From linimon at lonesome.com Tue Jul 1 00:21:31 2008 From: linimon at lonesome.com (Mark Linimon) Date: Tue Jul 1 00:21:37 2008 Subject: new wiki page to collect information about the ATA subsystem Message-ID: <20080701002130.GC5611@soaustin.net> Jeremy Chadwick (koitsu@) has been gathering together information on the wiki about commonly seen problems with FreeBSD: http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting Based on a discussion on #freebsd-bugbusters, I've gone ahead and added a signup page for people that are interested in volunteering to do ATA regression testing (either for patches that are included in the various PRs, or for isolating regressions that have already happened): http://wiki.freebsd.org/ATA/ATA_Volunteers Please feel free to sign up if you're interested in helping on this. Perhaps it will lead to something. There is also a new meta-page to cross-reference the above: http://wiki.freebsd.org/ATA mcl From pyunyh at gmail.com Tue Jul 1 00:51:06 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Tue Jul 1 00:51:11 2008 Subject: Marvell Yukon 88E8062 - media selection problem In-Reply-To: <1052423937.20080630135423@hot.pl> References: <1052423937.20080630135423@hot.pl> Message-ID: <20080701004855.GF83626@cdnetworks.co.kr> On Mon, Jun 30, 2008 at 01:54:23PM +0200, Krzysztof Jedruczyk wrote: > Hi, > > I am trying to bring up gigabit interface in couple of Nexcom blade servers running FreeBSD/amd64. The interfaces (two Marvell Yukon 88E8062 controllers) are recognized properly, but no media is ever detected: > > > ifconfig > msk0: flags=8802 metric 0 mtu 1500 > options=11a > ether 00:10:f3:0d:d6:45 > media: Ethernet autoselect (none) > status: no carrier > msk1: flags=8802 metric 0 mtu 1500 > options=11a > ether 00:10:f3:0d:d6:46 > media: Ethernet autoselect (none) > status: no carrier > > I tried manual setting of media - but the driver won't allow me to set 1000baseSX link (this is what other blades in the same chasis with working em driver are reporting). > > # ifconfig msk0 media 1000baseSX > ifconfig: SIOCSIFMEDIA (media): Device not configured > > I'm puzzled here: are there known limitations in the driver wrt support of certain media types? > > Here is pciconf -lv information if it helps... > > mskc0@pci0:3:0:0: class=0x020000 card=0x628211ab chip=0x434711ab rev=0x14 hdr=0x00 > vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > device = 'Yukon 88E8062 PCI-E IPMI Gigabit Ethernet Controller' > class = network > subclass = ethernet > > This is on 7.0-RELEASE on amd64. I also tried kernel from 7-STABLE from few days ago, but the problem was still present. > The 88E8062 support wasn't tested due to lack of hardware and I just copied the device id from myk driver. Would you show me the output of "devinfo -rv| grep oui" ? Also it would be better if I can see verbosed boot message. -- Regards, Pyun YongHyeon From daniel_k_eriksson at telia.com Tue Jul 1 10:10:59 2008 From: daniel_k_eriksson at telia.com (Daniel Eriksson) Date: Tue Jul 1 10:11:11 2008 Subject: MCP55 SATA data corruption in FreeBSD 7 Message-ID: <4F9C9299A10AE74E89EA580D14AA10A61A1968@royal64.emp.zapto.org> I am having problems with silent data corruption on (some) drives connected to an MCP55 SATA controller. I have two servers, both running RELENG_7_0/amd64. One has the 570 Ultra chipset, the other has 570 SLI. Both chipsets have the MCP55 SATA controller. The server with 570 Ultra chipset has a bunch of older 250GB SATA-150 drives hooked up to the MCP55 controller and it is working just fine. The server with 570 SLI chipset has a bunch of new SATA-300 drives hooked up to the MCP55 controller and it is giving me silent data corruption (easily detectable by running ZFS scrub, every time I run it new checksum errors show up). I know the drives are good because when they are hooked up to another controller they work just fine. Unfortunately the drives does not have a jumper for setting SATA-150 speed (they are Samsung 1 TB drives), and trying to force the drives to SATA-150 speed with the "patch" provided by the manufacturer does not seem to work (the drives still negotiate SATA-300 speed). I will try to get my hands on another older SATA-150 drive (or a new that can be jumpered) to verify if the culprit is the MCP55 revision (see below) or the interface speed. NOT working (570 SLI) --------------------- atapci1@pci0:0:5:0: class=0x010185 card=0x72501462 chip=0x037f10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 SATA Controller' class = mass storage subclass = ATA Working (570 Ultra) ------------------- atapci1@pci0:0:5:0: class=0x010185 card=0xcb8410de chip=0x037f10de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 SATA Controller' class = mass storage subclass = ATA This is most likely related to kern/120296 (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/120296) and kern/121396 (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/121396). If someone else is having data corruption problems with drives connected to an MCP55 controller it might be worth testing if limiting the drives to SATA-150 makes a difference. It will most likely take me a while before I can verify this. --- Daniel Eriksson (http://www.toomuchdata.com/) From beaker at hot.pl Tue Jul 1 10:32:06 2008 From: beaker at hot.pl (=?UTF-8?B?S3J6eXN6dG9mIErEmWRydWN6eWs=?=) Date: Tue Jul 1 10:32:10 2008 Subject: Marvell Yukon 88E8062 - media selection problem In-Reply-To: <20080701004855.GF83626@cdnetworks.co.kr> References: <1052423937.20080630135423@hot.pl> <20080701004855.GF83626@cdnetworks.co.kr> Message-ID: <486A07A4.1070406@hot.pl> Hi, Pyun YongHyeon wrote: > The 88E8062 support wasn't tested due to lack of hardware and I just > copied the device id from myk driver. Would you show me the output > of "devinfo -rv| grep oui" ? Also it would be better if I can see > verbosed boot message. > Here you go: # devinfo -rv | grep oui e1000phy0 pnpinfo oui=0x5043 model=0x9 rev=0x1 at phyno=0 e1000phy1 pnpinfo oui=0x5043 model=0x9 rev=0x1 at phyno=0 inphy0 pnpinfo oui=0xaa00 model=0x15 rev=0x4 at phyno=1 And dmesg with '-v' in boot.config and 'verbose_loading="YES"' in loader.conf: Copyright (c) 1992-2008 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 7.0-RELEASE-p2 #1: Mon Jun 30 20:03:47 CEST 2008 beaker@blade-1.ramfasto.com:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80bc8000. Calibrating clock(s) ... i8254 clock: 1193157 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 3600141768 Hz CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3600.14-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0xf4a Stepping = 10 Features=0xbfebfbff Features2=0x659d AMD Features=0x20100800 AMD Features2=0x1 Logical CPUs per core: 2 usable memory = 1059807232 (1010 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) 0x0000000000cc5000 - 0x000000003e09ffff, 1027452928 bytes (250843 pages) avail memory = 1021194240 (973 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 ACPI: RSDP @ 0x0xf5df0/0x0014 (v 0 IntelR) ACPI: RSDT @ 0x0x3fee3040/0x0030 (v 1 IntelR AWRDACPI 0x42302E31 AWRD 0x00000000) ACPI: FACP @ 0x0x3fee30c0/0x0074 (v 1 IntelR AWRDACPI 0x42302E31 AWRD 0x00000000) ACPI: DSDT @ 0x0x3fee3180/0x3AB7 (v 1 INTELR AWRDACPI 0x00001000 MSFT 0x0100000E) ACPI: FACS @ 0x0x3fee0000/0x0040 ACPI: MCFG @ 0x0x3fee6d80/0x003C (v 1 IntelR AWRDACPI 0x42302E31 AWRD 0x00000000) ACPI: APIC @ 0x0x3fee6c80/0x0084 (v 1 IntelR AWRDACPI 0x42302E31 AWRD 0x00000000) MADT: Found IO APIC ID 4, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 4 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high MADT: Ignoring local NMI routed to ACPI CPU 2 MADT: Ignoring local NMI routed to ACPI CPU 3 ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 ath_rate: version 1.2 wlan_amrr: wlan: <802.11 Link Layer> null: random: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: io: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Jun 30 2008 20:01:01) acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) AcpiOsDerivePciId: \\_SB_.PCI0.PX40.PIRQ -> bus 0 dev 31 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.PX40.PIR2 -> bus 0 dev 31 func 0 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3fde0000 (3) failed ACPI timer: 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 15 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 9 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 9 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 5 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 cpu0: on acpi0 cpu0: switching to generic Cx mode est0: enabling SpeedStep est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 122d0000122d device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 122d0000122d device_attach: est1 attach returned 6 p4tcc1: on cpu1 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x3590, revid=0x0c domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0106, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3591, revid=0x0c domain=0, bus=0, slot=0, func=1 class=ff-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3594, revid=0x0c domain=0, bus=0, slot=1, func=0 class=08-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 MSI supports 2 messages map[10]: type Memory, range 32, base 0xd8200000, size 12, enabled found-> vendor=0x8086, dev=0x3595, revid=0x0c domain=0, bus=0, slot=2, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x4018, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) intpin=a, irq=15 powerspec 2 supports D0 D3 current D0 MSI supports 2 messages pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3596, revid=0x0c domain=0, bus=0, slot=3, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x4018, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) intpin=a, irq=15 powerspec 2 supports D0 D3 current D0 MSI supports 2 messages pcib0: matched entry for 0.3.INTA pcib0: slot 3 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3597, revid=0x0c domain=0, bus=0, slot=4, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) intpin=a, irq=15 powerspec 2 supports D0 D3 current D0 MSI supports 2 messages pcib0: matched entry for 0.4.INTA pcib0: slot 4 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3598, revid=0x0c domain=0, bus=0, slot=5, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x4018, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) intpin=a, irq=15 powerspec 2 supports D0 D3 current D0 MSI supports 2 messages pcib0: matched entry for 0.5.INTA pcib0: slot 5 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3599, revid=0x0c domain=0, bus=0, slot=6, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x4018, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) intpin=a, irq=15 powerspec 2 supports D0 D3 current D0 MSI supports 2 messages pcib0: matched entry for 0.6.INTA pcib0: slot 6 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x359a, revid=0x0c domain=0, bus=0, slot=7, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x4018, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) intpin=a, irq=15 powerspec 2 supports D0 D3 current D0 MSI supports 2 messages pcib0: matched entry for 0.7.INTA pcib0: slot 7 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x24c2, revid=0x02 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=15 map[20]: type I/O Port, range 32, base 0xd800, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x24c4, revid=0x02 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 map[20]: type I/O Port, range 32, base 0xd000, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x24c7, revid=0x02 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[20]: type I/O Port, range 32, base 0xd400, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x24cd, revid=0x02 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xd8201000, size 10, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 23 found-> vendor=0x8086, dev=0x244e, revid=0x82 domain=0, bus=0, slot=30, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0080, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0e (3500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x24c0, revid=0x02 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x24cb, revid=0x02 domain=0, bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type I/O Port, range 32, base 0xf000, size 4, enabled map[24]: type Memory, range 32, base 0, size 10, enabled found-> vendor=0x8086, dev=0x24c3, revid=0x02 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=9 map[20]: type I/O Port, range 32, base 0x500, size 5, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 17 pci0: at device 0.1 (no driver attached) pci0: at device 1.0 (no driver attached) pcib1: irq 16 at device 2.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 pcib2: irq 16 at device 3.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xf000-0xfff pcib2: no prefetched decode pci2: on pcib2 pci2: domain=0, physical bus=2 pcib3: irq 16 at device 4.0 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xb000-0xbfff pcib3: memory decode 0xd8100000-0xd81fffff pcib3: no prefetched decode pci3: on pcib3 pci3: domain=0, physical bus=3 found-> vendor=0x11ab, dev=0x4347, revid=0x14 domain=0, bus=3, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=15 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 2 messages, 64 bit map[10]: type Memory, range 64, base 0xd8120000, size 14, enabled pcib3: requested memory range 0xd8120000-0xd8123fff: good map[18]: type I/O Port, range 32, base 0xb000, size 8, enabled pcib3: requested I/O range 0xb000-0xb0ff: in range pcib0: matched entry for 0.4.INTA pcib0: slot 4 INTA hardwired to IRQ 16 pcib3: slot 0 INTA is routed to irq 16 mskc0: port 0xb000-0xb0ff mem 0xd8120000-0xd8123fff irq 16 at device 0.0 on pci3 mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd8120000 mskc0: MSI count : 2 mskc0: RAM buffer size : 96KB mskc0: Port 0 : Rx Queue 70KB(0x00000000:0x000117ff) mskc0: Port 0 : Tx Queue 26KB(0x00011800:0x00017fff) mskc0: Port 1 : Rx Queue 70KB(0x00018000:0x000297ff) mskc0: Port 1 : Tx Queue 26KB(0x00029800:0x0002ffff) msk0: on mskc0 msk0: bpf attached msk0: Ethernet address: 00:10:f3:0d:d6:45 miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto msk1: on mskc0 msk1: bpf attached msk1: Ethernet address: 00:10:f3:0d:d6:46 miibus1: on msk1 e1000phy1: PHY 0 on miibus1 e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49 mskc0: [MPSAFE] mskc0: [FILTER] pcib4: irq 16 at device 5.0 on pci0 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0xf000-0xfff pcib4: no prefetched decode pci4: on pcib4 pci4: domain=0, physical bus=4 pcib5: irq 16 at device 6.0 on pci0 pcib5: domain 0 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: I/O decode 0xf000-0xfff pcib5: no prefetched decode pcib5: could not get PCI interrupt routing table for \\_SB_.PCI0.P1AB - AE_NOT_FOUND pci5: on pcib5 pci5: domain=0, physical bus=5 pcib6: irq 16 at device 7.0 on pci0 pcib6: domain 0 pcib6: secondary bus 6 pcib6: subordinate bus 6 pcib6: I/O decode 0xf000-0xfff pcib6: no prefetched decode pci6: on pcib6 pci6: domain=0, physical bus=6 uhci0: port 0xd800-0xd81f irq 16 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd800 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xd000-0xd01f irq 19 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd000 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 50 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xd400-0xd41f irq 18 at device 29.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd400 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 51 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xd8201000-0xd82013ff irq 23 at device 29.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xd8201000 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 52 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pcib7: at device 30.0 on pci0 pcib7: domain 0 pcib7: secondary bus 7 pcib7: subordinate bus 7 pcib7: I/O decode 0xc000-0xcfff pcib7: memory decode 0xd8000000-0xd80fffff pcib7: prefetched decode 0xd0000000-0xd7ffffff pcib7: Subtractively decoded bridge. pci7: on pcib7 pci7: domain=0, physical bus=7 found-> vendor=0x8086, dev=0x1229, revid=0x10 domain=0, bus=7, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=15 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xd8050000, size 12, enabled pcib7: requested memory range 0xd8050000-0xd8050fff: good map[14]: type I/O Port, range 32, base 0xc000, size 6, enabled pcib7: requested I/O range 0xc000-0xc03f: in range map[18]: type Memory, range 32, base 0xd8000000, size 17, enabled pcib7: requested memory range 0xd8000000-0xd801ffff: good pcib7: matched entry for 7.0.INTA pcib7: slot 0 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x515e, revid=0x02 domain=0, bus=7, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0087, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xd0000000, size 27, enabled pcib7: requested memory range 0xd0000000-0xd7ffffff: good map[14]: type I/O Port, range 32, base 0xc400, size 8, enabled pcib7: requested I/O range 0xc400-0xc4ff: in range map[18]: type Memory, range 32, base 0xd8040000, size 16, enabled pcib7: requested memory range 0xd8040000-0xd804ffff: good pcib7: matched entry for 7.2.INTA pcib7: slot 2 INTA hardwired to IRQ 18 fxp0: port 0xc000-0xc03f mem 0xd8050000-0xd8050fff,0xd8000000-0xd801ffff irq 16 at device 0.0 on pci7 fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xd8050000 fxp0: using memory space register mapping fxp0: PCI IDs: 8086 1229 8086 0000 0010 fxp0: Dynamic Standby mode is disabled miibus2: on fxp0 inphy0: PHY 1 on miibus2 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: bpf attached fxp0: Ethernet address: 00:10:f3:0d:d6:47 fxp0: [MPSAFE] fxp0: [ITHREAD] vgapci0: port 0xc400-0xc4ff mem 0xd0000000-0xd7ffffff,0xd8040000-0xd804ffff irq 18 at device 2.0 on pci7 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf000 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 53 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=00 ostat1=00 ata1: stat0=0x01 err=0x01 lsb=0x01 msb=0x01 ata1: stat1=0x01 err=0x01 lsb=0x01 msb=0x01 ata1: reset tp2 stat0=01 stat1=01 devices=0x0 ioapic0: routing intpin 15 (ISA IRQ 15) to vector 54 ata1: [MPSAFE] ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A ioapic0: routing intpin 4 (ISA IRQ 4) to vector 55 sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0 0 0 0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0 0 0 0 sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ioapic0: routing intpin 3 (ISA IRQ 3) to vector 56 sio1: [FILTER] ppc0: using extended I/O port range ppc0: SPP ppc0: port 0x378-0x37f,0x778-0x77b irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 ioapic0: routing intpin 7 (ISA IRQ 7) to vector 57 ppbus0: [MPSAFE] ppbus0: [ITHREAD] plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] psmcpnp0: irq 12 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 58 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: current command byte:0047 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to vector 59 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 ahc_isa_probe 0: ioport 0xc00 alloc failed ex_isa_identify() atkbdc: atkbdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xc8fff,0xcc000-0xcd7ff on isa0 fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 isa_probe_children: probing PnP devices Device configuration finished. procfs registered lapic: Divisor 2, Frequency 100003932 hz Timecounter "TSC" frequency 3600141768 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached hptrr: no controller detected. ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire ad0: setting PIO4 on ICH4 chip ad0: DMA limited to UDMA33, controller found non-ATA66 cable ad0: setting UDMA33 on ICH4 chip ad0: 238475MB at ata0-master UDMA33 ad0: 488397168 sectors [484521C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad0 ad0: Intel check1 failed ad0: Adaptec check1 failed ad0: LSI (v3) check1 failed ad0: LSI (v2) check1 failed ad0: FreeBSD check1 failed ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 Trying to mount root from ufs:/dev/ad0s1a start_init: trying /sbin/init From sos at FreeBSD.ORG Tue Jul 1 11:12:14 2008 From: sos at FreeBSD.ORG (=?ISO-8859-1?Q?S=F8ren_Schmidt?=) Date: Tue Jul 1 11:12:18 2008 Subject: MCP55 SATA data corruption in FreeBSD 7 In-Reply-To: <4F9C9299A10AE74E89EA580D14AA10A61A1968@royal64.emp.zapto.org> References: <4F9C9299A10AE74E89EA580D14AA10A61A1968@royal64.emp.zapto.org> Message-ID: Hi I'll look into that providing I can find HW to work on, IIRC I have one in the ATA collection but I have to verify when I get to the lab. -S?ren On 1Jul, 2008, at 11:01 , Daniel Eriksson wrote: > > I am having problems with silent data corruption on (some) drives > connected to an MCP55 SATA controller. > > I have two servers, both running RELENG_7_0/amd64. One has the 570 > Ultra > chipset, the other has 570 SLI. Both chipsets have the MCP55 SATA > controller. > > The server with 570 Ultra chipset has a bunch of older 250GB SATA-150 > drives hooked up to the MCP55 controller and it is working just fine. > The server with 570 SLI chipset has a bunch of new SATA-300 drives > hooked up to the MCP55 controller and it is giving me silent data > corruption (easily detectable by running ZFS scrub, every time I run > it > new checksum errors show up). I know the drives are good because when > they are hooked up to another controller they work just fine. > > Unfortunately the drives does not have a jumper for setting SATA-150 > speed (they are Samsung 1 TB drives), and trying to force the drives > to > SATA-150 speed with the "patch" provided by the manufacturer does not > seem to work (the drives still negotiate SATA-300 speed). I will try > to > get my hands on another older SATA-150 drive (or a new that can be > jumpered) to verify if the culprit is the MCP55 revision (see below) > or > the interface speed. > > > NOT working (570 SLI) > --------------------- > atapci1@pci0:0:5:0: class=0x010185 card=0x72501462 chip=0x037f10de > rev=0xa2 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'MCP55 SATA Controller' > class = mass storage > subclass = ATA > > Working (570 Ultra) > ------------------- > atapci1@pci0:0:5:0: class=0x010185 card=0xcb8410de chip=0x037f10de > rev=0xa3 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'MCP55 SATA Controller' > class = mass storage > subclass = ATA > > This is most likely related to kern/120296 > (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/120296) and kern/ > 121396 > (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/121396). > > > If someone else is having data corruption problems with drives > connected > to an MCP55 controller it might be worth testing if limiting the > drives > to SATA-150 makes a difference. It will most likely take me a while > before I can verify this. > > --- > Daniel Eriksson (http://www.toomuchdata.com/) > -S?ren From yraffah at sadeem.net Tue Jul 1 11:13:04 2008 From: yraffah at sadeem.net (Yousef Raffah) Date: Tue Jul 1 11:13:08 2008 Subject: Syncing or maybe update issue In-Reply-To: References: <20080630110349.GA80339@eos.sc1.parodius.com> Message-ID: On Mon, Jun 30, 2008 at 4:20 PM, Yousef Raffah wrote: > On Mon, Jun 30, 2008 at 2:03 PM, Jeremy Chadwick wrote: >> On Mon, Jun 30, 2008 at 01:09:25PM +0300, Yousef Raffah wrote: >>> Hello, >>> >>> I have a box which can't sync using cvsup, therefore, ... >> >> Let's start here. Why not? What happens? Have you used -L2? >> >> Also, if you're using 6.2 or later, you should be able to use csup >> (comes with the base system) and not cvsup. >> >>> I thought of >>> using cvs by invoking the following command in the directory >>> /usr/src/cvs/ >>> >>> # cvs -d freebsdanoncvs@anoncvs.freebsd.org:/home/ncvs co src >>> >>> I do get all the updates and it seems to be checking out successfully, >>> however, when I try to >>> # make -j4 buildword >>> I get the following error about elf.h not being found! >> >> This looks like you're checking out HEAD/-CURRENT. Is this really what >> you want to be doing? Probably not, based on the fact you mailed >> freebsd-stable and not freebsd-current. >> > I guess you nailed it, I couldn't understand how to specify that using > the command I used earlier. Anyhow, I'm checking it with the -r > RELENG_7_0_0_RELEASE and will report back how things go. I guess I couldn't figure out how to checkout RELENG_7_0_0_RELEASE from the mirror freebsdanoncvs@anoncvs.FreeBSD.org:/home/ncvs I typed this: # cvs checkout -r RELENG_7_0_0_RELEASE src Can someone help with it, I can't spot an issue with the syntax but it is complaining saying: cvs [checkout aborted]: cannot write /home/ncvs/CVSROOT/val-tags: Permission denied From bu7cher at yandex.ru Tue Jul 1 11:30:25 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Tue Jul 1 11:30:30 2008 Subject: MCP55 SATA data corruption in FreeBSD 7 In-Reply-To: <4F9C9299A10AE74E89EA580D14AA10A61A1968@royal64.emp.zapto.org> References: <4F9C9299A10AE74E89EA580D14AA10A61A1968@royal64.emp.zapto.org> Message-ID: <486A113B.8070607@yandex.ru> Daniel Eriksson wrote: > Unfortunately the drives does not have a jumper for setting SATA-150 > speed (they are Samsung 1 TB drives), and trying to force the drives to > SATA-150 speed with the "patch" provided by the manufacturer does not > seem to work (the drives still negotiate SATA-300 speed). I will try to > get my hands on another older SATA-150 drive (or a new that can be > jumpered) to verify if the culprit is the MCP55 revision (see below) or > the interface speed. Which patch did you use? -- WBR, Andrey V. Elsukov From daniel_k_eriksson at telia.com Tue Jul 1 12:49:05 2008 From: daniel_k_eriksson at telia.com (Daniel Eriksson) Date: Tue Jul 1 12:49:10 2008 Subject: MCP55 SATA data corruption in FreeBSD 7 In-Reply-To: <486A113B.8070607@yandex.ru> References: <4F9C9299A10AE74E89EA580D14AA10A61A1968@royal64.emp.zapto.org> <486A113B.8070607@yandex.ru> Message-ID: <4F9C9299A10AE74E89EA580D14AA10A61A1969@royal64.emp.zapto.org> Andrey V. Elsukov wrote: > Which patch did you use? I used BDM_SpeedSwitch1.zip (http://www.samsung.com/global/system/business/hdd/faq/2007/10/29/184337 BDM_SpeedSwitch1.zip). /Daniel From koitsu at FreeBSD.org Tue Jul 1 12:53:28 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Jul 1 12:53:31 2008 Subject: MCP55 SATA data corruption in FreeBSD 7 In-Reply-To: <4F9C9299A10AE74E89EA580D14AA10A61A1968@royal64.emp.zapto.org> References: <4F9C9299A10AE74E89EA580D14AA10A61A1968@royal64.emp.zapto.org> Message-ID: <20080701125328.GA69964@eos.sc1.parodius.com> On Tue, Jul 01, 2008 at 11:01:17AM +0200, Daniel Eriksson wrote: > The server with 570 Ultra chipset has a bunch of older 250GB SATA-150 > drives hooked up to the MCP55 controller and it is working just fine. > The server with 570 SLI chipset has a bunch of new SATA-300 drives > hooked up to the MCP55 controller and it is giving me silent data > corruption (easily detectable by running ZFS scrub, every time I run it > new checksum errors show up). I know the drives are good because when > they are hooked up to another controller they work just fine. With the same cables? Not that I want to use cables as a scapegoat, but in this case it seems applicable. > Unfortunately the drives does not have a jumper for setting SATA-150 > speed (they are Samsung 1 TB drives), and trying to force the drives to > SATA-150 speed with the "patch" provided by the manufacturer does not > seem to work (the drives still negotiate SATA-300 speed). I will try to > get my hands on another older SATA-150 drive (or a new that can be > jumpered) to verify if the culprit is the MCP55 revision (see below) or > the interface speed. Can you provide "atacontrol cap" output for one of the drives? I know in the case of Maxtor drives, there is a bug that exists in one of their disk firmwares which causes silent data corruption and/or SATA bus lockups when NCQ is used on nForce 4 chipsets. Maxtor provides a firmware update which fixes the bug. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From sos at FreeBSD.ORG Tue Jul 1 12:58:56 2008 From: sos at FreeBSD.ORG (=?ISO-8859-1?Q?S=F8ren_Schmidt?=) Date: Tue Jul 1 12:59:03 2008 Subject: MCP55 SATA data corruption in FreeBSD 7 In-Reply-To: <4F9C9299A10AE74E89EA580D14AA10A61A1968@royal64.emp.zapto.org> References: <4F9C9299A10AE74E89EA580D14AA10A61A1968@royal64.emp.zapto.org> Message-ID: <7ABD8B47-2ECD-457E-908D-E0BED4C6AE56@FreeBSD.ORG> Hi OK, the only "modern" nVidia board I have is MCP51 based, however it uses the same codepath as the MCP55. Anyhow, there has been fixes fro these in -current, thats not in any of the releng's yet. Please try the attached patch, or even better try a -current kernel. -S?ren -------------- next part -------------- A non-text attachment was scrubbed... Name: ff Type: application/octet-stream Size: 1238 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080701/30d963c2/ff.obj -------------- next part -------------- On 1Jul, 2008, at 11:01 , Daniel Eriksson wrote: > > I am having problems with silent data corruption on (some) drives > connected to an MCP55 SATA controller. > > I have two servers, both running RELENG_7_0/amd64. One has the 570 > Ultra > chipset, the other has 570 SLI. Both chipsets have the MCP55 SATA > controller. > > The server with 570 Ultra chipset has a bunch of older 250GB SATA-150 > drives hooked up to the MCP55 controller and it is working just fine. > The server with 570 SLI chipset has a bunch of new SATA-300 drives > hooked up to the MCP55 controller and it is giving me silent data > corruption (easily detectable by running ZFS scrub, every time I run > it > new checksum errors show up). I know the drives are good because when > they are hooked up to another controller they work just fine. > > Unfortunately the drives does not have a jumper for setting SATA-150 > speed (they are Samsung 1 TB drives), and trying to force the drives > to > SATA-150 speed with the "patch" provided by the manufacturer does not > seem to work (the drives still negotiate SATA-300 speed). I will try > to > get my hands on another older SATA-150 drive (or a new that can be > jumpered) to verify if the culprit is the MCP55 revision (see below) > or > the interface speed. > > > NOT working (570 SLI) > --------------------- > atapci1@pci0:0:5:0: class=0x010185 card=0x72501462 chip=0x037f10de > rev=0xa2 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'MCP55 SATA Controller' > class = mass storage > subclass = ATA > > Working (570 Ultra) > ------------------- > atapci1@pci0:0:5:0: class=0x010185 card=0xcb8410de chip=0x037f10de > rev=0xa3 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'MCP55 SATA Controller' > class = mass storage > subclass = ATA > > This is most likely related to kern/120296 > (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/120296) and kern/ > 121396 > (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/121396). > > > If someone else is having data corruption problems with drives > connected > to an MCP55 controller it might be worth testing if limiting the > drives > to SATA-150 makes a difference. It will most likely take me a while > before I can verify this. > > --- > Daniel Eriksson (http://www.toomuchdata.com/) > -S?ren From daniel_k_eriksson at telia.com Tue Jul 1 13:20:18 2008 From: daniel_k_eriksson at telia.com (Daniel Eriksson) Date: Tue Jul 1 13:20:26 2008 Subject: MCP55 SATA data corruption in FreeBSD 7 In-Reply-To: <20080701125328.GA69964@eos.sc1.parodius.com> References: <4F9C9299A10AE74E89EA580D14AA10A61A1968@royal64.emp.zapto.org> <20080701125328.GA69964@eos.sc1.parodius.com> Message-ID: <4F9C9299A10AE74E89EA580D14AA10A61A196A@royal64.emp.zapto.org> Jeremy Chadwick wrote: > With the same cables? Not that I want to use cables as a > scapegoat, but in this case it seems applicable. With the same cables, yes. > Can you provide "atacontrol cap" output for one of the drives? # atacontrol cap ad4 Protocol Serial ATA II device model SAMSUNG HD103UJ firmware revision 1AA01112 cylinders 16383 heads 16 sectors/track 63 lba supported 268435455 sectors lba48 supported 1953525168 sectors dma supported overlap not supported Feature Support Enable Value Vendor write cache yes yes read ahead yes yes Native Command Queuing (NCQ) yes - 31/0x1F Tagged Command Queuing (TCQ) no no 31/0x1F SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes no 0/0x00 automatic acoustic management yes no 0/0x00 254/0xFE > I know in the case of Maxtor drives, there is a bug that exists in one > of their disk firmwares which causes silent data corruption and/or > SATA bus lockups when NCQ is used on nForce 4 chipsets. Maxtor > provides a firmware update which fixes the bug. Connecting (some of) the drives to a or a makes them work just fine. FreeBSD itself does not seem to notice any data corruption. I only noticed it because "zpool status" reported checksum errors after I had written almost 3 TB to the array. I then issued a "zpool scrub", and within a couple of minutes I already had dozens of corrupt files (so I stopped the scrub, deleted the pool and started fault-finding). --- Daniel Eriksson (http://www.toomuchdata.com/) From ronald-freebsd8 at klop.yi.org Tue Jul 1 15:12:11 2008 From: ronald-freebsd8 at klop.yi.org (Ronald Klop) Date: Tue Jul 1 15:12:21 2008 Subject: installdate of a port/package? Message-ID: Hello, I just upgraded a machine from FreeBSD 6 to 7. Very nice. But my portupgrade -fa failed after a while. How can I know which ports/packages are still from FreeBSD 6? Is there a datee recorded somewhere or the FreeBSD-version of the port/package? The date of the files in /var/db/pkg/* is unreliable, because installing a package gives these files the date of the files in the package. How do I know which ports I still need to update? Ronald. From daniel_k_eriksson at telia.com Tue Jul 1 15:12:43 2008 From: daniel_k_eriksson at telia.com (Daniel Eriksson) Date: Tue Jul 1 15:12:49 2008 Subject: MCP55 SATA data corruption in FreeBSD 7 In-Reply-To: <7ABD8B47-2ECD-457E-908D-E0BED4C6AE56@FreeBSD.ORG> References: <4F9C9299A10AE74E89EA580D14AA10A61A1968@royal64.emp.zapto.org> <7ABD8B47-2ECD-457E-908D-E0BED4C6AE56@FreeBSD.ORG> Message-ID: <4F9C9299A10AE74E89EA580D14AA10A61A196B@royal64.emp.zapto.org> S?ren Schmidt wrote: > Please try the attached patch, or even better try a -current kernel. The patch made no difference on RELENG_7_0 unfortunately. (And I cannot try CURRENT on this server.) ___ Daniel Eriksson (http://www.toomuchdata.com/) From mh at kernel32.de Tue Jul 1 15:23:31 2008 From: mh at kernel32.de (Marian Hettwer) Date: Tue Jul 1 15:23:39 2008 Subject: no serial console for ttyd0 HP Blade Message-ID: <29641b38fd128219d11b0a910949a68c@localhost> Hi All, I installed a recent (as of today) RELENG_7 on one of our HP Blades. Unluckily my serial output stops right when a getty at ttyd0 should kick in. So I'm blind for the rest of the startup. Very unfortunate. The boot menu, as the bootup itself is printed out on serial console until: da0: Fixed Direct Access SCSI-5 device da0: 135.168MB/s transfers da0: 139947MB (286611840 512 byte sectors: 255H 32S/T 35124C) Trying to mount root from ufs:/dev/da0s1a bce0: link state changed to DOWN bce0: link state changed to UP bce1: link state changed to UP Which is, what I think, the point when init should take over and spawn a serial console on ttyd0, according to my /etc/ttys: # grep ttyd0 /etc/ttys ttyd0 "/usr/libexec/getty std.9600" vt100 on secure # cat /boot/loader.conf comconsole_speed="9600" console="vidconsole,comconsole" # A comma separated list of console(s) boot_multicons="-D" # -D: Use multiple consoles boot_serial="-h" # -h: Use serial console # uname -a FreeBSD db46-202.mobile.rz 7.0-STABLE FreeBSD 7.0-STABLE #0: Tue Jul 1 14:59:43 CEST 2008 root@db46-202.mobile.rz:/usr/obj/usr/src/sys/GENERIC amd64 The blade itself is a HP BL465c G5 Any ideas? I don't have this blade for a long time, so I'm a bit in a hurry. In fact, right now I'm testing this setup against a Debian 4.0 with Linux 2.6.25.9 under MySQL load, and up until now the machine looks good. If I wind up with a fully working, nearly as fast and stable as our linux boxes installation, I'd might be able to convince "the boys at work" to give FreeBSD a try. And in a 600 server setup, I'd be thrilled to do so :-) So lets get started with this serial console issue... which is indeed a pain :( TIA, Marian From alex at trull.org Tue Jul 1 15:53:29 2008 From: alex at trull.org (Alex Trull) Date: Tue Jul 1 15:53:33 2008 Subject: installdate of a port/package? In-Reply-To: References: Message-ID: <20080701153446.GB13250@syndicate.internationalconspiracy.org> Ronald, Look for files that are older than your upgrade/portupgrade -fa date in /usr/local/bin and /usr/local/sbin. e.g. $ find $dir -mtime +2 -type f -xdev -print Add a little guesswork/pkg_info to determine which ports they're from. Throw in a few more forced recursive portupgrades incase anything is broken for having built against older libraries. -- Alex On Tue, Jul 01, 2008 at 05:12:05PM +0200, Ronald Klop wrote: > Hello, > > I just upgraded a machine from FreeBSD 6 to 7. Very nice. > But my portupgrade -fa failed after a while. > How can I know which ports/packages are still from FreeBSD 6? Is there a > datee recorded somewhere or the FreeBSD-version of the port/package? > The date of the files in /var/db/pkg/* is unreliable, because installing > a package gives these files the date of the files in the package. > > How do I know which ports I still need to update? > > Ronald. From utisoft at googlemail.com Tue Jul 1 15:58:57 2008 From: utisoft at googlemail.com (Chris Rees) Date: Tue Jul 1 15:59:02 2008 Subject: MCP55 SATA data corruption in FreeBSD 7 Message-ID: > Date: Tue, 1 Jul 2008 11:01:17 +0200 > From: "Daniel Eriksson" > > I am having problems with silent data corruption on (some) drives > connected to an MCP55 SATA controller. > > I have two servers, both running RELENG_7_0/amd64. One has the 570 Ultra > chipset, the other has 570 SLI. Both chipsets have the MCP55 SATA > controller. > > The server with 570 Ultra chipset has a bunch of older 250GB SATA-150 > drives hooked up to the MCP55 controller and it is working just fine. > The server with 570 SLI chipset has a bunch of new SATA-300 drives > hooked up to the MCP55 controller and it is giving me silent data > corruption (easily detectable by running ZFS scrub, every time I run it > new checksum errors show up). I know the drives are good because when > they are hooked up to another controller they work just fine. > > Unfortunately the drives does not have a jumper for setting SATA-150 > speed (they are Samsung 1 TB drives), and trying to force the drives to > SATA-150 speed with the "patch" provided by the manufacturer does not > seem to work (the drives still negotiate SATA-300 speed). I will try to > get my hands on another older SATA-150 drive (or a new that can be > jumpered) to verify if the culprit is the MCP55 revision (see below) or > the interface speed. > > > NOT working (570 SLI) > --------------------- > atapci1@pci0:0:5:0: class=0x010185 card=0x72501462 chip=0x037f10de > rev=0xa2 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'MCP55 SATA Controller' > class = mass storage > subclass = ATA > > Working (570 Ultra) > ------------------- > atapci1@pci0:0:5:0: class=0x010185 card=0xcb8410de chip=0x037f10de > rev=0xa3 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'MCP55 SATA Controller' > class = mass storage > subclass = ATA > > This is most likely related to kern/120296 > (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/120296) and kern/121396 > (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/121396). > > > If someone else is having data corruption problems with drives connected > to an MCP55 controller it might be worth testing if limiting the drives > to SATA-150 makes a difference. It will most likely take me a while > before I can verify this. > > --- > Daniel Eriksson (http://www.toomuchdata.com/) > I have a 570 SLI too (Asus M2N-SLI Deluxe), I've been looking for an excuse to put FreeBSD on here :) I'll start installing it, anything I should do to make this error more obvious? My hard drive is a WDC WD2000JS-00SGB0; http://www.wdc.com/en/library/sata/2879-001146.pdf Chris From wahjava.ml at gmail.com Tue Jul 1 16:39:51 2008 From: wahjava.ml at gmail.com (=?utf-8?B?4KSG4KS24KWA4KS3IOCktuClgeCkleCljeCksg==?= Ashish Shukla) Date: Tue Jul 1 16:39:57 2008 Subject: Marvell Yukon 88E8062 - media selection problem In-Reply-To: <1052423937.20080630135423@hot.pl> References: <1052423937.20080630135423@hot.pl> Message-ID: <20080701161443.GA4955@chateau.d.lf> ,--[ On Mon, Jun 30, 2008 at 01:54:23PM +0200, Krzysztof Jedruczyk wrote: | Hi, | | I am trying to bring up gigabit interface in couple of Nexcom blade servers running FreeBSD/amd64. The interfaces (two Marvell Yukon 88E8062 controllers) are recognized properly, but no media is ever detected: | | > ifconfig | msk0: flags=8802 metric 0 mtu 1500 | options=11a | ether 00:10:f3:0d:d6:45 | media: Ethernet autoselect (none) | status: no carrier | msk1: flags=8802 metric 0 mtu 1500 | options=11a | ether 00:10:f3:0d:d6:46 | media: Ethernet autoselect (none) | status: no carrier | | I tried manual setting of media - but the driver won't allow me to set 1000baseSX link (this is what other blades in the same chasis with working em driver are reporting). | | # ifconfig msk0 media 1000baseSX | ifconfig: SIOCSIFMEDIA (media): Device not configured How about doing 'ifconfig msk0 up' prior to setting media ? Not sure, if that'll work. HTH Ashish -- ?-- ?- ???? ?--- ?- ???- ?- ?--?-? --? -- ?- ?? ?-?? ?-?-?- -?-? --- -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080701/ba15d131/attachment.pgp From daniel_k_eriksson at telia.com Tue Jul 1 16:55:25 2008 From: daniel_k_eriksson at telia.com (Daniel Eriksson) Date: Tue Jul 1 16:55:30 2008 Subject: MCP55 SATA data corruption in FreeBSD 7 In-Reply-To: References: Message-ID: <4F9C9299A10AE74E89EA580D14AA10A61A196C@royal64.emp.zapto.org> Chris Rees wrote: > I have a 570 SLI too (Asus M2N-SLI Deluxe), I've been looking for an > excuse to put FreeBSD on here :) > > I'll start installing it, anything I should do to make this > error more obvious? No, if it is a common problem with this chipset and/or MCP55 controller revision (which I think) then you should run into problems pretty much as soon as you start reading from the drive (on initial boot after install for example). I'm not sure if the problem is amd64 specific or not, but it seems the people that have reported problems have all run amd64 (and not i386). This might be a coincident though. ___ Daniel Eriksson (http://www.toomuchdata.com/) From jhb at freebsd.org Tue Jul 1 23:00:45 2008 From: jhb at freebsd.org (John Baldwin) Date: Tue Jul 1 23:00:48 2008 Subject: Problem with /boot/loader In-Reply-To: <20080627031233.9DC4945047@ptavv.es.net> References: <20080627031233.9DC4945047@ptavv.es.net> Message-ID: <200807011836.32855.jhb@freebsd.org> On Thursday 26 June 2008 11:12:33 pm Kevin Oberman wrote: > > Date: Thu, 26 Jun 2008 23:53:44 +0200 > > From: Volker > > Sender: owner-freebsd-stable@freebsd.org > > > > On 12/23/-58 20:59, Kelly Black wrote: > > > Hello, > > > > > > I have a problem with loader. I recently upgraded from 6_rel to 7_rel. > > > Now when I install world there is a problem booting. > > > > > > Here is what I do: > > > cd /usr/src > > > make buildworld > > > make buildkernel KERNCONF=BLACK > > > make installkernel KERNCONF=BLACK > > > > > > At this point I can reboot and all is good. After boot I install the new world: > > > > > > cd /usr/src > > > mergemaster -p > > > reboot into single user mode > > > cd /usr/src > > > make installworld > > > mergemaster > > > > > > Now when I reboot there is a problem. I get an error that the system > > > cannot boot. Part of it looks like this: > > > Can't work out which disk we are booting from. > > > Guessed BIOS device 0xffffffff not found by probes, defaulting to disk0: > > > > > > If I boot from a live disk and replace /boot/loader with > > > /boot/loader.old it boots up fine and everything looks good. A new > > > world and a new kernel. I would be grateful for any help or any > > > pointers. > > > > > > Sincerely, > > > Kel > > > > > > PS I do not do anything special with my loader config files: > > > > > > $ cat loader.conf > > >... > > > > Kelly, > > > > the /boot/loader.conf file does not come into play at that stage. Early > > in the loader code, loader needs to figure out, which disk (BIOS device) > > has been booted from. Until loader knows which device was booted up, > > it's unable to access any files (even loader.conf) on your boot device. > > > > As I've never seen such a problem while upgrading any system, I suspect > > your problem must be settings specific. Can you show me your kernel > > config or are you using a plain vanilla GENERIC? Which arch are we > > talking about? > > > > As I'm currently investigating another boot problem (but earlier in the > > boot chain), I'll check boot logic in the source code and may check for > > your issue, too, at that time, so it's just one effort. But please stay > > patient for some days, as I'm currently too busy. > > We just got hit by this. The loader never loads and nothing boots. But a > system admin discovered that the problem disappeared if the /boot.conf > file was deleted. It just contained '-P'. > > Once this file was removed, the system just booted up as expected. When > he changed it to -D or -h, the boot still locked up. Hmm, this is actually a bit helpful. What if you set the equivalent variables in /boot/loader.conf (e.g. console=comconsole) does it still hang? -- John Baldwin From pyunyh at gmail.com Wed Jul 2 01:11:41 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Jul 2 01:11:46 2008 Subject: Marvell Yukon 88E8062 - media selection problem In-Reply-To: <486A07A4.1070406@hot.pl> References: <1052423937.20080630135423@hot.pl> <20080701004855.GF83626@cdnetworks.co.kr> <486A07A4.1070406@hot.pl> Message-ID: <20080702010929.GA87933@cdnetworks.co.kr> On Tue, Jul 01, 2008 at 12:32:04PM +0200, Krzysztof J??druczyk wrote: > Hi, > > Pyun YongHyeon wrote: > >The 88E8062 support wasn't tested due to lack of hardware and I just > >copied the device id from myk driver. Would you show me the output > >of "devinfo -rv| grep oui" ? Also it would be better if I can see > >verbosed boot message. > > > > Here you go: > > # devinfo -rv | grep oui > e1000phy0 pnpinfo oui=0x5043 model=0x9 rev=0x1 at phyno=0 > e1000phy1 pnpinfo oui=0x5043 model=0x9 rev=0x1 at phyno=0 > inphy0 pnpinfo oui=0xaa00 model=0x15 rev=0x4 at phyno=1 > > And dmesg with '-v' in boot.config and 'verbose_loading="YES"' in > loader.conf: > Would you try attached patch? The patch is just for checking code path of fiber media. Btw, it looks like you have dual port controller, right? -- Regards, Pyun YongHyeon -------------- next part -------------- --- sys/dev/mii/e1000phy.c.orig 2007-11-21 14:51:55.000000000 +0900 +++ sys/dev/mii/e1000phy.c 2008-07-02 09:57:39.000000000 +0900 @@ -148,10 +148,13 @@ esc->mii_model = MII_MODEL(ma->mii_id2); switch (esc->mii_model) { case MII_MODEL_MARVELL_E1011: - case MII_MODEL_MARVELL_E1112: if (PHY_READ(sc, E1000_ESSR) & E1000_ESSR_FIBER_LINK) sc->mii_flags |= MIIF_HAVEFIBER; break; + case MII_MODEL_MARVELL_E1112: + /* XXX Should have a way to get instance info. */ + sc->mii_flags |= MIIF_HAVEFIBER; + break; case MII_MODEL_MARVELL_E3082: /* 88E3082 10/100 Fast Ethernet PHY. */ sc->mii_anegticks = MII_ANEGTICKS; From swhetzel at gmail.com Wed Jul 2 03:30:14 2008 From: swhetzel at gmail.com (Scot Hetzel) Date: Wed Jul 2 03:30:17 2008 Subject: Syncing or maybe update issue In-Reply-To: References: <20080630110349.GA80339@eos.sc1.parodius.com> Message-ID: <790a9fff0807012003j1b187d3dr75496cd239696137@mail.gmail.com> On Tue, Jul 1, 2008 at 6:13 AM, Yousef Raffah wrote: > I guess I couldn't figure out how to checkout RELENG_7_0_0_RELEASE > from the mirror > freebsdanoncvs@anoncvs.FreeBSD.org:/home/ncvs > I typed this: > # cvs checkout -r RELENG_7_0_0_RELEASE src > > Can someone help with it, I can't spot an issue with the syntax but it > is complaining saying: > cvs [checkout aborted]: cannot write /home/ncvs/CVSROOT/val-tags: > Permission denied Have a look at the handbook section: A.3 Using Anonymous CVS http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/anoncvs.html Scot From bu7cher at yandex.ru Wed Jul 2 03:52:32 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Wed Jul 2 03:52:37 2008 Subject: MCP55 SATA data corruption in FreeBSD 7 In-Reply-To: <4F9C9299A10AE74E89EA580D14AA10A61A196C@royal64.emp.zapto.org> References: <4F9C9299A10AE74E89EA580D14AA10A61A196C@royal64.emp.zapto.org> Message-ID: <486AFB78.5030905@yandex.ru> Daniel Eriksson wrote: > I'm not sure if the problem is amd64 specific or not, but it seems the > people that have reported problems have all run amd64 (and not i386). > This might be a coincident though. I have two motherboards with MCP55. They work well and I didn't see any data corruption. 1. ASUS M2N32 WS Pro (nForce 590 Ultra) FreeBSD 8.0-CURRENT amd64 atapci1@pci0:0:13:0: class=0x010185 card=0x81fb1043 chip=0x037f10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 SATA Controller' class = mass storage subclass = ATA 2. EPOX (don't remember version) (nForce 570 Ultra) FreeBSD 6.2-STABLE amd64 atapci1@pci0:5:0: class=0x010185 card=0x10261695 chip=0x037f10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class = mass storage subclass = ATA Both work on amd64 many months... -- WBR, Andrey V. Elsukov From jrhett at netconsonance.com Wed Jul 2 04:42:21 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed Jul 2 04:42:26 2008 Subject: no serial console for ttyd0 HP Blade In-Reply-To: <29641b38fd128219d11b0a910949a68c@localhost> References: <29641b38fd128219d11b0a910949a68c@localhost> Message-ID: <3AC5DAEE-95F1-4211-A819-CC085DD180ED@netconsonance.com> This rhymes with sio deciding that your TTY is something other than ttyd0. We had this same problem on Rackable -- even though the proper tty was setup 0x3f8 irq 4 it was being assigned to sio1. You can see this by 'grep sio /var/log/messages' The only fix for this is to edit /boot/device.hints and reassign the flags to the sio1 interface, like so: hint.sio.1.at="isa" hint.sio.1.port="0x3F8" hint.sio.1.flags="0x10" hint.sio.1.irq="4" hint.sio.0.at="isa" hint.sio.0.port="0x2F8" hint.sio.0.irq="3" On Jul 1, 2008, at 8:23 AM, Marian Hettwer wrote: > I installed a recent (as of today) RELENG_7 on one of our HP Blades. > Unluckily my serial output stops right when a getty at ttyd0 should > kick > in. So I'm blind for the rest of the startup. > Very unfortunate. > The boot menu, as the bootup itself is printed out on serial console > until: > da0: Fixed Direct Access SCSI-5 device > da0: 135.168MB/s transfers > da0: 139947MB (286611840 512 byte sectors: 255H 32S/T 35124C) > Trying to mount root from ufs:/dev/da0s1a > bce0: link state changed to DOWN > bce0: link state changed to UP > bce1: link state changed to UP > > Which is, what I think, the point when init should take over and > spawn a > serial console on ttyd0, according to my /etc/ttys: > # grep ttyd0 /etc/ttys > ttyd0 "/usr/libexec/getty std.9600" vt100 on secure > > # cat /boot/loader.conf > comconsole_speed="9600" > console="vidconsole,comconsole" # A comma separated list of > console(s) > boot_multicons="-D" # -D: Use multiple consoles > boot_serial="-h" # -h: Use serial console > > # uname -a > FreeBSD db46-202.mobile.rz 7.0-STABLE FreeBSD 7.0-STABLE #0: Tue > Jul 1 > 14:59:43 CEST 2008 root@db46-202.mobile.rz:/usr/obj/usr/src/sys/ > GENERIC > amd64 > > The blade itself is a HP BL465c G5 > > Any ideas? I don't have this blade for a long time, so I'm a bit in a > hurry. > In fact, right now I'm testing this setup against a Debian 4.0 with > Linux > 2.6.25.9 under MySQL load, and up until now the machine looks good. > If I wind up with a fully working, nearly as fast and stable as our > linux > boxes installation, I'd might be able to convince "the boys at work" > to > give FreeBSD a try. > And in a 600 server setup, I'd be thrilled to do so :-) > So lets get started with this serial console issue... which is > indeed a > pain :( > > TIA, > Marian > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From daniel_k_eriksson at telia.com Wed Jul 2 06:48:08 2008 From: daniel_k_eriksson at telia.com (Daniel Eriksson) Date: Wed Jul 2 06:48:12 2008 Subject: MCP55 SATA data corruption in FreeBSD 7 In-Reply-To: <486AFB78.5030905@yandex.ru> References: <4F9C9299A10AE74E89EA580D14AA10A61A196C@royal64.emp.zapto.org> <486AFB78.5030905@yandex.ru> Message-ID: <4F9C9299A10AE74E89EA580D14AA10A61A196F@royal64.emp.zapto.org> Andrey V. Elsukov wrote: > I have two motherboards with MCP55. They work well and I didn't > see any data corruption. Do you have SATA-150 or SATA-300 drives connected to the motherboards? ___ Daniel Eriksson (http://www.toomuchdata.com/) From ulf at Alameda.net Wed Jul 2 07:06:56 2008 From: ulf at Alameda.net (Ulf Zimmermann) Date: Wed Jul 2 07:07:04 2008 Subject: no serial console for ttyd0 HP Blade In-Reply-To: <3AC5DAEE-95F1-4211-A819-CC085DD180ED@netconsonance.com> References: <29641b38fd128219d11b0a910949a68c@localhost> <3AC5DAEE-95F1-4211-A819-CC085DD180ED@netconsonance.com> Message-ID: <20080702063651.GD69034@evil.alameda.net> Also remember that the blades have 2 serial ports, one can be accessed via a dongle in the front of the blade and I believe that is what usual would be called COM1 by default. The virtual serial via ilo takes up the COM2 by default. This is at least the default on DL series servers and I haven't checked into using the virtual serial on the Blades we have. On Tue, Jul 01, 2008 at 09:42:16PM -0700, Jo Rhett wrote: > This rhymes with sio deciding that your TTY is something other than > ttyd0. We had this same problem on Rackable -- even though the proper > tty was setup 0x3f8 irq 4 it was being assigned to sio1. You can see > this by 'grep sio /var/log/messages' > > The only fix for this is to edit /boot/device.hints and reassign the > flags to the sio1 interface, like so: > > hint.sio.1.at="isa" > hint.sio.1.port="0x3F8" > hint.sio.1.flags="0x10" > hint.sio.1.irq="4" > hint.sio.0.at="isa" > hint.sio.0.port="0x2F8" > hint.sio.0.irq="3" > > On Jul 1, 2008, at 8:23 AM, Marian Hettwer wrote: > >I installed a recent (as of today) RELENG_7 on one of our HP Blades. > >Unluckily my serial output stops right when a getty at ttyd0 should > >kick > >in. So I'm blind for the rest of the startup. > >Very unfortunate. > >The boot menu, as the bootup itself is printed out on serial console > >until: > >da0: Fixed Direct Access SCSI-5 device > >da0: 135.168MB/s transfers > >da0: 139947MB (286611840 512 byte sectors: 255H 32S/T 35124C) > >Trying to mount root from ufs:/dev/da0s1a > >bce0: link state changed to DOWN > >bce0: link state changed to UP > >bce1: link state changed to UP > > > >Which is, what I think, the point when init should take over and > >spawn a > >serial console on ttyd0, according to my /etc/ttys: > ># grep ttyd0 /etc/ttys > >ttyd0 "/usr/libexec/getty std.9600" vt100 on secure > > > ># cat /boot/loader.conf > >comconsole_speed="9600" > >console="vidconsole,comconsole" # A comma separated list of > >console(s) > >boot_multicons="-D" # -D: Use multiple consoles > >boot_serial="-h" # -h: Use serial console > > > ># uname -a > >FreeBSD db46-202.mobile.rz 7.0-STABLE FreeBSD 7.0-STABLE #0: Tue > >Jul 1 > >14:59:43 CEST 2008 root@db46-202.mobile.rz:/usr/obj/usr/src/sys/ > >GENERIC > >amd64 > > > >The blade itself is a HP BL465c G5 > > > >Any ideas? I don't have this blade for a long time, so I'm a bit in a > >hurry. > >In fact, right now I'm testing this setup against a Debian 4.0 with > >Linux > >2.6.25.9 under MySQL load, and up until now the machine looks good. > >If I wind up with a fully working, nearly as fast and stable as our > >linux > >boxes installation, I'd might be able to convince "the boys at work" > >to > >give FreeBSD a try. > >And in a 600 server setup, I'd be thrilled to do so :-) > >So lets get started with this serial console issue... which is > >indeed a > >pain :( > > > >TIA, > >Marian > > > >_______________________________________________ > >freebsd-stable@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > >" > > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source > and other randomness > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://www.Alameda.net/~ulf/resume.html From ulf at Alameda.net Wed Jul 2 07:06:56 2008 From: ulf at Alameda.net (Ulf Zimmermann) Date: Wed Jul 2 07:07:05 2008 Subject: no serial console for ttyd0 HP Blade In-Reply-To: <20080702063651.GD69034@evil.alameda.net> References: <29641b38fd128219d11b0a910949a68c@localhost> <3AC5DAEE-95F1-4211-A819-CC085DD180ED@netconsonance.com> <20080702063651.GD69034@evil.alameda.net> Message-ID: <20080702063837.GE69034@evil.alameda.net> I take that back, on blades the virtual serial is on COM1. On Tue, Jul 01, 2008 at 11:36:51PM -0700, Ulf Zimmermann wrote: > Also remember that the blades have 2 serial ports, one can be accessed via > a dongle in the front of the blade and I believe that is what usual would be > called COM1 by default. The virtual serial via ilo takes up the COM2 by > default. This is at least the default on DL series servers and I haven't > checked into using the virtual serial on the Blades we have. > > On Tue, Jul 01, 2008 at 09:42:16PM -0700, Jo Rhett wrote: > > This rhymes with sio deciding that your TTY is something other than > > ttyd0. We had this same problem on Rackable -- even though the proper > > tty was setup 0x3f8 irq 4 it was being assigned to sio1. You can see > > this by 'grep sio /var/log/messages' > > > > The only fix for this is to edit /boot/device.hints and reassign the > > flags to the sio1 interface, like so: > > > > hint.sio.1.at="isa" > > hint.sio.1.port="0x3F8" > > hint.sio.1.flags="0x10" > > hint.sio.1.irq="4" > > hint.sio.0.at="isa" > > hint.sio.0.port="0x2F8" > > hint.sio.0.irq="3" > > > > On Jul 1, 2008, at 8:23 AM, Marian Hettwer wrote: > > >I installed a recent (as of today) RELENG_7 on one of our HP Blades. > > >Unluckily my serial output stops right when a getty at ttyd0 should > > >kick > > >in. So I'm blind for the rest of the startup. > > >Very unfortunate. > > >The boot menu, as the bootup itself is printed out on serial console > > >until: > > >da0: Fixed Direct Access SCSI-5 device > > >da0: 135.168MB/s transfers > > >da0: 139947MB (286611840 512 byte sectors: 255H 32S/T 35124C) > > >Trying to mount root from ufs:/dev/da0s1a > > >bce0: link state changed to DOWN > > >bce0: link state changed to UP > > >bce1: link state changed to UP > > > > > >Which is, what I think, the point when init should take over and > > >spawn a > > >serial console on ttyd0, according to my /etc/ttys: > > ># grep ttyd0 /etc/ttys > > >ttyd0 "/usr/libexec/getty std.9600" vt100 on secure > > > > > ># cat /boot/loader.conf > > >comconsole_speed="9600" > > >console="vidconsole,comconsole" # A comma separated list of > > >console(s) > > >boot_multicons="-D" # -D: Use multiple consoles > > >boot_serial="-h" # -h: Use serial console > > > > > ># uname -a > > >FreeBSD db46-202.mobile.rz 7.0-STABLE FreeBSD 7.0-STABLE #0: Tue > > >Jul 1 > > >14:59:43 CEST 2008 root@db46-202.mobile.rz:/usr/obj/usr/src/sys/ > > >GENERIC > > >amd64 > > > > > >The blade itself is a HP BL465c G5 > > > > > >Any ideas? I don't have this blade for a long time, so I'm a bit in a > > >hurry. > > >In fact, right now I'm testing this setup against a Debian 4.0 with > > >Linux > > >2.6.25.9 under MySQL load, and up until now the machine looks good. > > >If I wind up with a fully working, nearly as fast and stable as our > > >linux > > >boxes installation, I'd might be able to convince "the boys at work" > > >to > > >give FreeBSD a try. > > >And in a 600 server setup, I'd be thrilled to do so :-) > > >So lets get started with this serial console issue... which is > > >indeed a > > >pain :( > > > > > >TIA, > > >Marian > > > > > >_______________________________________________ > > >freebsd-stable@freebsd.org mailing list > > >http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > >To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > > >" > > > > -- > > Jo Rhett > > Net Consonance : consonant endings by net philanthropy, open source > > and other randomness > > > > > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > > -- > Regards, Ulf. > > --------------------------------------------------------------------- > Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 > You can find my resume at: http://www.Alameda.net/~ulf/resume.html -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://www.Alameda.net/~ulf/resume.html From jrhett at netconsonance.com Wed Jul 2 07:16:47 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed Jul 2 07:16:52 2008 Subject: no serial console for ttyd0 HP Blade In-Reply-To: <20080702063837.GE69034@evil.alameda.net> References: <29641b38fd128219d11b0a910949a68c@localhost> <3AC5DAEE-95F1-4211-A819-CC085DD180ED@netconsonance.com> <20080702063651.GD69034@evil.alameda.net> <20080702063837.GE69034@evil.alameda.net> Message-ID: I'll bet you that sio is deciding that com1 or not, it's sio1 (not sio0) which can be fixed with the changes I mention below. On Jul 1, 2008, at 11:38 PM, Ulf Zimmermann wrote: > I take that back, on blades the virtual serial is on COM1. > > On Tue, Jul 01, 2008 at 11:36:51PM -0700, Ulf Zimmermann wrote: >> Also remember that the blades have 2 serial ports, one can be >> accessed via >> a dongle in the front of the blade and I believe that is what usual >> would be >> called COM1 by default. The virtual serial via ilo takes up the >> COM2 by >> default. This is at least the default on DL series servers and I >> haven't >> checked into using the virtual serial on the Blades we have. >> >> On Tue, Jul 01, 2008 at 09:42:16PM -0700, Jo Rhett wrote: >>> This rhymes with sio deciding that your TTY is something other than >>> ttyd0. We had this same problem on Rackable -- even though the >>> proper >>> tty was setup 0x3f8 irq 4 it was being assigned to sio1. You can >>> see >>> this by 'grep sio /var/log/messages' >>> >>> The only fix for this is to edit /boot/device.hints and reassign the >>> flags to the sio1 interface, like so: >>> >>> hint.sio.1.at="isa" >>> hint.sio.1.port="0x3F8" >>> hint.sio.1.flags="0x10" >>> hint.sio.1.irq="4" >>> hint.sio.0.at="isa" >>> hint.sio.0.port="0x2F8" >>> hint.sio.0.irq="3" >>> >>> On Jul 1, 2008, at 8:23 AM, Marian Hettwer wrote: >>>> I installed a recent (as of today) RELENG_7 on one of our HP >>>> Blades. >>>> Unluckily my serial output stops right when a getty at ttyd0 should >>>> kick >>>> in. So I'm blind for the rest of the startup. >>>> Very unfortunate. >>>> The boot menu, as the bootup itself is printed out on serial >>>> console >>>> until: >>>> da0: Fixed Direct Access SCSI-5 device >>>> da0: 135.168MB/s transfers >>>> da0: 139947MB (286611840 512 byte sectors: 255H 32S/T 35124C) >>>> Trying to mount root from ufs:/dev/da0s1a >>>> bce0: link state changed to DOWN >>>> bce0: link state changed to UP >>>> bce1: link state changed to UP >>>> >>>> Which is, what I think, the point when init should take over and >>>> spawn a >>>> serial console on ttyd0, according to my /etc/ttys: >>>> # grep ttyd0 /etc/ttys >>>> ttyd0 "/usr/libexec/getty std.9600" vt100 on secure >>>> >>>> # cat /boot/loader.conf >>>> comconsole_speed="9600" >>>> console="vidconsole,comconsole" # A comma separated list of >>>> console(s) >>>> boot_multicons="-D" # -D: Use multiple consoles >>>> boot_serial="-h" # -h: Use serial console >>>> >>>> # uname -a >>>> FreeBSD db46-202.mobile.rz 7.0-STABLE FreeBSD 7.0-STABLE #0: Tue >>>> Jul 1 >>>> 14:59:43 CEST 2008 root@db46-202.mobile.rz:/usr/obj/usr/src/ >>>> sys/ >>>> GENERIC >>>> amd64 >>>> >>>> The blade itself is a HP BL465c G5 >>>> >>>> Any ideas? I don't have this blade for a long time, so I'm a bit >>>> in a >>>> hurry. >>>> In fact, right now I'm testing this setup against a Debian 4.0 with >>>> Linux >>>> 2.6.25.9 under MySQL load, and up until now the machine looks good. >>>> If I wind up with a fully working, nearly as fast and stable as our >>>> linux >>>> boxes installation, I'd might be able to convince "the boys at >>>> work" >>>> to >>>> give FreeBSD a try. >>>> And in a 600 server setup, I'd be thrilled to do so :-) >>>> So lets get started with this serial console issue... which is >>>> indeed a >>>> pain :( >>>> >>>> TIA, >>>> Marian >>>> >>>> _______________________________________________ >>>> freebsd-stable@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org >>>> " >>> >>> -- >>> Jo Rhett >>> Net Consonance : consonant endings by net philanthropy, open source >>> and other randomness >>> >>> >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org >>> " >>> >> >> -- >> Regards, Ulf. >> >> --------------------------------------------------------------------- >> Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 >> You can find my resume at: http://www.Alameda.net/~ulf/resume.html > > -- > Regards, Ulf. > > --------------------------------------------------------------------- > Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 > You can find my resume at: http://www.Alameda.net/~ulf/resume.html -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From bu7cher at yandex.ru Wed Jul 2 07:17:56 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Wed Jul 2 07:18:01 2008 Subject: MCP55 SATA data corruption in FreeBSD 7 In-Reply-To: <4F9C9299A10AE74E89EA580D14AA10A61A196F@royal64.emp.zapto.org> References: <4F9C9299A10AE74E89EA580D14AA10A61A196C@royal64.emp.zapto.org> <486AFB78.5030905@yandex.ru> <4F9C9299A10AE74E89EA580D14AA10A61A196F@royal64.emp.zapto.org> Message-ID: <486B2B9C.2080007@yandex.ru> Daniel Eriksson wrote: >> I have two motherboards with MCP55. They work well and I didn't >> see any data corruption. > > Do you have SATA-150 or SATA-300 drives connected to the motherboards? All drives are SATA-300: FreeBSD 6.2: 1x WDC WD3200YS-01PGB0/21.00M21 FreeBSD 8.0: 5x WDC WD5001ABYS-01YNA0/59.01D01 1x WDC WD1200JS-00MHB0/02.01C03 -- WBR, Andrey V. Elsukov From koitsu at FreeBSD.org Wed Jul 2 07:27:42 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Jul 2 07:27:46 2008 Subject: no serial console for ttyd0 HP Blade In-Reply-To: References: <29641b38fd128219d11b0a910949a68c@localhost> <3AC5DAEE-95F1-4211-A819-CC085DD180ED@netconsonance.com> <20080702063651.GD69034@evil.alameda.net> <20080702063837.GE69034@evil.alameda.net> Message-ID: <20080702072741.GA45396@eos.sc1.parodius.com> On Wed, Jul 02, 2008 at 12:16:41AM -0700, Jo Rhett wrote: > I'll bet you that sio is deciding that com1 or not, it's sio1 (not sio0) > which can be fixed with the changes I mention below. > > On Jul 1, 2008, at 11:38 PM, Ulf Zimmermann wrote: >> I take that back, on blades the virtual serial is on COM1. I agree with Joe. Chances are it may be "COM1" in the BIOS, but it may be actually wired to the equivalent of COM2. Or, the blade manufacturer set the ACPI table to point 0x3f8/4 to COM2 and 0x2f8/3 to COM1. I've seen this on one Supermicro board (front panel COM port is COM2, rear is COM1; but no mention of what's what in the manual. You actually have to experiment to find out.) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Wed Jul 2 07:28:27 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Jul 2 07:28:30 2008 Subject: MCP55 SATA data corruption in FreeBSD 7 In-Reply-To: <486B2B9C.2080007@yandex.ru> References: <4F9C9299A10AE74E89EA580D14AA10A61A196C@royal64.emp.zapto.org> <486AFB78.5030905@yandex.ru> <4F9C9299A10AE74E89EA580D14AA10A61A196F@royal64.emp.zapto.org> <486B2B9C.2080007@yandex.ru> Message-ID: <20080702072826.GB45396@eos.sc1.parodius.com> On Wed, Jul 02, 2008 at 11:17:48AM +0400, Andrey V. Elsukov wrote: > Daniel Eriksson wrote: >>> I have two motherboards with MCP55. They work well and I didn't >>> see any data corruption. >> >> Do you have SATA-150 or SATA-300 drives connected to the motherboards? > > All drives are SATA-300: > FreeBSD 6.2: > 1x WDC WD3200YS-01PGB0/21.00M21 > FreeBSD 8.0: > 5x WDC WD5001ABYS-01YNA0/59.01D01 > 1x WDC WD1200JS-00MHB0/02.01C03 Which makes me wonder if there's multiple revisions of the MCP55, or, if Samsung drives simply don't behave properly with that chipset (this has my vote). Can the OP get some non-Samsung disks for testing? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From iskander at apple-park.kiev.ua Wed Jul 2 07:33:16 2008 From: iskander at apple-park.kiev.ua (Alexander Vyrlanovich) Date: Wed Jul 2 07:33:19 2008 Subject: installdate of a port/package? In-Reply-To: References: Message-ID: Hi May be this will be useful for you (from man portupgrade): Rebuild and reinstall all that ports that were installed prior to the date 2001-09-20: portupgrade -f '<2001-09-20' On 1 ???? 2008, at 18:12, Ronald Klop wrote: > Hello, > > I just upgraded a machine from FreeBSD 6 to 7. Very nice. > But my portupgrade -fa failed after a while. > How can I know which ports/packages are still from FreeBSD 6? Is > there a datee recorded somewhere or the FreeBSD-version of the port/ > package? > The date of the files in /var/db/pkg/* is unreliable, because > installing a package gives these files the date of the files in the > package. > > How do I know which ports I still need to update? > > Ronald. > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable- > unsubscribe@freebsd.org" From bu7cher at yandex.ru Wed Jul 2 07:34:49 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Wed Jul 2 07:34:55 2008 Subject: MCP55 SATA data corruption in FreeBSD 7 In-Reply-To: <20080702072826.GB45396@eos.sc1.parodius.com> References: <4F9C9299A10AE74E89EA580D14AA10A61A196C@royal64.emp.zapto.org> <486AFB78.5030905@yandex.ru> <4F9C9299A10AE74E89EA580D14AA10A61A196F@royal64.emp.zapto.org> <486B2B9C.2080007@yandex.ru> <20080702072826.GB45396@eos.sc1.parodius.com> Message-ID: <486B2F8F.70801@yandex.ru> Jeremy Chadwick wrote: > Which makes me wonder if there's multiple revisions of the MCP55, or, if > Samsung drives simply don't behave properly with that chipset (this has > my vote). Daniel has the same revision (as I can see from pciconf). -- WBR, Andrey V. Elsukov From mh at kernel32.de Wed Jul 2 07:53:11 2008 From: mh at kernel32.de (Marian Hettwer) Date: Wed Jul 2 07:53:15 2008 Subject: no serial console for ttyd0 HP Blade In-Reply-To: <3AC5DAEE-95F1-4211-A819-CC085DD180ED@netconsonance.com> References: <3AC5DAEE-95F1-4211-A819-CC085DD180ED@netconsonance.com> Message-ID: Hi there, On Tue, 1 Jul 2008 21:42:16 -0700, Jo Rhett wrote: > This rhymes with sio deciding that your TTY is something other than > ttyd0. We had this same problem on Rackable -- even though the proper > tty was setup 0x3f8 irq 4 it was being assigned to sio1. You can see > this by 'grep sio /var/log/messages' > Well no, it seems the irq assignment for sioX is okay: Jul 1 15:13:57 db46-202 kernel: sio0: configured irq 3 not in bitmap of probed irqs 0 Jul 1 15:13:57 db46-202 kernel: sio0: port may not be enabled Jul 1 15:13:57 db46-202 kernel: sio0: configured irq 3 not in bitmap of probed irqs 0 Jul 1 15:13:57 db46-202 kernel: sio0: port may not be enabled Jul 1 15:13:57 db46-202 kernel: sio0: port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0 Jul 1 15:13:57 db46-202 kernel: sio0: type 16550A, console Jul 1 15:13:57 db46-202 kernel: sio0: [FILTER] On the other hand... port may not be enabled doesn't sound good, hm? And in the end it gets irq3 at port 0x2f8 > The only fix for this is to edit /boot/device.hints and reassign the > flags to the sio1 interface, like so: > > hint.sio.1.at="isa" > hint.sio.1.port="0x3F8" > hint.sio.1.flags="0x10" > hint.sio.1.irq="4" > hint.sio.0.at="isa" > hint.sio.0.port="0x2F8" > hint.sio.0.irq="3" > Looks reasonable to me. I'll give it a shot. Thank you :) best regards, Marian > On Jul 1, 2008, at 8:23 AM, Marian Hettwer wrote: >> I installed a recent (as of today) RELENG_7 on one of our HP Blades. >> Unluckily my serial output stops right when a getty at ttyd0 should >> kick >> in. So I'm blind for the rest of the startup. >> Very unfortunate. >> The boot menu, as the bootup itself is printed out on serial console >> until: >> da0: Fixed Direct Access SCSI-5 device >> da0: 135.168MB/s transfers >> da0: 139947MB (286611840 512 byte sectors: 255H 32S/T 35124C) >> Trying to mount root from ufs:/dev/da0s1a >> bce0: link state changed to DOWN >> bce0: link state changed to UP >> bce1: link state changed to UP >> >> Which is, what I think, the point when init should take over and >> spawn a >> serial console on ttyd0, according to my /etc/ttys: >> # grep ttyd0 /etc/ttys >> ttyd0 "/usr/libexec/getty std.9600" vt100 on secure >> >> # cat /boot/loader.conf >> comconsole_speed="9600" >> console="vidconsole,comconsole" # A comma separated list of >> console(s) >> boot_multicons="-D" # -D: Use multiple consoles >> boot_serial="-h" # -h: Use serial console >> >> # uname -a >> FreeBSD db46-202.mobile.rz 7.0-STABLE FreeBSD 7.0-STABLE #0: Tue >> Jul 1 >> 14:59:43 CEST 2008 root@db46-202.mobile.rz:/usr/obj/usr/src/sys/ >> GENERIC >> amd64 >> >> The blade itself is a HP BL465c G5 >> >> Any ideas? I don't have this blade for a long time, so I'm a bit in a >> hurry. >> In fact, right now I'm testing this setup against a Debian 4.0 with >> Linux >> 2.6.25.9 under MySQL load, and up until now the machine looks good. >> If I wind up with a fully working, nearly as fast and stable as our >> linux >> boxes installation, I'd might be able to convince "the boys at work" >> to >> give FreeBSD a try. >> And in a 600 server setup, I'd be thrilled to do so :-) >> So lets get started with this serial console issue... which is >> indeed a >> pain :( >> >> TIA, >> Marian >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org >> " > > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source > and other randomness > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From mh at kernel32.de Wed Jul 2 07:55:10 2008 From: mh at kernel32.de (Marian Hettwer) Date: Wed Jul 2 07:55:13 2008 Subject: no serial console for ttyd0 HP Blade In-Reply-To: <20080702063651.GD69034@evil.alameda.net> References: <20080702063651.GD69034@evil.alameda.net> Message-ID: Hi there, On Tue, 1 Jul 2008 23:36:51 -0700, Ulf Zimmermann wrote: > Also remember that the blades have 2 serial ports, one can be accessed via > a dongle in the front of the blade and I believe that is what usual would > be > called COM1 by default. The virtual serial via ilo takes up the COM2 by > default. This is at least the default on DL series servers and I haven't > checked into using the virtual serial on the Blades we have. > Well, I enabled ttyd1 too in /etc/ttys and gave init a kill -HUP: [root@db46-202.mobile.rz] <~>ps ax | grep ttyd [9:54:02 on 08-07-02] 7888 ?? S 0:00.01 /usr/libexec/getty std.9600 ttyd1 961 d0 Is+ 0:00.00 /usr/libexec/getty std.9600 ttyd0 But no login prompt, though... regards, Marian From mh at kernel32.de Wed Jul 2 07:57:00 2008 From: mh at kernel32.de (Marian Hettwer) Date: Wed Jul 2 07:57:03 2008 Subject: no serial console for ttyd0 HP Blade In-Reply-To: <20080702072741.GA45396@eos.sc1.parodius.com> References: <20080702072741.GA45396@eos.sc1.parodius.com> Message-ID: <08575f4ae13d3599f2aa3e23865ade67@localhost> Hi Jeremy, On Wed, 2 Jul 2008 00:27:41 -0700, Jeremy Chadwick wrote: > On Wed, Jul 02, 2008 at 12:16:41AM -0700, Jo Rhett wrote: >> I'll bet you that sio is deciding that com1 or not, it's sio1 (not sio0) >> which can be fixed with the changes I mention below. >> >> On Jul 1, 2008, at 11:38 PM, Ulf Zimmermann wrote: >>> I take that back, on blades the virtual serial is on COM1. > > I agree with Joe. Chances are it may be "COM1" in the BIOS, but it may > be actually wired to the equivalent of COM2. Or, the blade manufacturer > set the ACPI table to point 0x3f8/4 to COM2 and 0x2f8/3 to COM1. > Ack. > I've seen this on one Supermicro board (front panel COM port is COM2, > rear is COM1; but no mention of what's what in the manual. You actually > have to experiment to find out.) > I'll do so. However, I do wonder why the serial console works in boot loader and kernel bootup stage? Any explanation? :) regards, Marian From mh at kernel32.de Wed Jul 2 08:05:01 2008 From: mh at kernel32.de (Marian Hettwer) Date: Wed Jul 2 08:05:04 2008 Subject: no serial console for ttyd0 HP Blade In-Reply-To: References: Message-ID: <62befb2b24054f59734de3d2b21b9417@localhost> On Wed, 2 Jul 2008 00:16:41 -0700, Jo Rhett wrote: > I'll bet you that sio is deciding that com1 or not, it's sio1 (not > sio0) which can be fixed with the changes I mention below. > puuuh, well, with your suggested change, I do get a login prompt now (at ttyd1 it says), but I don't see any bootup messages anymore. It seems that the sio0 is irq 4 while booting and becomes irq3 later. That's odd. If I remember correctly, one was able to configure the mapping of serial ports in the BIOS (in regards to those HP blades). Perhaps that helps. I'll give it a shot and if I found a way to have boot messages and the login getty, I'll drop a [solved] mail to this list. Anyway, thanks all so far :-) regards, Marian From jrhett at netconsonance.com Wed Jul 2 08:23:46 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed Jul 2 08:23:50 2008 Subject: no serial console for ttyd0 HP Blade In-Reply-To: <62befb2b24054f59734de3d2b21b9417@localhost> References: <62befb2b24054f59734de3d2b21b9417@localhost> Message-ID: On Jul 2, 2008, at 1:04 AM, Marian Hettwer wrote: > puuuh, well, with your suggested change, I do get a login prompt now > (at > ttyd1 it says), but I don't see any bootup messages anymore. > It seems that the sio0 is irq 4 while booting and becomes irq3 later. > That's odd. > If I remember correctly, one was able to configure the mapping of > serial > ports in the BIOS (in regards to those HP blades). Perhaps that helps. > I'll give it a shot and if I found a way to have boot messages and the > login getty, I'll drop a [solved] mail to this list. So the boot loader uses 0x3f8 irq 4 no matter what it's mapped to. Second stage does something similar, but After you've loaded the kernel it does mappings to sio0 and sio1 and these may be different. This is why you have to screw with device.hints so that all three stages are using the same device. > Jul 1 15:13:57 db46-202 kernel: sio0: port > 0x2f8-0x2ff irq 3 flags 0x10 on acpi0 It's pretty clear from your grep command that sio0 is 0x2f8 irq 3, but the boot loader always uses 0x3f8 irq 4. You have to change these until the device which has 0x3f8 irq 4 has the "flags 0x10" option, which is what makes it the console. NOTE: I think this whole parade sucks, and the kernel should believe device.hints ... but there is no apparent interest in solving this problem (even when a bounty is offered), and I don't do enough device driver development these days for it to be worth my time. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From daniel_k_eriksson at telia.com Wed Jul 2 08:55:10 2008 From: daniel_k_eriksson at telia.com (Daniel Eriksson) Date: Wed Jul 2 08:55:14 2008 Subject: MCP55 SATA data corruption in FreeBSD 7 In-Reply-To: <20080702072826.GB45396@eos.sc1.parodius.com> References: <4F9C9299A10AE74E89EA580D14AA10A61A196C@royal64.emp.zapto.org> <486AFB78.5030905@yandex.ru> <4F9C9299A10AE74E89EA580D14AA10A61A196F@royal64.emp.zapto.org> <486B2B9C.2080007@yandex.ru> <20080702072826.GB45396@eos.sc1.parodius.com> Message-ID: <4F9C9299A10AE74E89EA580D14AA10A61A1970@royal64.emp.zapto.org> Jeremy Chadwick wrote: > Can the OP get some non-Samsung disks for testing? I've got a 750 GB Western Digital that I've been planning to use to verify if it's a SATA-150 / SATA-300 problem (it can be jumpered to SATA-150), but the drive is packed with valuable data that I'd have to move elsewhere first. I'll get to it eventually, but maybe not this week. ___ Daniel Eriksson (http://www.toomuchdata.com/) From joao at matik.com.br Wed Jul 2 11:33:22 2008 From: joao at matik.com.br (JoaoBR) Date: Wed Jul 2 11:33:27 2008 Subject: kern.cp_time wrong with phenoms Message-ID: <200807020833.01149.joao@matik.com.br> Hi kern.cp_time seems is reporting wrong values (most time too high) with Phenom and amd64 (i386 Ido not know) but with snmpget I get the correct machine values when consulting ssCpuRawUser.0 ssCpuRawNice.0 ssCpuRawSystem.0 ssCpuRawInterrupt.0 ssCpuRawIdle.0 kern.cp_time on RELENG6 reports correct with same hardware -- Jo?o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From marcus at blazingdot.com Wed Jul 2 12:00:03 2008 From: marcus at blazingdot.com (Marcus Reid) Date: Wed Jul 2 12:00:10 2008 Subject: msync() differences between Linux and FreeBSD Message-ID: <20080702120002.GB65355@blazingdot.com> Hi, I recently had a patch accepted to the ports collection that took out an msync() call that seriously detrimented performance for rrdtool updates. It seems that in FreeBSD, msync() waits for bits to be committed to disk even when MS_ASYNC is specified. Under Linux, there is not such a wait for msync(). First off, I don't know how frequently msync() is used, and whether changing its behavior would impact the performance of many things. It's possible that FreeBSD msync() behavior is more correct in some ways. From a message from Matt Dillon on this same list: It used to be that msync() only synced VM pages to the underlying file, making them consistent with read()'s and write()'s against the underlying file. Since FreeBSD uses a unified VM page cache this is always true. However, the Open Group specification now requires that the dirty pages actually be written out to the underlying media... i.e. issue real I/O. So msync() can't be a NOP if you go by the OpenGroup specification. Is there a spec that FreeBSD is adhering to that prevents msync() with MS_ASYNC from being a NOP, seeing as munmap() does the job? And does this really matter for the real-world performance of some apps? Thanks, Marcus From utisoft at googlemail.com Wed Jul 2 15:42:02 2008 From: utisoft at googlemail.com (Chris Rees) Date: Wed Jul 2 15:42:08 2008 Subject: MCP55 SATA data corruption in FreeBSD 7 Message-ID: > Date: Wed, 2 Jul 2008 10:55:07 +0200 > "Daniel Eriksson" wrote: > Jeremy Chadwick wrote: > >> Can the OP get some non-Samsung disks for testing? > > I've got a 750 GB Western Digital that I've been planning to use to > verify if it's a SATA-150 / SATA-300 problem (it can be jumpered to > SATA-150), but the drive is packed with valuable data that I'd have to > move elsewhere first. > > I'll get to it eventually, but maybe not this week. > > ___ > Daniel Eriksson (http://www.toomuchdata.com/) > Looks like I'm the guinea pig for now, I'll post in about half an hour with the results :) This is a clean install; it works perfectly with the restriction jumper on, now it comes off. Chris From graham at menhennitt.com.au Wed Jul 2 17:35:21 2008 From: graham at menhennitt.com.au (Graham Menhennitt) Date: Wed Jul 2 17:35:26 2008 Subject: installdate of a port/package? In-Reply-To: References: Message-ID: <486AAB93.1050606@menhennitt.com.au> Ronald Klop wrote: > I just upgraded a machine from FreeBSD 6 to 7. Very nice. > But my portupgrade -fa failed after a while. > ... > How do I know which ports I still need to update? Run "portupgrade -fan" and see which ones it says still need upgrading. Graham From sam at freebsd.org Wed Jul 2 20:12:00 2008 From: sam at freebsd.org (Sam Leffler) Date: Wed Jul 2 20:12:03 2008 Subject: Atheros (ath) MSI wireless embedded chipset fails to attach on 7.0-STABLE In-Reply-To: <3c0b01820806170757v5565b59ne0e9d5db06f26761@mail.gmail.com> References: <3c0b01820806170757v5565b59ne0e9d5db06f26761@mail.gmail.com> Message-ID: <486BDCE9.3000608@freebsd.org> Alexander Sack wrote: > Hello: > > I have installed FreeBSD-7.0-amd64 stable on my new AMD X2 Turon based > notebook, a MSI-1710A (GX710Ax) which has a generic embedded > controller. During boot up I notice that ATH complains with: > > ath_rate: version 1.2 > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > ath0: mem 0xfd7f0000-0xfd7fffff irq 16 at device 0.0 on pci2 > ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfd7f0000 > ath0: [MPSAFE] > ath0: [ITHREAD] > ath0: unable to attach hardware; HAL status 13 > device_attach: ath0 attach returned 6 > > HAL status 13 from the header file seems to indicate that the > 7.0-STABLE driver doesn't support my hardware revision. Here is my > pciconf -l output: > > hostb0@pci0:0:0:0: class=0x060000 card=0x42cd1462 chip=0x79101002 > rev=0x00 hdr=0x00 > pcib1@pci0:0:2:0: class=0x060400 card=0x42cd1462 chip=0x79131002 > rev=0x00 hdr=0x01 > pcib2@pci0:0:4:0: class=0x060400 card=0x42cd1462 chip=0x79141002 > rev=0x00 hdr=0x01 > pcib3@pci0:0:6:0: class=0x060400 card=0x42cd1462 chip=0x79161002 > rev=0x00 hdr=0x01 > pcib4@pci0:0:7:0: class=0x060400 card=0x42cd1462 chip=0x79171002 > rev=0x00 hdr=0x01 > atapci0@pci0:0:18:0: class=0x01018f card=0x42cd1462 chip=0x43801002 > rev=0x00 hdr=0x00 > ohci0@pci0:0:19:0: class=0x0c0310 card=0x42cd1462 chip=0x43871002 > rev=0x00 hdr=0x00 > ohci1@pci0:0:19:1: class=0x0c0310 card=0x42cd1462 chip=0x43881002 > rev=0x00 hdr=0x00 > ohci2@pci0:0:19:2: class=0x0c0310 card=0x42cd1462 chip=0x43891002 > rev=0x00 hdr=0x00 > ohci3@pci0:0:19:3: class=0x0c0310 card=0x42cd1462 chip=0x438a1002 > rev=0x00 hdr=0x00 > ohci4@pci0:0:19:4: class=0x0c0310 card=0x42cd1462 chip=0x438b1002 > rev=0x00 hdr=0x00 > ehci0@pci0:0:19:5: class=0x0c0320 card=0x42cd1462 chip=0x43861002 > rev=0x00 hdr=0x00 > none0@pci0:0:20:0: class=0x0c0500 card=0x42cd1462 chip=0x43851002 > rev=0x14 hdr=0x00 > atapci1@pci0:0:20:1: class=0x01018a card=0x42cd1462 chip=0x438c1002 > rev=0x00 hdr=0x00 > none1@pci0:0:20:2: class=0x040300 card=0x42cd1462 chip=0x43831002 > rev=0x00 hdr=0x00 > isab0@pci0:0:20:3: class=0x060100 card=0x42cd1462 chip=0x438d1002 > rev=0x00 hdr=0x00 > pcib5@pci0:0:20:4: class=0x060401 card=0x00000000 chip=0x43841002 > rev=0x00 hdr=0x01 > hostb1@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 > rev=0x00 hdr=0x00 > hostb2@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 > rev=0x00 hdr=0x00 > hostb3@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 > rev=0x00 hdr=0x00 > hostb4@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 > rev=0x00 hdr=0x00 > vgapci0@pci0:1:0:0: class=0x030000 card=0x42cd1462 chip=0x95811002 > rev=0x00 hdr=0x00 > none2@pci0:1:0:1: class=0x040300 card=0xaa081462 chip=0xaa081002 > rev=0x00 hdr=0x00 > ath0@pci0:2:0:0: class=0x020000 card=0x10261a3b chip=0x001c168c > rev=0x01 hdr=0x00 > re0@pci0:5:0:0: class=0x020000 card=0x42cd1462 chip=0x816810ec rev=0x01 hdr=0x00 > cbb0@pci0:6:4:0: class=0x060700 card=0x42cd1462 chip=0x71341217 > rev=0x21 hdr=0x02 > none3@pci0:6:4:2: class=0x080500 card=0x42cd1462 chip=0x71201217 > rev=0x01 hdr=0x00 > none4@pci0:6:4:3: class=0x068000 card=0x42cd1462 chip=0x71301217 > rev=0x01 hdr=0x00 > fwohci0@pci0:6:4:4: class=0x0c0010 card=0x42cd1462 chip=0x00f71217 > rev=0x02 hdr=0x00 > > ath0 is listed as rev=0x01 so I'm a little confused why I got HAL > status 13. Does anyone know if this chipset is supported in > 7.0-STABLE? If not, is it possible to try CURRENT on 7.0 which may > fix it? I've attached my complete dmesg output. > > Again, any feedback would be much appreciated! > > Try the hal in http://www.freebsd.org/~sam. Sam From beaker at hot.pl Wed Jul 2 23:25:33 2008 From: beaker at hot.pl (=?ISO-8859-2?Q?Krzysztof_J=EAdruczyk?=) Date: Wed Jul 2 23:25:38 2008 Subject: Marvell Yukon 88E8062 - media selection problem In-Reply-To: <20080702010929.GA87933@cdnetworks.co.kr> References: <1052423937.20080630135423@hot.pl> <20080701004855.GF83626@cdnetworks.co.kr> <486A07A4.1070406@hot.pl> <20080702010929.GA87933@cdnetworks.co.kr> Message-ID: <486C0E69.8020603@hot.pl> Pyun YongHyeon pisze: > Would you try attached patch? > The patch is just for checking code path of fiber media. It's slightly better - some media gets detected, but looks weird to me (and doesn't communicate with other machines on the switch): # ifconfig msk0: flags=8802 metric 0 mtu 1500 options=11a ether 00:10:f3:0d:d6:45 media: Ethernet autoselect (autoselect ) status: active msk1: flags=8802 metric 0 mtu 1500 options=11a ether 00:10:f3:0d:d6:46 media: Ethernet autoselect (autoselect ) status: active 'autoselect (autoselect )' doesn't seem right to me... I couldn't see any signs of interface being functional with neither ping nor tcpdump... I tried the patch with 7.0-RELEASE-p2, -STABLE and -CURRENT kernels. I'm not sure how important is that, but I still can't force it to 1000baseSX: # ifconfig msk0 media 1000baseSX ifconfig: SIOCSIFMEDIA (media): Device not configured > > Btw, it looks like you have dual port controller, right? > Yes, this machine has dual gigabit ports: http://www.nexcom.com/ProductModel.aspx?id=7541ac3e-ecfd-4008-83cd-52e1ababe6a8 Let me know if there is any info I could provide that would help making this interface functional. -- Best regards, Krzysztof J?druczyk -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3221 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080702/51a3c0ab/smime.bin From utisoft at googlemail.com Wed Jul 2 23:35:01 2008 From: utisoft at googlemail.com (Chris Rees) Date: Wed Jul 2 23:35:06 2008 Subject: MCP55 SATA data corruption in FreeBSD 7 In-Reply-To: References: Message-ID: On 02/07/2008, Chris Rees wrote: > > Date: Wed, 2 Jul 2008 10:55:07 +0200 > > "Daniel Eriksson" wrote: > > Jeremy Chadwick wrote: > > > >> Can the OP get some non-Samsung disks for testing? > > > > I've got a 750 GB Western Digital that I've been planning to use to > > verify if it's a SATA-150 / SATA-300 problem (it can be jumpered to > > SATA-150), but the drive is packed with valuable data that I'd have to > > move elsewhere first. > > > > I'll get to it eventually, but maybe not this week. > > > > > ___ > > Daniel Eriksson (http://www.toomuchdata.com/) > > > > > Looks like I'm the guinea pig for now, I'll post in about half an hour > with the results :) > > This is a clean install; it works perfectly with the restriction > jumper on, now it comes off. > > > Chris > Real sorry fellas, can't reproduce on my M2N-SLI; chipset 570 SLI. I've been building ports for hours on here, everything's working perfectly I'm afraid. # pciconf -lv - snip - atapci1@pci0:0:5:0: class=0x010185 card=0x82391043 chip=0x037f10de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 SATA Controller' class = mass storage subclass = ATA - snip - # FreeBSD hydra.bayofrum.net 7.0-RELEASE-p2 FreeBSD 7.0-RELEASE-p2 #1: Wed Jul 2 16:50:49 UTC 2008 chris@hydra.bayofrum.net:/usr/obj/usr/src/sys/HYDRA amd64 Looks like mine's hardware revision (rev=) 0xa3; yours however is 0xa2. I had PS/2 port trouble on Linux, and needed a BIOS update, perhaps it came with that? Is the revision a firmware or hardware property? Good luck tracking that down, anyway, hope my tests helped :) Chris -- R< $&h ! > $- ! $+ $@ $2 < @ $1 .UUCP. > (sendmail.cf) From stef-list at memberwebs.com Thu Jul 3 00:39:59 2008 From: stef-list at memberwebs.com (Stef) Date: Thu Jul 3 00:40:04 2008 Subject: connect(): Operation not permitted References: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> <1211037564.6326.27.camel@porksoda> <679DB462-75D6-45CC-949C-1BE8E12C22CD@stromnet.se> <482FD877.6050707@infracaninophile.co.uk> Message-ID: <20080703003955.859BCF180C0@mx.npubs.com> Kian Mohageri wrote: > On Sun, May 18, 2008 at 3:33 AM, Johan Str?m wrote: >> On May 18, 2008, at 9:19 AM, Matthew Seaman wrote: >> >>> Johan Str?m wrote: >>> >>>> drop all traffic)? A check with pfctl -vsr reveals that the actual rule >>>> inserted is "pass on lo0 inet from 123.123.123.123 to 123.123.123.123 flags >>>> S/SA keep state". Where did that "keep state" come from? >>> 'flags S/SA keep state' is the default now for tcp filter rules -- that >>> was new in 7.0 reflecting the upstream changes made between the 4.0 and >>> 4.1 >>> releases of OpenBSD. If you want a stateless rule, append 'no state'. >>> >>> http://www.openbsd.org/faq/pf/filter.html#state >> Thanks! I was actually looking around in the pf.conf manpage but failed to >> find it yesterday, but looking closer today I now saw it. >> Applied the no state (and quick) to the rule, and now no state is created. >> And the problem I had in the first place seems to have been resolved too >> now, even though it didn't look like a state problem.. (started to deny new >> connections much earlier than the states was full, altough maybee i wasnt >> looking for updates fast enough or something). >> > > I'd be willing to bet it's because you're reusing the source port on a > new connection before the old state expires. > > You'll know if you check the state-mismatch counter. > > Anyway, glad you found a resolution. I've been experiencing this "Operation not permitted" too. I've been trying to track down the problem for many months, but due to the complexity of my firewalls (scores of jails each with scores of rules), I wasn't brave enough to ask for help :) As a work around we started creating rules without state, whenever we would run into the problem. Thanks for the pointer about state-mismatch. The state-mismatch counter does is in fact high in my case (see below). How would I go about getting the pf state timeout and the reuse of ports for outbound connections to match? Or is this an intractable problem, that just needs to be worked around? Cheers, Stef Walter Status: Enabled for 13 days 23:55:25 Debug: Urgent Hostid: 0x38ae6776 State Table Total Rate current entries 65 searches 819507771 677.7/s inserts 1136670 0.9/s removals 1136605 0.9/s Counters match 787482855 651.2/s bad-offset 0 0.0/s fragment 0 0.0/s short 0 0.0/s normalize 0 0.0/s memory 0 0.0/s bad-timestamp 0 0.0/s congestion 0 0.0/s ip-option 0 0.0/s proto-cksum 0 0.0/s state-mismatch 748 0.0/s state-insert 0 0.0/s state-limit 0 0.0/s src-limit 0 0.0/s synproxy 0 0.0/s From pyunyh at gmail.com Thu Jul 3 02:02:01 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Jul 3 02:02:06 2008 Subject: Marvell Yukon 88E8062 - media selection problem In-Reply-To: <486C0E69.8020603@hot.pl> References: <1052423937.20080630135423@hot.pl> <20080701004855.GF83626@cdnetworks.co.kr> <486A07A4.1070406@hot.pl> <20080702010929.GA87933@cdnetworks.co.kr> <486C0E69.8020603@hot.pl> Message-ID: <20080703015948.GB92015@cdnetworks.co.kr> On Thu, Jul 03, 2008 at 01:25:29AM +0200, Krzysztof J?druczyk wrote: > Pyun YongHyeon pisze: > > Would you try attached patch? > >The patch is just for checking code path of fiber media. > > It's slightly better - some media gets detected, but looks weird to me > (and doesn't communicate with other machines on the switch): > > # ifconfig > msk0: flags=8802 metric 0 mtu 1500 > options=11a > ether 00:10:f3:0d:d6:45 > media: Ethernet autoselect (autoselect ) > status: active > msk1: flags=8802 metric 0 mtu 1500 > options=11a > ether 00:10:f3:0d:d6:46 > media: Ethernet autoselect (autoselect ) > status: active > > 'autoselect (autoselect )' doesn't seem right to me... > I guess I've clobbered extended address register. How about attached one? > I couldn't see any signs of interface being functional with neither ping > nor tcpdump... > There could be other issues in msk(4) for dual port controllers but let's focus on PHY issue first. > I tried the patch with 7.0-RELEASE-p2, -STABLE and -CURRENT kernels. > > I'm not sure how important is that, but I still can't force it to > 1000baseSX: > > # ifconfig msk0 media 1000baseSX > ifconfig: SIOCSIFMEDIA (media): Device not configured > I guess you may have to specify "mediaopt full-duplex" in the command. But I believe you should not manually set media type on gigabit environments. > > > >Btw, it looks like you have dual port controller, right? > > > Yes, this machine has dual gigabit ports: > http://www.nexcom.com/ProductModel.aspx?id=7541ac3e-ecfd-4008-83cd-52e1ababe6a8 > > Let me know if there is any info I could provide that would help making > this interface functional. > There are a copule of code path that applys to dual port controllers. For example MSI is not supported even though hardware actually support that feature. That would be next item to try. -- Regards, Pyun YongHyeon -------------- next part -------------- --- sys/dev/mii/e1000phy.c.orig 2007-11-21 14:51:55.000000000 +0900 +++ sys/dev/mii/e1000phy.c 2008-07-03 10:46:06.000000000 +0900 @@ -148,10 +148,13 @@ esc->mii_model = MII_MODEL(ma->mii_id2); switch (esc->mii_model) { case MII_MODEL_MARVELL_E1011: - case MII_MODEL_MARVELL_E1112: if (PHY_READ(sc, E1000_ESSR) & E1000_ESSR_FIBER_LINK) sc->mii_flags |= MIIF_HAVEFIBER; break; + case MII_MODEL_MARVELL_E1112: + /* XXX Should have a way to get instance info. */ + sc->mii_flags |= MIIF_HAVEFIBER; + break; case MII_MODEL_MARVELL_E3082: /* 88E3082 10/100 Fast Ethernet PHY. */ sc->mii_anegticks = MII_ANEGTICKS; @@ -209,7 +212,7 @@ e1000phy_reset(struct mii_softc *sc) { struct e1000phy_softc *esc; - uint16_t reg; + uint16_t page, reg; esc = (struct e1000phy_softc *)sc; reg = PHY_READ(sc, E1000_SCR); @@ -217,13 +220,14 @@ reg &= ~E1000_SCR_AUTO_X_MODE; PHY_WRITE(sc, E1000_SCR, reg); if (esc->mii_model == MII_MODEL_MARVELL_E1112) { + page = PHY_READ(sc, E1000_EADR); /* Select 1000BASE-X only mode. */ PHY_WRITE(sc, E1000_EADR, 2); reg = PHY_READ(sc, E1000_SCR); reg &= ~E1000_SCR_MODE_MASK; reg |= E1000_SCR_MODE_1000BX; PHY_WRITE(sc, E1000_SCR, reg); - PHY_WRITE(sc, E1000_EADR, 1); + PHY_WRITE(sc, E1000_EADR, page); } } else { switch (esc->mii_model) { @@ -472,8 +476,8 @@ else mii->mii_media_active |= IFM_10_T; } else { - if (ssr & E1000_SSR_1000MBS) - mii->mii_media_active |= IFM_1000_SX; + /* XXX Should have a way to tell IFM_1000_SX/IFM_1000_LX. */ + mii->mii_media_active |= IFM_1000_SX; } if (ssr & E1000_SSR_DUPLEX) From andrew at rinet.ru Thu Jul 3 10:43:19 2008 From: andrew at rinet.ru (Andrew Kolchoogin) Date: Thu Jul 3 10:43:27 2008 Subject: installdate of a port/package? In-Reply-To: <486AAB93.1050606@menhennitt.com.au> References: <486AAB93.1050606@menhennitt.com.au> Message-ID: <1215078195.9029.22.camel@akela> Wed, 02/07/2008 в 08:11 +1000, Graham Menhennitt writes: > Ronald Klop wrote: > > I just upgraded a machine from FreeBSD 6 to 7. Very nice. > > But my portupgrade -fa failed after a while. > > ... > > How do I know which ports I still need to update? > Run "portupgrade -fan" ... ... and it will suggest you to reinstall/upgrade everything. :) "portupgrade -an" will do suggest you to upgrade only outdated packages, but trouble in question is in that there is no way to determine what version of FreeBSD package was built on, neither using base system utilities, nor using tools from ports-mgmt/ -- one may suggest me to do this the way Gentoo's "revdep-rebuild" script does -- i.e., using ldd to determine which version of libc.so executable in question is linked with, asking pkg_info about what port contains the file and rebuilding such a port with portupgrade, this method is more or less good, but it is not a universal one. First of all, there're statically linked executables. Oh, well, one might use "strings" to extract them from executable and try to guess C compiler version executable was built with, but, in my opinon, human trying to rely on method described above is a "dangerous sharlatan" (C) opensolaris.org, BrandZ community. :) Second, there're a couple of ports that contains only libraries, and there're TONS of software which doesn't use advanced capabilities of modern link editors that are able to link one shared library with others, thus giving a large chance to run-time link editor to choke from incorrect versions of shared libraries, and making our first method of determining fairly useless. At last, but not at least, one can rely on versioned symbols, but this method can be used when people will upgrade old and obsolete RELENG_7 to modern and sexy RELENG_8, :) so I will not discuss it here at least in three years. ;) Conclusion: when you're upgrading from (n-1).x to n.x and starting "portupgrade -fa", in my opinion, the only safe choice in a case of "portupgrade -fa" faults is to start it again (oh-eh!). It's feasible, though, to avoid use of "portupgrade -fa" -- prepare list of packages with dependencies using "portupgrade -nfa" and use the simplest shell statement: for i in `cat package-list`; do portupgrade -f $i; done -- Andrew Kolchoogin Cronyx Plus LLC From des at des.no Thu Jul 3 14:57:36 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Thu Jul 3 14:57:42 2008 Subject: make buildworld fails on a RELENG_7_0 machine In-Reply-To: <64de5c8b0806260110k72470558gbbf237f42308e06d@mail.gmail.com> (Rajkumar S.'s message of "Thu\, 26 Jun 2008 13\:40\:51 +0530") References: <64de5c8b0806260110k72470558gbbf237f42308e06d@mail.gmail.com> Message-ID: <86r6abkobm.fsf@ds4.des.no> "Rajkumar S" writes: > [...] > ===> gnu/usr.bin/cvs/contrib (cleandir) > sed -e 's,@CSH@,/bin/csh,' -e 's,@PERL@,/usr/bin/perl,' > /usr/src/gnu/usr.bin/cvs/contrib/../../../../contrib/cvs/contrib/Makefile.in > Makefile > "Makefile", line 15: Need an operator This will happen if src/gnu/usr.bin/cvs/contrib/Makefile is older than src/contrib/cvs/contrib/Makefile.in, which is usually not the case, but can happen by accident. This has been fixed in 7-STABLE. csup to get a clean tree, then # touch /usr/src/gnu/usr.bin/cvs/contrib/Makefile before building. DES -- Dag-Erling Sm?rgrav - des@des.no From kian.mohageri at gmail.com Thu Jul 3 16:20:04 2008 From: kian.mohageri at gmail.com (Kian Mohageri) Date: Thu Jul 3 16:20:08 2008 Subject: connect(): Operation not permitted In-Reply-To: <20080703003955.859BCF180C0@mx.npubs.com> References: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> <1211037564.6326.27.camel@porksoda> <679DB462-75D6-45CC-949C-1BE8E12C22CD@stromnet.se> <482FD877.6050707@infracaninophile.co.uk> <20080703003955.859BCF180C0@mx.npubs.com> Message-ID: On Wed, Jul 2, 2008 at 5:39 PM, Stef wrote: > Kian Mohageri wrote: >> On Sun, May 18, 2008 at 3:33 AM, Johan Str?m wrote: >>> On May 18, 2008, at 9:19 AM, Matthew Seaman wrote: >>> >>>> Johan Str?m wrote: >>>> >>>>> drop all traffic)? A check with pfctl -vsr reveals that the actual rule >>>>> inserted is "pass on lo0 inet from 123.123.123.123 to 123.123.123.123 flags >>>>> S/SA keep state". Where did that "keep state" come from? >>>> 'flags S/SA keep state' is the default now for tcp filter rules -- that >>>> was new in 7.0 reflecting the upstream changes made between the 4.0 and >>>> 4.1 >>>> releases of OpenBSD. If you want a stateless rule, append 'no state'. >>>> >>>> http://www.openbsd.org/faq/pf/filter.html#state >>> Thanks! I was actually looking around in the pf.conf manpage but failed to >>> find it yesterday, but looking closer today I now saw it. >>> Applied the no state (and quick) to the rule, and now no state is created. >>> And the problem I had in the first place seems to have been resolved too >>> now, even though it didn't look like a state problem.. (started to deny new >>> connections much earlier than the states was full, altough maybee i wasnt >>> looking for updates fast enough or something). >>> >> >> I'd be willing to bet it's because you're reusing the source port on a >> new connection before the old state expires. >> >> You'll know if you check the state-mismatch counter. >> >> Anyway, glad you found a resolution. > > I've been experiencing this "Operation not permitted" too. I've been > trying to track down the problem for many months, but due to the > complexity of my firewalls (scores of jails each with scores of rules), > I wasn't brave enough to ask for help :) > > As a work around we started creating rules without state, whenever we > would run into the problem. > > Thanks for the pointer about state-mismatch. The state-mismatch counter > does is in fact high in my case (see below). How would I go about > getting the pf state timeout and the reuse of ports for outbound > connections to match? Or is this an intractable problem, that just needs > to be worked around? > Make sure your state-mismatch counter is increasing at the same times you experience the problem (and isn't just high from some unrelated issue). A similar/related problem was addressed in OpenBSD 4.3 (http://www.openbsd.org/plus43.html). * In pf(4), allow state reuse if both sides are in FIN_WAIT_2 and a new SYN arrives. I'm not sure if it's been imported yet. If not, you could try tuning your timeout values (see pf.conf(5)). The specific issue I was experienced was solved by shortening tcp.closed, IIRC. It's been a while though. -Kian From biancalana at gmail.com Thu Jul 3 16:33:56 2008 From: biancalana at gmail.com (Alexandre Biancalana) Date: Thu Jul 3 16:33:59 2008 Subject: DigiBoard Xem with 2 extenal modules Message-ID: <8e10486b0807030908i4c6f70bbp3f8e8907c7443259@mail.gmail.com> Hi List, Is anybody running FreeBSD 7 DigiBoard Xem with 2 external 16-port modules ? I have this at my hands and only the first 16 ports are recognized... any tricks ?? Any help is very appreciated. Regards, Alexandre From biancalana at gmail.com Thu Jul 3 17:41:09 2008 From: biancalana at gmail.com (Alexandre Biancalana) Date: Thu Jul 3 17:41:13 2008 Subject: DigiBoard Xem with 2 extenal modules In-Reply-To: <1215105220.32135.18.camel@buffy.york.ac.uk> References: <8e10486b0807030908i4c6f70bbp3f8e8907c7443259@mail.gmail.com> <1215105220.32135.18.camel@buffy.york.ac.uk> Message-ID: <8e10486b0807031041o54349836i31c5da84ebda70f6@mail.gmail.com> On 7/3/08, Gavin Atkinson wrote: > Hi, > > I'm afraid I can't give you the answer, but there's various bits of > information that I think will be useful to try to help resolve it: > > full verbose dmesg > output of "pciconf -l" (if it is a PCI card) > output of "devinfo -v" and "pnpinfo" (if it's an ISA card) > > Could you also take a look at PR kern/82227 and see if that is the same > hardware as yours please? Hi Gavin ! Thank you for you attention! My problem looks exact the same of the kern/82227 Follow the requested infos.... # pciconf -lv hostb0@pci0:0:0:0: class=0x060000 card=0x82761043 chip=0x29c08086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '(Bearlake) Processor to I/O Controller' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x29c18086 chip=0x29c18086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '(Bearlake) PCIe Root Port' class = bridge subclass = PCI-PCI uhci0@pci0:0:26:0: class=0x0c0300 card=0x82771043 chip=0x29378086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci1@pci0:0:26:1: class=0x0c0300 card=0x82771043 chip=0x29388086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci2@pci0:0:26:2: class=0x0c0300 card=0x82771043 chip=0x29398086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) USB Universal Host Controller' class = serial bus subclass = USB ehci0@pci0:0:26:7: class=0x0c0320 card=0x82771043 chip=0x293c8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) USB2 Enhanced Host Controller' class = serial bus subclass = USB pcib2@pci0:0:28:0: class=0x060400 card=0x82771043 chip=0x29408086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) PCIe Root Port 1' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:4: class=0x060400 card=0x82771043 chip=0x29488086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) PCIe Root Port 5' class = bridge subclass = PCI-PCI pcib4@pci0:0:28:5: class=0x060400 card=0x82771043 chip=0x294a8086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) PCIe Root Port 6' class = bridge subclass = PCI-PCI uhci3@pci0:0:29:0: class=0x0c0300 card=0x82771043 chip=0x29348086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci4@pci0:0:29:1: class=0x0c0300 card=0x82771043 chip=0x29358086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci5@pci0:0:29:2: class=0x0c0300 card=0x82771043 chip=0x29368086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) USB Universal Host Controller' class = serial bus subclass = USB ehci1@pci0:0:29:7: class=0x0c0320 card=0x82771043 chip=0x293a8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) USB2 Enhanced Host Controller' class = serial bus subclass = USB pcib5@pci0:0:30:0: class=0x060401 card=0x82771043 chip=0x244e8086 rev=0x92 hdr=0x01 vendor = 'Intel Corporation' device = '82801 Family (ICH2/3/4/4/5/5/6/7/8/9,63xxESB) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x82771043 chip=0x29188086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB (ICH9) LPC Interface Controller' class = bridge subclass = PCI-ISA atapci1@pci0:0:31:2: class=0x01018f card=0x82771043 chip=0x29218086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) 2 port Serial ATA Storage Controller 1' class = mass storage subclass = ATA none0@pci0:0:31:3: class=0x0c0500 card=0x82771043 chip=0x29308086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) SMBus Controller' class = serial bus subclass = SMBus atapci2@pci0:0:31:5: class=0x010185 card=0x82771043 chip=0x29268086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) 2 port Serial ATA Storage Controller 2' class = mass storage subclass = ATA vgapci0@pci0:1:0:0: class=0x030000 card=0x12131019 chip=0x01d310de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'GeForce 7300 SE' class = display subclass = VGA atapci0@pci0:3:0:0: class=0x01018f card=0x82a21043 chip=0x612111ab rev=0xb2 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = '6121 SATA2 Controller' class = mass storage subclass = ATA none1@pci0:2:0:0: class=0x020000 card=0x82261043 chip=0x10481969 rev=0xb0 hdr=0x00 vendor = 'Attansic (Now owned by Atheros)' device = 'L1 Gigabit Ethernet 10/100/1000Base-T Ethernet Controller' class = network subclass = ethernet xl0@pci0:5:0:0: class=0x020000 card=0x635610b7 chip=0x605610b7 rev=0x20 hdr=0x00 vendor = '3COM Corp, Networking Division' device = '3CN3AC1556B MiniPCI 10/100 Ethernet+Modem56k (see devid:1007)' class = network subclass = ethernet none2@pci0:5:0:1: class=0x078000 card=0x615910b7 chip=0x100710b7 rev=0x20 hdr=0x00 vendor = '3COM Corp, Networking Division' device = '3C556 V.90 Mini-PCI Modem' class = simple comms digi0@pci0:5:1:0: class=0x078000 card=0x00000000 chip=0x0004114f rev=0x01 hdr=0x00 vendor = 'Digi International' device = 'AccelePort Xem' class = simple comms # # devinfo -v nexus0 acpi0 cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU1 acpi_perf0 est0 p4tcc0 cpufreq0 cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU2 acpi_perf1 est1 p4tcc1 cpufreq1 unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU3 unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU4 pcib0 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.PCI0 pci0 hostb0 pnpinfo vendor=0x8086 device=0x29c0 subvendor=0x1043 subdevice=0x8276 class=0x060000 at slot=0 function=0 pcib1 pnpinfo vendor=0x8086 device=0x29c1 subvendor=0x8086 subdevice=0x29c1 class=0x060400 at slot=1 function=0 handle=\_SB_.PCI0.P0P2 pci1 vgapci0 pnpinfo vendor=0x10de device=0x01d3 subvendor=0x1019 subdevice=0x1213 class=0x030000 at slot=0 function=0 drm0 uhci0 pnpinfo vendor=0x8086 device=0x2937 subvendor=0x1043 subdevice=0x8277 class=0x0c0300 at slot=26 function=0 handle=\_SB_.PCI0.USB4 usb0 uhub0 uhci1 pnpinfo vendor=0x8086 device=0x2938 subvendor=0x1043 subdevice=0x8277 class=0x0c0300 at slot=26 function=1 handle=\_SB_.PCI0.USB5 usb1 uhub1 uhci2 pnpinfo vendor=0x8086 device=0x2939 subvendor=0x1043 subdevice=0x8277 class=0x0c0300 at slot=26 function=2 handle=\_SB_.PCI0.USB6 usb2 uhub2 ehci0 pnpinfo vendor=0x8086 device=0x293c subvendor=0x1043 subdevice=0x8277 class=0x0c0320 at slot=26 function=7 handle=\_SB_.PCI0.USBE usb3 uhub3 pcib2 pnpinfo vendor=0x8086 device=0x2940 subvendor=0x1043 subdevice=0x8277 class=0x060400 at slot=28 function=0 handle=\_SB_.PCI0.P0P4 pci4 pcib3 pnpinfo vendor=0x8086 device=0x2948 subvendor=0x1043 subdevice=0x8277 class=0x060400 at slot=28 function=4 handle=\_SB_.PCI0.P0P8 pci3 atapci0 pnpinfo vendor=0x11ab device=0x6121 subvendor=0x1043 subdevice=0x82a2 class=0x01018f at slot=0 function=0 ata2 ata3 pcib4 pnpinfo vendor=0x8086 device=0x294a subvendor=0x1043 subdevice=0x8277 class=0x060400 at slot=28 function=5 handle=\_SB_.PCI0.P0P9 pci2 unknown pnpinfo vendor=0x1969 device=0x1048 subvendor=0x1043 subdevice=0x8226 class=0x020000 at slot=0 function=0 uhci3 pnpinfo vendor=0x8086 device=0x2934 subvendor=0x1043 subdevice=0x8277 class=0x0c0300 at slot=29 function=0 handle=\_SB_.PCI0.USB0 usb4 uhub4 uhci4 pnpinfo vendor=0x8086 device=0x2935 subvendor=0x1043 subdevice=0x8277 class=0x0c0300 at slot=29 function=1 handle=\_SB_.PCI0.USB1 usb5 uhub5 uhci5 pnpinfo vendor=0x8086 device=0x2936 subvendor=0x1043 subdevice=0x8277 class=0x0c0300 at slot=29 function=2 handle=\_SB_.PCI0.USB2 usb6 uhub6 ehci1 pnpinfo vendor=0x8086 device=0x293a subvendor=0x1043 subdevice=0x8277 class=0x0c0320 at slot=29 function=7 handle=\_SB_.PCI0.EUSB usb7 uhub7 pcib5 pnpinfo vendor=0x8086 device=0x244e subvendor=0x1043 subdevice=0x8277 class=0x060401 at slot=30 function=0 handle=\_SB_.PCI0.P0P1 pci5 xl0 pnpinfo vendor=0x10b7 device=0x6056 subvendor=0x10b7 subdevice=0x6356 class=0x020000 at slot=0 function=0 miibus0 acphy0 pnpinfo oui=0x895 model=0x21 rev=0xb at phyno=0 unknown pnpinfo vendor=0x10b7 device=0x1007 subvendor=0x10b7 subdevice=0x6159 class=0x078000 at slot=0 function=1 digi0 pnpinfo vendor=0x114f device=0x0004 subvendor=0x0000 subdevice=0x0000 class=0x078000 at slot=1 function=0 isab0 pnpinfo vendor=0x8086 device=0x2918 subvendor=0x1043 subdevice=0x8277 class=0x060100 at slot=31 function=0 handle=\_SB_.PCI0.SBRG isa0 fdc0 ppc0 sc0 sio0 sio1 sio2 sio3 vga0 orm0 atapci1 pnpinfo vendor=0x8086 device=0x2921 subvendor=0x1043 subdevice=0x8277 class=0x01018f at slot=31 function=2 handle=\_SB_.PCI0.SATA ata4 ad8 subdisk8 ata5 unknown pnpinfo vendor=0x8086 device=0x2930 subvendor=0x1043 subdevice=0x8277 class=0x0c0500 at slot=31 function=3 atapci2 pnpinfo vendor=0x8086 device=0x2926 subvendor=0x1043 subdevice=0x8277 class=0x010185 at slot=31 function=5 handle=\_SB_.PCI0.SAT1 ata6 ata7 acpi_sysresource0 pnpinfo _HID=PNP0C01 _UID=10 at handle=\_SB_.PCI0.MCH_ unknown pnpinfo _HID=AWY0001 _UID=0 at handle=\_SB_.PCI0.SBRG.IELK unknown pnpinfo _HID=PNP0000 _UID=0 at handle=\_SB_.PCI0.SBRG.PIC_ atdma0 pnpinfo _HID=PNP0200 _UID=0 at handle=\_SB_.PCI0.SBRG.DMAD attimer0 pnpinfo _HID=PNP0100 _UID=0 at handle=\_SB_.PCI0.SBRG.TMR_ attimer1 pnpinfo _HID=PNP0B00 _UID=0 at handle=\_SB_.PCI0.SBRG.RTC0 unknown pnpinfo _HID=PNP0800 _UID=0 at handle=\_SB_.PCI0.SBRG.SPKR fpupnp0 pnpinfo _HID=PNP0C04 _UID=0 at handle=\_SB_.PCI0.SBRG.COPR unknown pnpinfo _HID=PNP0700 _UID=0 at handle=\_SB_.PCI0.SBRG.FDC_ acpi_sysresource1 pnpinfo _HID=PNP0C02 _UID=46 at handle=\_SB_.PCI0.SBRG.SIOR acpi_sysresource2 pnpinfo _HID=PNP0C02 _UID=16 at handle=\_SB_.PCI0.SBRG.RMSC unknown pnpinfo _HID=ATK0110 _UID=16843024 at handle=\_SB_.PCI0.SBRG.ASOC unknown pnpinfo _HID=PNP0103 _UID=0 at handle=\_SB_.PCI0.SBRG.HPET unknown pnpinfo _HID=PNP0501 _UID=1 at handle=\_SB_.PCI0.SBRG.UAR1 acpi_sysresource3 pnpinfo _HID=PNP0C02 _UID=0 at handle=\_SB_.PCI0.SBRG.OMSC atkbdc0 pnpinfo _HID=PNP0303 _UID=0 at handle=\_SB_.PCI0.SBRG.PS2K atkbd0 psm0 acpi_sysresource4 pnpinfo _HID=PNP0C02 _UID=17 at handle=\_SB_.PCI0.PCIE unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.SATA.CHN0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.SATA.CHN0.DRV0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.SATA.CHN0.DRV1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.SATA.CHN1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.SATA.CHN1.DRV0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.SATA.CHN1.DRV1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.SAT1.CHN0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.SAT1.CHN0.DRV0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.SAT1.CHN0.DRV1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.SAT1.CHN1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.SAT1.CHN1.DRV0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.SAT1.CHN1.DRV1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.P0P5 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.P0P6 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.P0P7 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.GBEC unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.USB3 acpi_sysresource5 pnpinfo _HID=PNP0C01 _UID=1 at handle=\_SB_.RMEM acpi_button0 pnpinfo _HID=PNP0C0C _UID=170 at handle=\_SB_.PWRB pci_link0 pnpinfo _HID=PNP0C0F _UID=1 at handle=\_SB_.LNKA pci_link1 pnpinfo _HID=PNP0C0F _UID=2 at handle=\_SB_.LNKB pci_link2 pnpinfo _HID=PNP0C0F _UID=3 at handle=\_SB_.LNKC pci_link3 pnpinfo _HID=PNP0C0F _UID=4 at handle=\_SB_.LNKD pci_link4 pnpinfo _HID=PNP0C0F _UID=5 at handle=\_SB_.LNKE pci_link5 pnpinfo _HID=PNP0C0F _UID=6 at handle=\_SB_.LNKF pci_link6 pnpinfo _HID=PNP0C0F _UID=7 at handle=\_SB_.LNKG pci_link7 pnpinfo _HID=PNP0C0F _UID=8 at handle=\_SB_.LNKH acpi_timer0 pnpinfo unknown at unknown acpi_hpet0 pnpinfo unknown at unknown apic0 legacy0 ram0 # Copyright (c) 1992-2008 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 7.0-STABLE #0: Thu Jul 3 02:14:49 UTC 2008 root@:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E4600 @ 2.40GHz (2407.18-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 2133786624 (2034 MB) avail memory = 2059083776 (1963 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7ff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xfd000000-0xfdffffff,0xd0000000-0xdfffffff,0xfc000000-0xfcffffff irq 16 at device 0.0 on pci1 uhci0: port 0xc800-0xc81f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xc880-0xc89f irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xcc00-0xcc1f irq 18 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xfbfffc00-0xfbffffff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pcib2: irq 17 at device 28.0 on pci0 pci4: on pcib2 pcib3: irq 17 at device 28.4 on pci0 pci3: on pcib3 atapci0: port 0xdc00-0xdc07,0xd880-0xd883,0xd800-0xd807,0xd480-0xd483,0xd400-0xd40f mem 0xfe3ffc00-0xfe3fffff irq 16 at device 0.0 on pci3 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pcib4: irq 16 at device 28.5 on pci0 pci2: on pcib4 pci2: at device 0.0 (no driver attached) uhci3: port 0xc080-0xc09f irq 23 at device 29.0 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0xc400-0xc41f irq 19 at device 29.1 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered uhci5: port 0xc480-0xc49f irq 18 at device 29.2 on pci0 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered ehci1: mem 0xfbfff800-0xfbfffbff irq 23 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub7: on usb7 uhub7: 6 ports with 6 removable, self powered pcib5: at device 30.0 on pci0 pci5: on pcib5 xl0: <3Com 3c556B Fast Etherlink XL> port 0xe400-0xe4ff mem 0xfebff400-0xfebff47f,0xfebff000-0xfebff07f irq 16 at device 0.0 on pci5 miibus0: on xl0 acphy0: PHY 0 on miibus0 acphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:00:86:4d:7d:da xl0: [ITHREAD] pci5: at device 0.1 (no driver attached) digi0 mem 0xfe400000-0xfe7fffff irq 17 at device 1.0 on pci5 digi0: Digiboard PCI PC/Xem ASIC, 16 ports found isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0xb000-0xb007,0xac00-0xac03,0xa880-0xa887,0xa800-0xa803,0xa480-0xa48f,0xa400-0xa40f irq 22 at device 31.2 on pci0 atapci1: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci2: port 0xc000-0xc007,0xbc00-0xbc03,0xb880-0xb887,0xb800-0xb803,0xb480-0xb48f,0xb400-0xb40f irq 22 at device 31.5 on pci0 atapci2: [ITHREAD] ata6: on atapci2 ata6: [ITHREAD] ata7: on atapci2 ata7: [ITHREAD] cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] acpi_button0: on acpi0 orm0: at iomem 0xcf000-0xcffff on isa0 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec ad8: 305245MB at ata4-master SATA300 SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad8s1a digi0: Digiboard PCI PC/Xem ASIC, 16 ports found digi0: Got init reset after 0 us digi0: BIOS uploaded digi0: BIOS started after 0 us digi0: BIOS booted after 1621 iterations digi0: Loading FEP/OS digi0: FEP/OS loaded digi0: FEP/OS started after 28 iterations digi0: Digiboard PCI PC/Xem ASIC, 16 ports found # From gavin at FreeBSD.org Thu Jul 3 17:44:15 2008 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Thu Jul 3 17:44:20 2008 Subject: DigiBoard Xem with 2 extenal modules In-Reply-To: <8e10486b0807030908i4c6f70bbp3f8e8907c7443259@mail.gmail.com> References: <8e10486b0807030908i4c6f70bbp3f8e8907c7443259@mail.gmail.com> Message-ID: <1215105220.32135.18.camel@buffy.york.ac.uk> On Thu, 2008-07-03 at 13:08 -0300, Alexandre Biancalana wrote: > Hi List, > > Is anybody running FreeBSD 7 DigiBoard Xem with 2 external 16-port modules ? > > I have this at my hands and only the first 16 ports are recognized... > any tricks ?? > > Any help is very appreciated. Hi, I'm afraid I can't give you the answer, but there's various bits of information that I think will be useful to try to help resolve it: full verbose dmesg output of "pciconf -l" (if it is a PCI card) output of "devinfo -v" and "pnpinfo" (if it's an ISA card) Could you also take a look at PR kern/82227 and see if that is the same hardware as yours please? Thanks, Gavin From peterjeremy at optushome.com.au Thu Jul 3 20:00:08 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Thu Jul 3 20:00:13 2008 Subject: DigiBoard Xem with 2 extenal modules In-Reply-To: <8e10486b0807030908i4c6f70bbp3f8e8907c7443259@mail.gmail.com> References: <8e10486b0807030908i4c6f70bbp3f8e8907c7443259@mail.gmail.com> Message-ID: <20080703200005.GO29380@server.vk2pj.dyndns.org> On 2008-Jul-03 13:08:09 -0300, Alexandre Biancalana wrote: >Is anybody running FreeBSD 7 DigiBoard Xem with 2 external 16-port modules ? I was unable to get it to work in 6.x and haven't tried with 7.x. My work-around was to use PCI cards (since I had a second one available). I have worked through the driver and compared it to the most recent Linux driver available from Digi, as well as upgrading the firmware to the most recent available to no avail. I know the second 16 ports works in Solaris but haven't tried Linux and verified that it doesn't work in FreeBSD. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080703/7c43711c/attachment.pgp From biancalana at gmail.com Thu Jul 3 20:13:51 2008 From: biancalana at gmail.com (Alexandre Biancalana) Date: Thu Jul 3 20:13:55 2008 Subject: DigiBoard Xem with 2 extenal modules In-Reply-To: <20080703200005.GO29380@server.vk2pj.dyndns.org> References: <8e10486b0807030908i4c6f70bbp3f8e8907c7443259@mail.gmail.com> <20080703200005.GO29380@server.vk2pj.dyndns.org> Message-ID: <8e10486b0807031313k836835tefc38f72ac036545@mail.gmail.com> On 7/3/08, Peter Jeremy wrote: > On 2008-Jul-03 13:08:09 -0300, Alexandre Biancalana wrote: > >Is anybody running FreeBSD 7 DigiBoard Xem with 2 external 16-port modules ? > > > I was unable to get it to work in 6.x and haven't tried with 7.x. My > work-around was to use PCI cards (since I had a second one available). > I have worked through the driver and compared it to the most recent > Linux driver available from Digi, as well as upgrading the firmware to > the most recent available to no avail. > > I know the second 16 ports works in Solaris but haven't tried Linux > and verified that it doesn't work in FreeBSD. I tried in Linux and that works. But the customer solution was ever FreeBSD and I don't want to change :-( From pisymbol at gmail.com Thu Jul 3 21:11:42 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Thu Jul 3 21:11:46 2008 Subject: Atheros (ath) MSI wireless embedded chipset fails to attach on 7.0-STABLE In-Reply-To: <486BDCE9.3000608@freebsd.org> References: <3c0b01820806170757v5565b59ne0e9d5db06f26761@mail.gmail.com> <486BDCE9.3000608@freebsd.org> Message-ID: <3c0b01820807031411y2d45660eqaca499c8debac2cc@mail.gmail.com> On Wed, Jul 2, 2008 at 3:54 PM, Sam Leffler wrote: > Alexander Sack wrote: >> >> Hello: >> >> I have installed FreeBSD-7.0-amd64 stable on my new AMD X2 Turon based >> notebook, a MSI-1710A (GX710Ax) which has a generic embedded >> controller. During boot up I notice that ATH complains with: >> >> ath_rate: version 1.2 >> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) >> ath0: mem 0xfd7f0000-0xfd7fffff irq 16 at device 0.0 >> on pci2 >> ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfd7f0000 >> ath0: [MPSAFE] >> ath0: [ITHREAD] >> ath0: unable to attach hardware; HAL status 13 >> device_attach: ath0 attach returned 6 >> >> HAL status 13 from the header file seems to indicate that the >> 7.0-STABLE driver doesn't support my hardware revision. Here is my >> pciconf -l output: >> >> hostb0@pci0:0:0:0: class=0x060000 card=0x42cd1462 chip=0x79101002 >> rev=0x00 hdr=0x00 >> pcib1@pci0:0:2:0: class=0x060400 card=0x42cd1462 chip=0x79131002 >> rev=0x00 hdr=0x01 >> pcib2@pci0:0:4:0: class=0x060400 card=0x42cd1462 chip=0x79141002 >> rev=0x00 hdr=0x01 >> pcib3@pci0:0:6:0: class=0x060400 card=0x42cd1462 chip=0x79161002 >> rev=0x00 hdr=0x01 >> pcib4@pci0:0:7:0: class=0x060400 card=0x42cd1462 chip=0x79171002 >> rev=0x00 hdr=0x01 >> atapci0@pci0:0:18:0: class=0x01018f card=0x42cd1462 chip=0x43801002 >> rev=0x00 hdr=0x00 >> ohci0@pci0:0:19:0: class=0x0c0310 card=0x42cd1462 chip=0x43871002 >> rev=0x00 hdr=0x00 >> ohci1@pci0:0:19:1: class=0x0c0310 card=0x42cd1462 chip=0x43881002 >> rev=0x00 hdr=0x00 >> ohci2@pci0:0:19:2: class=0x0c0310 card=0x42cd1462 chip=0x43891002 >> rev=0x00 hdr=0x00 >> ohci3@pci0:0:19:3: class=0x0c0310 card=0x42cd1462 chip=0x438a1002 >> rev=0x00 hdr=0x00 >> ohci4@pci0:0:19:4: class=0x0c0310 card=0x42cd1462 chip=0x438b1002 >> rev=0x00 hdr=0x00 >> ehci0@pci0:0:19:5: class=0x0c0320 card=0x42cd1462 chip=0x43861002 >> rev=0x00 hdr=0x00 >> none0@pci0:0:20:0: class=0x0c0500 card=0x42cd1462 chip=0x43851002 >> rev=0x14 hdr=0x00 >> atapci1@pci0:0:20:1: class=0x01018a card=0x42cd1462 chip=0x438c1002 >> rev=0x00 hdr=0x00 >> none1@pci0:0:20:2: class=0x040300 card=0x42cd1462 chip=0x43831002 >> rev=0x00 hdr=0x00 >> isab0@pci0:0:20:3: class=0x060100 card=0x42cd1462 chip=0x438d1002 >> rev=0x00 hdr=0x00 >> pcib5@pci0:0:20:4: class=0x060401 card=0x00000000 chip=0x43841002 >> rev=0x00 hdr=0x01 >> hostb1@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 >> rev=0x00 hdr=0x00 >> hostb2@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 >> rev=0x00 hdr=0x00 >> hostb3@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 >> rev=0x00 hdr=0x00 >> hostb4@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 >> rev=0x00 hdr=0x00 >> vgapci0@pci0:1:0:0: class=0x030000 card=0x42cd1462 chip=0x95811002 >> rev=0x00 hdr=0x00 >> none2@pci0:1:0:1: class=0x040300 card=0xaa081462 chip=0xaa081002 >> rev=0x00 hdr=0x00 >> ath0@pci0:2:0:0: class=0x020000 card=0x10261a3b chip=0x001c168c >> rev=0x01 hdr=0x00 >> re0@pci0:5:0:0: class=0x020000 card=0x42cd1462 chip=0x816810ec rev=0x01 >> hdr=0x00 >> cbb0@pci0:6:4:0: class=0x060700 card=0x42cd1462 chip=0x71341217 >> rev=0x21 hdr=0x02 >> none3@pci0:6:4:2: class=0x080500 card=0x42cd1462 chip=0x71201217 >> rev=0x01 hdr=0x00 >> none4@pci0:6:4:3: class=0x068000 card=0x42cd1462 chip=0x71301217 >> rev=0x01 hdr=0x00 >> fwohci0@pci0:6:4:4: class=0x0c0010 card=0x42cd1462 chip=0x00f71217 >> rev=0x02 hdr=0x00 >> >> ath0 is listed as rev=0x01 so I'm a little confused why I got HAL >> status 13. Does anyone know if this chipset is supported in >> 7.0-STABLE? If not, is it possible to try CURRENT on 7.0 which may >> fix it? I've attached my complete dmesg output. >> >> Again, any feedback would be much appreciated! >> >> > > Try the hal in http://www.freebsd.org/~sam. Again Sam, thanks for this, it worked for me... -aps From kensmith at cse.Buffalo.EDU Thu Jul 3 21:14:18 2008 From: kensmith at cse.Buffalo.EDU (Ken Smith) Date: Thu Jul 3 21:14:23 2008 Subject: cvsup server reachable via IPv6... Message-ID: <1215119650.75067.10.camel@neo.cse.buffalo.edu> If any of you have been wishing there was an IPv6-capable cvsup server you could use (with csup as the client obviously since cvsup doesn't do IPv6...) give cvsup18.freebsd.org a try. With the help of a few other folks I got nudged into giving inetd/netcat a try as a means to feed IPv6 connections to the cvsupd server process. If you try it and have problems let me know. cvsup18 is my "little server" (handles between 200 and 300 connects a day) but if this seems to work OK I can give it a try on my "big server" (handles between 3000 and 4000 connects a day...). -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080703/6aaebee1/attachment.pgp From avg at icyb.net.ua Thu Jul 3 21:26:47 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Jul 3 21:26:49 2008 Subject: 6.3 nfe: dead after system reset In-Reply-To: <20080226073633.GC47750@cdnetworks.co.kr> References: <47A3041D.5050402@icyb.net.ua> <20080201123603.GA14050@cdnetworks.co.kr> <47A321BB.1060708@icyb.net.ua> <47A32501.7080703@icyb.net.ua> <20080204035242.GA28554@cdnetworks.co.kr> <47C2BC50.5040702@icyb.net.ua> <47C2DBEF.301@icyb.net.ua> <20080226073633.GC47750@cdnetworks.co.kr> Message-ID: <486D440F.1090601@icyb.net.ua> As they say - long time, no see :-) I am back with some more details, but still with no insights. Let me refresh an essence of the issue. The issue: after 'abrupt' reset/reboot of a system my nfe interface is dead. That is, if I do a graceful reboot (e.g. via shutdown -r) everything is ok, ditto if I do power-down (whether graceful or not) and the power-up. The problem happens only if I press reset button and then boot up. Details. The issue can not be reproduced with nve driver. Moreover, when I reproduce the problem with nfe, then kldunload nfe driver, kldload nve driver - nve interface is alive. Then kldunload nve, kldload nfe - nfe interface is dead again. Specification of dead. There are no errors. ifconfig shows the same output (active, media, up, etc) as in normal case. But I can not ping any host on local network (connected to the same switch), ping outputs "Host is down". tcpdump also doesn't show any incoming traffic. More details. I was able to verify that packets do actually go through the interface. When I try to ping some machine I see (on the other host) arp requests for its ethernet address. All address in arp packets are correct (ethernet and ip). So the interface works for outgoing packets, but somehow loses incoming arp replies. Not sure if thap happens in the NIC or in the driver itself (see the above nve/nfe live replacement experiment). So, there are some facts, but still no clues. -- Andriy Gapon From rizzo at iet.unipi.it Thu Jul 3 21:50:37 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Thu Jul 3 21:50:41 2008 Subject: 6.3 nfe: dead after system reset In-Reply-To: <486D440F.1090601@icyb.net.ua> References: <47A3041D.5050402@icyb.net.ua> <20080201123603.GA14050@cdnetworks.co.kr> <47A321BB.1060708@icyb.net.ua> <47A32501.7080703@icyb.net.ua> <20080204035242.GA28554@cdnetworks.co.kr> <47C2BC50.5040702@icyb.net.ua> <47C2DBEF.301@icyb.net.ua> <20080226073633.GC47750@cdnetworks.co.kr> <486D440F.1090601@icyb.net.ua> Message-ID: <20080703213517.GA76155@onelab2.iet.unipi.it> On Fri, Jul 04, 2008 at 12:26:39AM +0300, Andriy Gapon wrote: > > As they say - long time, no see :-) > I am back with some more details, but still with no insights. > > Let me refresh an essence of the issue. > The issue: after 'abrupt' reset/reboot of a system my nfe interface is dead. > That is, if I do a graceful reboot (e.g. via shutdown -r) everything is > ok, ditto if I do power-down (whether graceful or not) and the power-up. > The problem happens only if I press reset button and then boot up. > > Details. > The issue can not be reproduced with nve driver. > Moreover, when I reproduce the problem with nfe, then kldunload nfe > driver, kldload nve driver - nve interface is alive. Then kldunload nve, > kldload nfe - nfe interface is dead again. > > Specification of dead. > There are no errors. ifconfig shows the same output (active, media, up, > etc) as in normal case. But I can not ping any host on local network > (connected to the same switch), ping outputs "Host is down". tcpdump > also doesn't show any incoming traffic. > > More details. > I was able to verify that packets do actually go through the interface. > When I try to ping some machine I see (on the other host) arp requests > for its ethernet address. All address in arp packets are correct > (ethernet and ip). So the interface works for outgoing packets, but > somehow loses incoming arp replies. Not sure if thap happens in the NIC > or in the driver itself (see the above nve/nfe live replacement experiment). these symptoms (outgoing traffic is ok, incoming not received) are similar to what i see in other conditions on my machine, see http://www.mavetju.org/mail/view_message.php?list=freebsd-net&id=2730309 it is interesting that if_nve works ok, maybe we can compare the two drivers and see if they initialize the device in different ways (or test for receive interrupts in different ways) cheers luigi From eculp at encontacto.net Fri Jul 4 01:13:57 2008 From: eculp at encontacto.net (eculp) Date: Fri Jul 4 01:14:01 2008 Subject: Atheros (ath) MSI wireless embedded chipset fails to attach on 7.0-STABLE In-Reply-To: <3c0b01820807031411y2d45660eqaca499c8debac2cc@mail.gmail.com> References: <3c0b01820806170757v5565b59ne0e9d5db06f26761@mail.gmail.com> <486BDCE9.3000608@freebsd.org> <3c0b01820807031411y2d45660eqaca499c8debac2cc@mail.gmail.com> Message-ID: <20080703200331.1765415meuda1ji8@intranet.encontacto.net> Quoting Alexander Sack : > On Wed, Jul 2, 2008 at 3:54 PM, Sam Leffler wrote: >> Alexander Sack wrote: >>> >>> Hello: >>> >>> I have installed FreeBSD-7.0-amd64 stable on my new AMD X2 Turon based >>> notebook, a MSI-1710A (GX710Ax) which has a generic embedded >>> controller. During boot up I notice that ATH complains with: >>> >>> ath_rate: version 1.2 >>> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) >>> ath0: mem 0xfd7f0000-0xfd7fffff irq 16 at device 0.0 >>> on pci2 I have the same Atheros 5424/2424 on my Acer aspire laptop and it works great by installing the patch from Sam, http://people.freebsd.org/~sam/ath_hal-20080528.tgz Building a new kernel and then adding your configuration in rc.conf. good luck, ed >>> ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfd7f0000 >>> ath0: [MPSAFE] >>> ath0: [ITHREAD] >>> ath0: unable to attach hardware; HAL status 13 >>> device_attach: ath0 attach returned 6 >>> >>> HAL status 13 from the header file seems to indicate that the >>> 7.0-STABLE driver doesn't support my hardware revision. Here is my >>> pciconf -l output: >>> >>> hostb0@pci0:0:0:0: class=0x060000 card=0x42cd1462 chip=0x79101002 >>> rev=0x00 hdr=0x00 >>> pcib1@pci0:0:2:0: class=0x060400 card=0x42cd1462 chip=0x79131002 >>> rev=0x00 hdr=0x01 >>> pcib2@pci0:0:4:0: class=0x060400 card=0x42cd1462 chip=0x79141002 >>> rev=0x00 hdr=0x01 >>> pcib3@pci0:0:6:0: class=0x060400 card=0x42cd1462 chip=0x79161002 >>> rev=0x00 hdr=0x01 >>> pcib4@pci0:0:7:0: class=0x060400 card=0x42cd1462 chip=0x79171002 >>> rev=0x00 hdr=0x01 >>> atapci0@pci0:0:18:0: class=0x01018f card=0x42cd1462 chip=0x43801002 >>> rev=0x00 hdr=0x00 >>> ohci0@pci0:0:19:0: class=0x0c0310 card=0x42cd1462 chip=0x43871002 >>> rev=0x00 hdr=0x00 >>> ohci1@pci0:0:19:1: class=0x0c0310 card=0x42cd1462 chip=0x43881002 >>> rev=0x00 hdr=0x00 >>> ohci2@pci0:0:19:2: class=0x0c0310 card=0x42cd1462 chip=0x43891002 >>> rev=0x00 hdr=0x00 >>> ohci3@pci0:0:19:3: class=0x0c0310 card=0x42cd1462 chip=0x438a1002 >>> rev=0x00 hdr=0x00 >>> ohci4@pci0:0:19:4: class=0x0c0310 card=0x42cd1462 chip=0x438b1002 >>> rev=0x00 hdr=0x00 >>> ehci0@pci0:0:19:5: class=0x0c0320 card=0x42cd1462 chip=0x43861002 >>> rev=0x00 hdr=0x00 >>> none0@pci0:0:20:0: class=0x0c0500 card=0x42cd1462 chip=0x43851002 >>> rev=0x14 hdr=0x00 >>> atapci1@pci0:0:20:1: class=0x01018a card=0x42cd1462 chip=0x438c1002 >>> rev=0x00 hdr=0x00 >>> none1@pci0:0:20:2: class=0x040300 card=0x42cd1462 chip=0x43831002 >>> rev=0x00 hdr=0x00 >>> isab0@pci0:0:20:3: class=0x060100 card=0x42cd1462 chip=0x438d1002 >>> rev=0x00 hdr=0x00 >>> pcib5@pci0:0:20:4: class=0x060401 card=0x00000000 chip=0x43841002 >>> rev=0x00 hdr=0x01 >>> hostb1@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 >>> rev=0x00 hdr=0x00 >>> hostb2@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 >>> rev=0x00 hdr=0x00 >>> hostb3@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 >>> rev=0x00 hdr=0x00 >>> hostb4@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 >>> rev=0x00 hdr=0x00 >>> vgapci0@pci0:1:0:0: class=0x030000 card=0x42cd1462 chip=0x95811002 >>> rev=0x00 hdr=0x00 >>> none2@pci0:1:0:1: class=0x040300 card=0xaa081462 chip=0xaa081002 >>> rev=0x00 hdr=0x00 >>> ath0@pci0:2:0:0: class=0x020000 card=0x10261a3b chip=0x001c168c >>> rev=0x01 hdr=0x00 >>> re0@pci0:5:0:0: class=0x020000 card=0x42cd1462 chip=0x816810ec rev=0x01 >>> hdr=0x00 >>> cbb0@pci0:6:4:0: class=0x060700 card=0x42cd1462 chip=0x71341217 >>> rev=0x21 hdr=0x02 >>> none3@pci0:6:4:2: class=0x080500 card=0x42cd1462 chip=0x71201217 >>> rev=0x01 hdr=0x00 >>> none4@pci0:6:4:3: class=0x068000 card=0x42cd1462 chip=0x71301217 >>> rev=0x01 hdr=0x00 >>> fwohci0@pci0:6:4:4: class=0x0c0010 card=0x42cd1462 chip=0x00f71217 >>> rev=0x02 hdr=0x00 >>> >>> ath0 is listed as rev=0x01 so I'm a little confused why I got HAL >>> status 13. Does anyone know if this chipset is supported in >>> 7.0-STABLE? If not, is it possible to try CURRENT on 7.0 which may >>> fix it? I've attached my complete dmesg output. >>> >>> Again, any feedback would be much appreciated! >>> >>> >> >> Try the hal in http://www.freebsd.org/~sam. > > Again Sam, thanks for this, it worked for me... > > -aps > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From zbeeble at gmail.com Fri Jul 4 01:21:31 2008 From: zbeeble at gmail.com (Zaphod Beeblebrox) Date: Fri Jul 4 01:21:34 2008 Subject: MCP55 SATA data corruption in FreeBSD 7 In-Reply-To: <4F9C9299A10AE74E89EA580D14AA10A61A1968@royal64.emp.zapto.org> References: <4F9C9299A10AE74E89EA580D14AA10A61A1968@royal64.emp.zapto.org> Message-ID: <5f67a8c40807031752r22c3391ds23ab57cb59d2cd32@mail.gmail.com> On Tue, Jul 1, 2008 at 5:01 AM, Daniel Eriksson wrote: > > I am having problems with silent data corruption on (some) drives > connected to an MCP55 SATA controller. > I have an MCP55 controller here running most of my RAID array. When I origionally loaded this machine, I had many problems until I figured out I could only use every other SATA port with any degree of reliability. It turned out that with the first two drives I bought, this every-other rule was true. These drives are: ad4: 238475MB at ata2-master SATA300 But When I bought new drives, they happily used every channel: ad10: 715404MB at ata5-master SATA300 The difference, I'm lead to believe, is that the Samsung drive is a PATA drive with a SATA to PATA bridge on it. The newer "true SATA" drives work fine. From peterjeremy at optushome.com.au Fri Jul 4 02:24:24 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Fri Jul 4 02:24:30 2008 Subject: DigiBoard Xem with 2 extenal modules In-Reply-To: <8e10486b0807031313k836835tefc38f72ac036545@mail.gmail.com> References: <8e10486b0807030908i4c6f70bbp3f8e8907c7443259@mail.gmail.com> <20080703200005.GO29380@server.vk2pj.dyndns.org> <8e10486b0807031313k836835tefc38f72ac036545@mail.gmail.com> Message-ID: <20080704022419.GB32475@server.vk2pj.dyndns.org> On 2008-Jul-03 17:13:50 -0300, Alexandre Biancalana wrote: >I tried in Linux and that works. But the customer solution was ever >FreeBSD and I don't want to change :-( Which implies that problem is inside our code. Maybe someone else needs to work through the Linux driver and see what it does that our driver isn't doing. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080704/29dd5301/attachment.pgp From koitsu at FreeBSD.org Fri Jul 4 11:32:14 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Jul 4 11:32:21 2008 Subject: connect(): Operation not permitted In-Reply-To: References: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> <1211037564.6326.27.camel@porksoda> <679DB462-75D6-45CC-949C-1BE8E12C22CD@stromnet.se> <482FD877.6050707@infracaninophile.co.uk> <20080703003955.859BCF180C0@mx.npubs.com> Message-ID: <20080704113213.GA13586@eos.sc1.parodius.com> On Thu, Jul 03, 2008 at 08:55:21AM -0700, Kian Mohageri wrote: > On Wed, Jul 2, 2008 at 5:39 PM, Stef wrote: > > Kian Mohageri wrote: > >> On Sun, May 18, 2008 at 3:33 AM, Johan Str?m wrote: > >>> On May 18, 2008, at 9:19 AM, Matthew Seaman wrote: > >>> > >>>> Johan Str?m wrote: > >>>> > >>>>> drop all traffic)? A check with pfctl -vsr reveals that the actual rule > >>>>> inserted is "pass on lo0 inet from 123.123.123.123 to 123.123.123.123 flags > >>>>> S/SA keep state". Where did that "keep state" come from? > >>>> 'flags S/SA keep state' is the default now for tcp filter rules -- that > >>>> was new in 7.0 reflecting the upstream changes made between the 4.0 and > >>>> 4.1 > >>>> releases of OpenBSD. If you want a stateless rule, append 'no state'. > >>>> > >>>> http://www.openbsd.org/faq/pf/filter.html#state > >>> Thanks! I was actually looking around in the pf.conf manpage but failed to > >>> find it yesterday, but looking closer today I now saw it. > >>> Applied the no state (and quick) to the rule, and now no state is created. > >>> And the problem I had in the first place seems to have been resolved too > >>> now, even though it didn't look like a state problem.. (started to deny new > >>> connections much earlier than the states was full, altough maybee i wasnt > >>> looking for updates fast enough or something). > >>> > >> > >> I'd be willing to bet it's because you're reusing the source port on a > >> new connection before the old state expires. > >> > >> You'll know if you check the state-mismatch counter. > >> > >> Anyway, glad you found a resolution. > > > > I've been experiencing this "Operation not permitted" too. I've been > > trying to track down the problem for many months, but due to the > > complexity of my firewalls (scores of jails each with scores of rules), > > I wasn't brave enough to ask for help :) > > > > As a work around we started creating rules without state, whenever we > > would run into the problem. > > > > Thanks for the pointer about state-mismatch. The state-mismatch counter > > does is in fact high in my case (see below). How would I go about > > getting the pf state timeout and the reuse of ports for outbound > > connections to match? Or is this an intractable problem, that just needs > > to be worked around? > > Make sure your state-mismatch counter is increasing at the same times > you experience the problem (and isn't just high from some unrelated > issue). > > A similar/related problem was addressed in OpenBSD 4.3 > (http://www.openbsd.org/plus43.html). > > * In pf(4), allow state reuse if both sides are in FIN_WAIT_2 and a > new SYN arrives. > > I'm not sure if it's been imported yet. If not, you could try tuning > your timeout values (see pf.conf(5)). > > The specific issue I was experienced was solved by shortening > tcp.closed, IIRC. It's been a while though. When administrators see state-mismatch increasing, they get concerned. The common scapegoat is tcp.closed, which people don't even bother to describe (pf has an internal value of 10 seconds applied to that value, e.g. tcp.closed=5 means 15 seconds). You can set tcp.closed as low as you want, but chances are random Internet users will have equipment with IP stacks that re-use outbound sockets which haven't fully closed down within the aforementioned interval. pf cannot fix this. For example, on our production/hosting systems, we see state-mismatch increase fairly often. I just pfctl -F info'd our main webserver, and within about 15 minutes, state-mismatch was up to 22. We use tcp.closed of 5 (which means 15 seconds). Workarounds such as "no state" suffice, but if you use rdr rules, you MUST track state, which means there's no way of winning in that case. For sake of example, OpenBSD spamd requires the use of rdr rules. Administrators then ask 3 questions: 1) How do I determine whether or not state-mismatch increasing is a sign of bad things, or due to peoples' broken IP stacks, 2) What happens to packets which cause state-mismatch to increment, e.g. are they blocked, passed, or what? 3) Why isn't state-mismatch described in detail in the documentation? Finally, the fix in OpenBSD 4.3 should really be backported to FreeBSD ASAP. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Fri Jul 4 12:10:50 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Jul 4 12:11:08 2008 Subject: connect(): Operation not permitted In-Reply-To: <20080704113213.GA13586@eos.sc1.parodius.com> References: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> <1211037564.6326.27.camel@porksoda> <679DB462-75D6-45CC-949C-1BE8E12C22CD@stromnet.se> <482FD877.6050707@infracaninophile.co.uk> <20080703003955.859BCF180C0@mx.npubs.com> <20080704113213.GA13586@eos.sc1.parodius.com> Message-ID: <20080704121050.GA14604@eos.sc1.parodius.com> On Fri, Jul 04, 2008 at 04:32:13AM -0700, Jeremy Chadwick wrote: > On Thu, Jul 03, 2008 at 08:55:21AM -0700, Kian Mohageri wrote: > > A similar/related problem was addressed in OpenBSD 4.3 > > (http://www.openbsd.org/plus43.html). > > > > * In pf(4), allow state reuse if both sides are in FIN_WAIT_2 and a > > new SYN arrives. The OpenBSD diff: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf.c.diff?r2=1.559&r1=1.558&f=H I've submit a FreeBSD PR to get the above backported into RELENG_7 and RELENG_6: http://www.freebsd.org/cgi/query-pr.cgi?pr=125261 -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From freebsd at meijome.net Fri Jul 4 13:05:32 2008 From: freebsd at meijome.net (Norberto Meijome) Date: Fri Jul 4 13:05:40 2008 Subject: installdate of a port/package? In-Reply-To: <20080701153446.GB13250@syndicate.internationalconspiracy.org> References: <20080701153446.GB13250@syndicate.internationalconspiracy.org> Message-ID: <20080704223842.673c8d49@ayiin> On Tue, 1 Jul 2008 16:34:47 +0100 Alex Trull wrote: > e.g. $ find $dir -mtime +2 -type f -xdev -print > > Add a little guesswork/pkg_info to determine which ports they're from. you can use pkg_info -W {file} to find out which port installed {file} _________________________ {Beto|Norberto|Numard} Meijome Your reasoning is excellent -- it's only your basic assumptions that are wrong. I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From biancalana at gmail.com Fri Jul 4 15:34:32 2008 From: biancalana at gmail.com (Alexandre Biancalana) Date: Fri Jul 4 15:34:39 2008 Subject: DigiBoard Xem with 2 extenal modules In-Reply-To: <1215176991.36376.24.camel@buffy.york.ac.uk> References: <8e10486b0807030908i4c6f70bbp3f8e8907c7443259@mail.gmail.com> <1215105220.32135.18.camel@buffy.york.ac.uk> <8e10486b0807031041o54349836i31c5da84ebda70f6@mail.gmail.com> <1215176991.36376.24.camel@buffy.york.ac.uk> Message-ID: <8e10486b0807040834m27a38254k5261535d93d70ce6@mail.gmail.com> On 7/4/08, Gavin Atkinson wrote: > It's not a solution, but it may well be a great help in diagnosing where > the problem lies: it would be useful to know if the driver is simply > failing to detect the correct number of ports, or if the driver > physically cannot use them. > > In /usr/src/sys/dev/digi/digi.c, line 510, you'll see the following > code: > > if (sc->numports == 0) { > device_printf(sc->dev, "%s, 0 ports found\n", sc->name); > sc->hidewin(sc); > return (0); > } > > Just before that section, can you add a line "sc->numports = 32;", > recompile, and see if the missing 16 ports are usable? If they are, I > suspect fixing the driver will be trivial. Wow !! Now the 32 ports are detected and devices created. # digictl -d 1 -r /dev/digi0.ctl digi0: Got init reset after 0 us digi0: BIOS uploaded digi0: BIOS started after 0 us digi0: BIOS booted after 1619 iterations digi0: Loading FEP/OS digi0: FEP/OS loaded digi0: FEP/OS started after 28 iterations digi0: Digiboard PCI PC/Xem ASIC, 32 ports found # ls /dev/cuaD?? | wc -l 32 I will connect some modems to that ports to test and let you know. Thank you for your time. From kian.mohageri at gmail.com Fri Jul 4 21:30:57 2008 From: kian.mohageri at gmail.com (Kian Mohageri) Date: Fri Jul 4 21:31:09 2008 Subject: connect(): Operation not permitted In-Reply-To: <20080704113213.GA13586@eos.sc1.parodius.com> References: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> <1211037564.6326.27.camel@porksoda> <679DB462-75D6-45CC-949C-1BE8E12C22CD@stromnet.se> <482FD877.6050707@infracaninophile.co.uk> <20080703003955.859BCF180C0@mx.npubs.com> <20080704113213.GA13586@eos.sc1.parodius.com> Message-ID: On Fri, Jul 4, 2008 at 4:32 AM, Jeremy Chadwick wrote: > On Thu, Jul 03, 2008 at 08:55:21AM -0700, Kian Mohageri wrote: >> On Wed, Jul 2, 2008 at 5:39 PM, Stef wrote: >> > Kian Mohageri wrote: >> >> On Sun, May 18, 2008 at 3:33 AM, Johan Str?m wrote: >> >>> On May 18, 2008, at 9:19 AM, Matthew Seaman wrote: >> >>> >> >>>> Johan Str?m wrote: >> >>>> >> >>>>> drop all traffic)? A check with pfctl -vsr reveals that the actual rule >> >>>>> inserted is "pass on lo0 inet from 123.123.123.123 to 123.123.123.123 flags >> >>>>> S/SA keep state". Where did that "keep state" come from? >> >>>> 'flags S/SA keep state' is the default now for tcp filter rules -- that >> >>>> was new in 7.0 reflecting the upstream changes made between the 4.0 and >> >>>> 4.1 >> >>>> releases of OpenBSD. If you want a stateless rule, append 'no state'. >> >>>> >> >>>> http://www.openbsd.org/faq/pf/filter.html#state >> >>> Thanks! I was actually looking around in the pf.conf manpage but failed to >> >>> find it yesterday, but looking closer today I now saw it. >> >>> Applied the no state (and quick) to the rule, and now no state is created. >> >>> And the problem I had in the first place seems to have been resolved too >> >>> now, even though it didn't look like a state problem.. (started to deny new >> >>> connections much earlier than the states was full, altough maybee i wasnt >> >>> looking for updates fast enough or something). >> >>> >> >> >> >> I'd be willing to bet it's because you're reusing the source port on a >> >> new connection before the old state expires. >> >> >> >> You'll know if you check the state-mismatch counter. >> >> >> >> Anyway, glad you found a resolution. >> > >> > I've been experiencing this "Operation not permitted" too. I've been >> > trying to track down the problem for many months, but due to the >> > complexity of my firewalls (scores of jails each with scores of rules), >> > I wasn't brave enough to ask for help :) >> > >> > As a work around we started creating rules without state, whenever we >> > would run into the problem. >> > >> > Thanks for the pointer about state-mismatch. The state-mismatch counter >> > does is in fact high in my case (see below). How would I go about >> > getting the pf state timeout and the reuse of ports for outbound >> > connections to match? Or is this an intractable problem, that just needs >> > to be worked around? >> >> Make sure your state-mismatch counter is increasing at the same times >> you experience the problem (and isn't just high from some unrelated >> issue). >> >> A similar/related problem was addressed in OpenBSD 4.3 >> (http://www.openbsd.org/plus43.html). >> >> * In pf(4), allow state reuse if both sides are in FIN_WAIT_2 and a >> new SYN arrives. >> >> I'm not sure if it's been imported yet. If not, you could try tuning >> your timeout values (see pf.conf(5)). >> >> The specific issue I was experienced was solved by shortening >> tcp.closed, IIRC. It's been a while though. > > When administrators see state-mismatch increasing, they get concerned. > The common scapegoat is tcp.closed, which people don't even bother to > describe (pf has an internal value of 10 seconds applied to that value, > e.g. tcp.closed=5 means 15 seconds). > > You can set tcp.closed as low as you want, but chances are random > Internet users will have equipment with IP stacks that re-use outbound > sockets which haven't fully closed down within the aforementioned > interval. pf cannot fix this. > > For example, on our production/hosting systems, we see state-mismatch > increase fairly often. I just pfctl -F info'd our main webserver, and > within about 15 minutes, state-mismatch was up to 22. We use tcp.closed > of 5 (which means 15 seconds). > > Workarounds such as "no state" suffice, but if you use rdr rules, you > MUST track state, which means there's no way of winning in that case. > For sake of example, OpenBSD spamd requires the use of rdr rules. > > Administrators then ask 3 questions: > For the sake of a helpful archive... > 1) How do I determine whether or not state-mismatch increasing is a > sign of bad things, or due to peoples' broken IP stacks, You can't. Only way you know is probably when people complain, or you notice scripts/page loads failing. > 2) What happens to packets which cause state-mismatch to increment, > e.g. are they blocked, passed, or what? Dropped. In the case of a state-mismatch during TCP handshake, an RST is sent. That's why the failure happens immediately. > 3) Why isn't state-mismatch described in detail in the documentation? > Good question. I guess because it would be difficult to document all of the reasons a state wouldn't match. It would be easier to simply document what a state _is_, but that's already in the archives. -Kian From peterjeremy at optushome.com.au Fri Jul 4 23:54:20 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Fri Jul 4 23:54:27 2008 Subject: msync() differences between Linux and FreeBSD In-Reply-To: <20080702120002.GB65355@blazingdot.com> References: <20080702120002.GB65355@blazingdot.com> Message-ID: <20080704235315.GE29380@server.vk2pj.dyndns.org> On 2008-Jul-02 05:00:02 -0700, Marcus Reid wrote: > It seems that in FreeBSD, msync() waits for bits to be >committed to disk even when MS_ASYNC is specified. Your previous ktrace output suggests that, at least for the way rrdtool is using mmap(2), physical I/O is being performed by msync(2). It's not clear whether FreeBSD is ignoring the MS_ASYNC flag (the code suggests it isn't), is blocking on previously queued I/O or is blocking for some other reason. >First off, I don't know how frequently msync() is used, and whether changing >its behavior would impact the performance of many things. The behaviour of msync(2) is defined in the Single Unix Specification and FreeBSD adheres to SUS unless there is a very good reason. > media... i.e. issue real I/O. So msync() can't be a NOP if you go by > the OpenGroup specification. > >Is there a spec that FreeBSD is adhering to that prevents msync() with >MS_ASYNC from being a NOP, seeing as munmap() does the job? As per Matt's response that you quoted, yes. > And does this >really matter for the real-world performance of some apps? IMO, rrdtool is using mmap()/madvise()/msync()/munmap() in an unusual fashion and it should be fixed, rather than changing FreeBSD to match rrdtool. I believe a more usual approach would be to mmap() a file (or part thereof), optionally call madvise(), perform a series of accesses and maybe msync()s of any updated regions then a single munmap() before exiting. Performing mmap()/msync()/munmap() (where the msync() specifies the entire file) for each update maximises system overheads for no obvious benefit. Also, you mentioned hitting a "brick wall" between 940MB and 1161MB. That straddles 1GB. You may also be running into system or process boundary conditions (how much RAM do you have and what tuning have you done). You might like to write a tool to simulate the rrdtool behaviour with varying DB sizes and identify exactly what you are hitting. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080704/01d5aed9/attachment.pgp From mnd999 at gmail.com Sat Jul 5 15:58:45 2008 From: mnd999 at gmail.com (Mark Dixon) Date: Sat Jul 5 15:58:53 2008 Subject: Net crash in ath on FREEBSD-7 STABLE Message-ID: <6C1A742B-AB45-4E72-8BA9-F333F607A55E@gmail.com> Hi, I get the following when I run portupgrade and it tries to hit the network for a package on stable. It looks like something has been broken in ath? Seeing as I don't update very often it could have been around for a while. Kernel is GENERIC. Modules are kernel, snd_ich, sound, aio and linux. If anyone wants to look at this and needs more info, let me know. Mark GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 02 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff8025e2f2 stack pointer = 0x10:0xffffffffaec9e630 frame pointer = 0x10:0xffffff00018fa100 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 16516 (fetch) trap number = 12 panic: page fault cpuid = 2 Uptime: 2m56s Physical memory: 2034 MB Dumping 251 MB: (CTRL-C to abort) 236 220 (CTRL-C to abort) 204 188 172 156 140 124 108 92 76 60 (CTRL-C to abort) 44 28 12 Reading symbols from /boot/kernel/snd_ich.ko...Reading symbols from / boot/kernel/snd_ich.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_ich.ko Reading symbols from /boot/kernel/sound.ko...Reading symbols from / boot/kernel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/kernel/aio.ko...Reading symbols from /boot/ kernel/aio.ko.symbols...done. done. Loaded symbols for /boot/kernel/aio.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from / boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko #0 doadump () at pcpu.h:194 194 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:194 #1 0x0000000000000004 in ?? () #2 0xffffffff804964a9 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #3 0xffffffff804968ad in panic (fmt=0x104
) at /usr/src/sys/kern/kern_shutdown.c:572 #4 0xffffffff8075ff74 in trap_fatal (frame=0xffffff00044d66a0, eva=18446742974267905128) at /usr/src/sys/amd64/amd64/trap.c:724 #5 0xffffffff80760345 in trap_pfault (frame=0xffffffffaec9e580, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:641 #6 0xffffffff80760c88 in trap (frame=0xffffffffaec9e580) at /usr/src/sys/amd64/amd64/trap.c:410 #7 0xffffffff8074664e in calltrap () at /usr/src/sys/amd64/amd64/exception.S:169 #8 0xffffffff8025e2f2 in ath_start (ifp=0xffffff00011cd800) at /usr/src/sys/dev/ath/if_ath.c:1747 #9 0xffffffff8052fab6 in ether_output_frame (ifp=0xffffff00011cd800, m=0xffffff000421eb00) at /usr/src/sys/net/if_ethersubr.c:405 #10 0xffffffff805300e2 in ether_output (ifp=0xffffff00011cd800, m=0xffffff000421eb00, dst=Variable "dst" is not available. ) at /usr/src/sys/net/if_ethersubr.c:374 #11 0xffffffff805755df in ip_output (m=0xffffff000421eb00, opt=Variable "opt" is not available. ) at /usr/src/sys/netinet/ip_output.c:551 #12 0xffffffff805ce48c in tcp_output (tp=0xffffff0004216b60) at /usr/src/sys/netinet/tcp_output.c:1135 #13 0xffffffff805d880d in tcp_usr_rcvd (so=Variable "so" is not available. ) at /usr/src/sys/netinet/tcp_usrreq.c:738 #14 0xffffffff804ef5cf in soreceive_generic (so=0xffffff001040c570, psa=0x0, uio=0xffffffffaec9eb00, mp0=Variable "mp0" is not available. ) at /usr/src/sys/kern/uipc_socket.c:1825 #15 0xffffffff804cee1d in dofileread (td=0xffffff00044d66a0, fd=3, fp=0xffffff00047e4168, auio=0xffffffffaec9eb00, offset=Variable "offset" is not available. ) at file.h:242 #16 0xffffffff804cf18e in kern_readv (td=0xffffff00044d66a0, fd=3, auio=0xffffffffaec9eb00) at /usr/src/sys/kern/sys_generic.c:192 #17 0xffffffff804cf27c in read (td=0xffffffff80e62000, uap=0xffffff00044d66a0) at /usr/src/sys/kern/sys_generic.c:108 #18 0xffffffff807605c7 in syscall (frame=0xffffffffaec9ec70) at /usr/src/sys/amd64/amd64/trap.c:852 #19 0xffffffff8074685b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:290 #20 0x0000000800c0297c in ?? () Previous frame inner to this frame (corrupt stack?) From jilles at stack.nl Sun Jul 6 11:15:14 2008 From: jilles at stack.nl (Jilles Tjoelker) Date: Sun Jul 6 11:15:21 2008 Subject: expand_number(3) silently truncates numeric part of the argument to 32 bit on i386, light impact on gjournal In-Reply-To: <1214770585.1079.13.camel@RabbitsDen> References: <1214770585.1079.13.camel@RabbitsDen> Message-ID: <20080706111511.GA68941@stack.nl> On Sun, Jun 29, 2008 at 04:16:25PM -0400, Alexandre Sunny Kovalenko wrote: > I honestly don't know whether it should or should not do it, and if it > should not, what errno should be set to. Program below gives following > output on RELENG_7 as of June 28th: > sunny:RabbitsDen>./expand_number 5368709120k > Result is 1099511627776 > sunny:RabbitsDen>./expand_number 5120G > Result is 5497558138880 > sunny:RabbitsDen> > One of the more interesting manifestations in the userland is that > gjournal label -s 5368709120 -f /dev/da0s1a > quietly gives you 1G of the journal in the resulting file system. > [snip program calling expand_number(3)] This happens because src/lib/libutil/expand_number.c does not include the necessary header for calling strtoimax(3). The file is compiled without compiler warnings, so the bug shows up as wrong behaviour. Adding #include fixes it. The file is slightly changed in CURRENT but the same patch should apply. -- Jilles Tjoelker -------------- next part -------------- A non-text attachment was scrubbed... Name: expand_number.patch Type: text/x-diff Size: 322 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080706/4ded021b/expand_number.bin From norwoh at comcast.net Sun Jul 6 13:41:45 2008 From: norwoh at comcast.net (norwoh@comcast.net) Date: Sun Jul 6 13:41:51 2008 Subject: Makefile in FreeBSD 7.0 Stable Message-ID: <070620081325.12363.4870C7D80001BF5A0000304B22147564020801999D0102@comcast.net> I have a fresh install of FreeBSD 7.0 but it it seems several system related modules are broken. One I would like to have a solution on urgently is the "Makefile". I am not able to compile or install any program with it. The errors are too many no matter which application I try to install from ports collection. I have not built a custom kernel yet. The behavior of Makefile worries me more than anything at the moment. pkg_ add is minimally working itself. I am also noticing that quite many apllications in the port collection are bad. Any idea for me to get started? Thanks, Saffa > From kris at FreeBSD.org Sun Jul 6 13:56:54 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Sun Jul 6 13:57:02 2008 Subject: Makefile in FreeBSD 7.0 Stable In-Reply-To: <070620081325.12363.4870C7D80001BF5A0000304B22147564020801999D0102@comcast.net> References: <070620081325.12363.4870C7D80001BF5A0000304B22147564020801999D0102@comcast.net> Message-ID: <4870CF24.30300@FreeBSD.org> norwoh@comcast.net wrote: > I have a fresh install of FreeBSD 7.0 but it it seems several system related modules are broken. One I would like to have a solution on urgently is the "Makefile". I am not able to compile or install any program with it. The errors are too many no matter which application I try to install from ports collection. I have not built a custom kernel yet. The behavior of Makefile worries me more than anything at the moment. > > pkg_ add is minimally working itself. I am also noticing that quite many apllications in the port collection are bad. Any idea for me to get started? You'll have to start by showing us exactly what you are doing, and what is going wrong. Kris From norwoh at comcast.net Sun Jul 6 19:20:53 2008 From: norwoh at comcast.net (norwoh@comcast.net) Date: Sun Jul 6 19:21:00 2008 Subject: Makefile in FreeBSD 7.0 Stable Message-ID: <070620081904.17867.487117540007643A000045CB22165662760801999D0102@comcast.net> -------------- Original message ---------------------- From: Kris Kennaway > norwoh@comcast.net wrote: > > I have a fresh install of FreeBSD 7.0 but it it seems several system related > modules are broken. One I would like to have a solution on urgently is the > "Makefile". I am not able to compile or install any program with it. The errors > are too many no matter which application I try to install from ports collection. > I have not built a custom kernel yet. The behavior of Makefile worries me more > than anything at the moment. > > > > pkg_ add is minimally working itself. I am also noticing that quite many > apllications in the port collection are bad. Any idea for me to get started? > > You'll have to start by showing us exactly what you are doing, and what > is going wrong. > Thanks ... say you have a package: cd /usr/ports/sysutils/usermin In this folder you have Makefile, distinfo, files, pkg-descr, pkg-message, and pkg-plist The issue the command while in this folder: perl Makefile voila,, you get: Semicolon seems to be missing at Makefile line 9 Bareword found where operator expected at Makefile line 11 .near "/www" [Missing operator before www?] syntax erro at Makefile line 10 Execution of Makefile aborted due to Compilation errors. And many more of these errors for each and every file/application I try to install. Thanks, SJK Saffa > > Kris > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From kris at FreeBSD.org Sun Jul 6 19:26:44 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Sun Jul 6 19:26:51 2008 Subject: Makefile in FreeBSD 7.0 Stable In-Reply-To: <070620081904.17867.487117540007643A000045CB22165662760801999D0102@comcast.net> References: <070620081904.17867.487117540007643A000045CB22165662760801999D0102@comcast.net> Message-ID: <48711C74.6050901@FreeBSD.org> norwoh@comcast.net wrote: > -------------- Original message ---------------------- > From: Kris Kennaway >> norwoh@comcast.net wrote: >>> I have a fresh install of FreeBSD 7.0 but it it seems several system related >> modules are broken. One I would like to have a solution on urgently is the >> "Makefile". I am not able to compile or install any program with it. The errors >> are too many no matter which application I try to install from ports collection. >> I have not built a custom kernel yet. The behavior of Makefile worries me more >> than anything at the moment. >>> pkg_ add is minimally working itself. I am also noticing that quite many >> apllications in the port collection are bad. Any idea for me to get started? >> >> You'll have to start by showing us exactly what you are doing, and what >> is going wrong. >> > > Thanks ... say you have a package: > cd /usr/ports/sysutils/usermin > In this folder you have Makefile, distinfo, files, pkg-descr, pkg-message, and pkg-plist > The issue the command while in this folder: > perl Makefile > voila,, you get: > > Semicolon seems to be missing at Makefile line 9 > Bareword found where operator expected at Makefile line 11 .near "/www" [Missing operator before www?] > syntax erro at Makefile line 10 > Execution of Makefile aborted due to Compilation errors. > > And many more of these errors for each and every file/application I try to install. Why are you running that command? It's not how you build ports. Take a look at the handbook for directions. Kris From cliftonr at lava.net Sun Jul 6 20:41:59 2008 From: cliftonr at lava.net (Clifton Royston) Date: Sun Jul 6 20:42:06 2008 Subject: Makefile in FreeBSD 7.0 Stable In-Reply-To: <070620081904.17867.487117540007643A000045CB22165662760801999D0102@comcast.net> References: <070620081904.17867.487117540007643A000045CB22165662760801999D0102@comcast.net> Message-ID: <20080706204151.GA24976@lava.net> On Sun, Jul 06, 2008 at 07:04:52PM +0000, norwoh@comcast.net wrote: > > -------------- Original message ---------------------- > From: Kris Kennaway > > norwoh@comcast.net wrote: > > > I have a fresh install of FreeBSD 7.0 but it it seems several system related > > modules are broken. One I would like to have a solution on urgently is the > > "Makefile". I am not able to compile or install any program with it. The errors > > are too many no matter which application I try to install from ports collection. > > I have not built a custom kernel yet. The behavior of Makefile worries me more > > than anything at the moment. > > > > > > pkg_ add is minimally working itself. I am also noticing that quite many > > apllications in the port collection are bad. Any idea for me to get started? > > > > You'll have to start by showing us exactly what you are doing, and what > > is going wrong. > > > > Thanks ... say you have a package: > cd /usr/ports/sysutils/usermin > In this folder you have Makefile, distinfo, files, pkg-descr, pkg-message, and pkg-plist > The issue the command while in this folder: > perl Makefile > voila,, you get: The command "make" is used to execute Makefiles.; Perl is not used to execute makefiles. At a guess, you seem to be confusing "Makefile" with the "Makefile.pl" included as part of many Perl packages. The "pl" extension on the latter is what indicates the use of Perl. Try "man ports" for more information about how the ports system works. As a beginner, most of the time you will simply want to use "make install". -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From beaker at hot.pl Sun Jul 6 20:45:35 2008 From: beaker at hot.pl (=?UTF-8?B?S3J6eXN6dG9mIErEmWRydWN6eWs=?=) Date: Sun Jul 6 20:45:42 2008 Subject: Marvell Yukon 88E8062 - media selection problem In-Reply-To: <20080705011612.GC671@cdnetworks.co.kr> References: <1052423937.20080630135423@hot.pl> <20080701004855.GF83626@cdnetworks.co.kr> <486A07A4.1070406@hot.pl> <20080702010929.GA87933@cdnetworks.co.kr> <486C0E69.8020603@hot.pl> <20080703015948.GB92015@cdnetworks.co.kr> <486CBA1D.6000602@hot.pl> <20080705011612.GC671@cdnetworks.co.kr> Message-ID: <48712EE8.1000701@hot.pl> Pyun YongHyeon pisze: > > Would you try the patch at the following URL? > http://people.freebsd.org/~yongari/msk/msk.88E8040.patch5 > > The diff generated against HEAD and it could be cleanly applied to > 7-stable. 7-stable also has a couple of important bug fixes. > So it would be better to use 7-stable. After applying both patches (the one from previous email and the one from http link) both interfaces work. I'm impressed :) I understand the media selection fix I am using at the moment is just a hack - but will the other patch get in the -stable anytime soon? -- Best regards, Krzysztof J?druczyk -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3221 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080706/9a8d8c2a/smime.bin From ronald-freebsd8 at klop.yi.org Mon Jul 7 08:15:40 2008 From: ronald-freebsd8 at klop.yi.org (Ronald Klop) Date: Mon Jul 7 08:15:55 2008 Subject: panic in drm In-Reply-To: References: <20080616102144.4E3312844C@ronald.office.base.nl> <1214496067.23553.42.camel@buffy.york.ac.uk> Message-ID: On Fri, 27 Jun 2008 11:55:45 +0200, Ronald Klop wrote: > On Thu, 26 Jun 2008 18:01:07 +0200, Gavin Atkinson > wrote: > >> On Thu, 2008-06-26 at 16:09 +0200, Ronald Klop wrote: >>> Hello, >>> >>> At my work I see a panic if I do this. >>> Leaf my computer on screensaver (don't no if that is necessary) and >>> come >>> back the next morning. My monitor is than black, but the light is >>> green, >>> so DPMS didn't kick in. >>> Keys or mouse don't wake up the system. CTRL-ALT-F1 switches to the >>> console and immediately triggers this panic. >>> >>> I'm running latest x.org with xf86-video-i810-1.7.4_1. The newer >>> xf86-video-intel also crashes my system sometimes when I'm working on >>> it, >>> so a downgraded. >>> >>> Any ideas, suggestions or fixes available? >> >> This sounds very familiar to me. I think I was seeing the same panic in >> 2006... >> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2006-12/msg00344.html >> >> Can you add this to src/sys/dev/drm/i915_irq.c >> >> if (!dev->irqr) { >> return DRM_ERR(EINVAL); >> } >> >> just above the DRM_WAIT_ON in i915_driver_vblank_wait() (around line >> 140), and see if that prevents the panic? Note that I believe this to >> be a workaround, and not really the correct fix. >> >> (sorry for not supplying patches, I'm not in a position to right now) >> >> Gavin > > Thanks, I'll try this next week. > > Ronald. Unfortunately, your change didn't fix it for me. I also added a DRM_ERROR message in the diff and it is never displayed. Ronald. From pyunyh at gmail.com Mon Jul 7 10:26:45 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Mon Jul 7 10:26:52 2008 Subject: Marvell Yukon 88E8062 - media selection problem In-Reply-To: <48712EE8.1000701@hot.pl> References: <1052423937.20080630135423@hot.pl> <20080701004855.GF83626@cdnetworks.co.kr> <486A07A4.1070406@hot.pl> <20080702010929.GA87933@cdnetworks.co.kr> <486C0E69.8020603@hot.pl> <20080703015948.GB92015@cdnetworks.co.kr> <486CBA1D.6000602@hot.pl> <20080705011612.GC671@cdnetworks.co.kr> <48712EE8.1000701@hot.pl> Message-ID: <20080707102433.GE8171@cdnetworks.co.kr> On Sun, Jul 06, 2008 at 10:45:28PM +0200, Krzysztof J??druczyk wrote: > Pyun YongHyeon pisze: > > > >Would you try the patch at the following URL? > >http://people.freebsd.org/~yongari/msk/msk.88E8040.patch5 > > > >The diff generated against HEAD and it could be cleanly applied to > >7-stable. 7-stable also has a couple of important bug fixes. > >So it would be better to use 7-stable. > > After applying both patches (the one from previous email and the one > from http link) both interfaces work. I'm impressed :) > Thanks a lot for testing! Since the patch had lots of code not related with 88E8062 dual port controller, would you try attached patch again? I think the attached patch is minimal one that makes 88E8062 work. The patch also try to enable MSI for dual port controllers. At the time of writing support for MSI I had no testers to experiment MSI so MSI on dual port controllers were ignored. Please see if msk(4) take advantage of MSI. irq256 or higher number would be showed in "vmstat -i" output if MSI is active. > I understand the media selection fix I am using at the moment is just a > hack - but will the other patch get in the -stable anytime soon? > I'll MFC attached patch if it work well on your hardware. -- Regards, Pyun YongHyeon -------------- next part -------------- --- sys/dev/mii/e1000phy.c.orig 2007-11-16 19:39:18.000000000 +0900 +++ sys/dev/mii/e1000phy.c 2008-07-07 16:58:31.000000000 +0900 @@ -59,6 +59,9 @@ #include "miidevs.h" #include +/* XXX */ +#include +#include #include "miibus_if.h" @@ -128,6 +131,8 @@ struct mii_softc *sc; struct mii_attach_args *ma; struct mii_data *mii; + struct ifnet *ifp; + struct msk_mii_data *mmd; int fast_ether; esc = device_get_softc(dev); @@ -148,10 +153,20 @@ esc->mii_model = MII_MODEL(ma->mii_id2); switch (esc->mii_model) { case MII_MODEL_MARVELL_E1011: - case MII_MODEL_MARVELL_E1112: if (PHY_READ(sc, E1000_ESSR) & E1000_ESSR_FIBER_LINK) sc->mii_flags |= MIIF_HAVEFIBER; break; + case MII_MODEL_MARVELL_E1112: + /* XXX */ + ifp = sc->mii_pdata->mii_ifp; + if (strcmp(ifp->if_dname, "msk") == 0) { + mmd = device_get_ivars( + device_get_parent(device_get_parent(dev))); + if (mmd != NULL && + (mmd->mii_flags & MIIF_HAVEFIBER) != 0); + sc->mii_flags |= MIIF_HAVEFIBER; + } + break; case MII_MODEL_MARVELL_E3082: /* 88E3082 10/100 Fast Ethernet PHY. */ sc->mii_anegticks = MII_ANEGTICKS; @@ -209,7 +224,7 @@ e1000phy_reset(struct mii_softc *sc) { struct e1000phy_softc *esc; - uint16_t reg; + uint16_t page, reg; esc = (struct e1000phy_softc *)sc; reg = PHY_READ(sc, E1000_SCR); @@ -217,13 +232,14 @@ reg &= ~E1000_SCR_AUTO_X_MODE; PHY_WRITE(sc, E1000_SCR, reg); if (esc->mii_model == MII_MODEL_MARVELL_E1112) { + page = PHY_READ(sc, E1000_EADR); /* Select 1000BASE-X only mode. */ PHY_WRITE(sc, E1000_EADR, 2); reg = PHY_READ(sc, E1000_SCR); reg &= ~E1000_SCR_MODE_MASK; reg |= E1000_SCR_MODE_1000BX; PHY_WRITE(sc, E1000_SCR, reg); - PHY_WRITE(sc, E1000_EADR, 1); + PHY_WRITE(sc, E1000_EADR, page); } } else { switch (esc->mii_model) { @@ -472,8 +488,8 @@ else mii->mii_media_active |= IFM_10_T; } else { - if (ssr & E1000_SSR_1000MBS) - mii->mii_media_active |= IFM_1000_SX; + /* XXX Should have a way to tell IFM_1000_SX/IFM_1000_LX. */ + mii->mii_media_active |= IFM_1000_SX; } if (ssr & E1000_SSR_DUPLEX) --- sys/dev/msk/if_msk.c.orig 2008-03-27 13:43:51.000000000 +0900 +++ sys/dev/msk/if_msk.c 2008-07-07 17:32:48.000000000 +0900 @@ -1398,6 +1398,7 @@ struct msk_softc *sc; struct msk_if_softc *sc_if; struct ifnet *ifp; + struct msk_mii_data *mmd; int i, port, error; uint8_t eaddr[6]; @@ -1407,7 +1408,8 @@ error = 0; sc_if = device_get_softc(dev); sc = device_get_softc(device_get_parent(dev)); - port = *(int *)device_get_ivars(dev); + mmd = device_get_ivars(dev); + port = mmd->port; sc_if->msk_if_dev = dev; sc_if->msk_port = port; @@ -1537,7 +1539,8 @@ mskc_attach(device_t dev) { struct msk_softc *sc; - int error, msic, msir, *port, reg; + struct msk_mii_data *mmd; + int error, i, msic, msir, reg; sc = device_get_softc(dev); sc->msk_dev = dev; @@ -1646,15 +1649,7 @@ msic = pci_msi_count(dev); if (bootverbose) device_printf(dev, "MSI count : %d\n", msic); - /* - * The Yukon II reports it can handle two messages, one for each - * possible port. We go ahead and allocate two messages and only - * setup a handler for both if we have a dual port card. - * - * XXX: I haven't untangled the interrupt handler to handle dual - * port cards with separate MSI messages, so for now I disable MSI - * on dual port cards. - */ + if (legacy_intr != 0) msi_disable = 1; if (msi_disable == 0) { @@ -1662,10 +1657,9 @@ case 2: case 1: /* 88E8058 reports 1 MSI message */ msir = msic; - if (sc->msk_num_port == 1 && - pci_alloc_msi(dev, &msir) == 0) { + if (pci_alloc_msi(dev, &msir) == 0) { if (msic == msir) { - sc->msk_msi = 1; + sc->msk_msi = msic; sc->msk_irq_spec = msic == 2 ? msk_irq_spec_msi2 : msk_irq_spec_msi; @@ -1706,15 +1700,17 @@ error = ENXIO; goto fail; } - port = malloc(sizeof(int), M_DEVBUF, M_WAITOK); - if (port == NULL) { + mmd = malloc(sizeof(struct msk_mii_data), M_DEVBUF, M_WAITOK | M_ZERO); + if (mmd == NULL) { device_printf(dev, "failed to allocate memory for " "ivars of PORT_A\n"); error = ENXIO; goto fail; } - *port = MSK_PORT_A; - device_set_ivars(sc->msk_devs[MSK_PORT_A], port); + mmd->port = MSK_PORT_A; + if (sc->msk_coppertype == 0) + mmd->mii_flags |= MIIF_HAVEFIBER; + device_set_ivars(sc->msk_devs[MSK_PORT_A], mmd); if (sc->msk_num_port > 1) { sc->msk_devs[MSK_PORT_B] = device_add_child(dev, "msk", -1); @@ -1723,15 +1719,18 @@ error = ENXIO; goto fail; } - port = malloc(sizeof(int), M_DEVBUF, M_WAITOK); - if (port == NULL) { + mmd = malloc(sizeof(struct msk_mii_data), M_DEVBUF, + M_WAITOK | M_ZERO); + if (mmd == NULL) { device_printf(dev, "failed to allocate memory for " "ivars of PORT_B\n"); error = ENXIO; goto fail; } - *port = MSK_PORT_B; - device_set_ivars(sc->msk_devs[MSK_PORT_B], port); + mmd->port = MSK_PORT_A; + if (sc->msk_coppertype == 0) + mmd->mii_flags |= MIIF_HAVEFIBER; + device_set_ivars(sc->msk_devs[MSK_PORT_B], mmd); } error = bus_generic_attach(dev); @@ -1751,8 +1750,13 @@ taskqueue_thread_enqueue, &sc->msk_tq); taskqueue_start_threads(&sc->msk_tq, 1, PI_NET, "%s taskq", device_get_nameunit(sc->msk_dev)); - error = bus_setup_intr(dev, sc->msk_irq[0], INTR_TYPE_NET | - INTR_MPSAFE, msk_intr, NULL, sc, &sc->msk_intrhand[0]); + for (i = 0; i < sc->msk_msi; i++) { + error = bus_setup_intr(dev, sc->msk_irq[i], + INTR_TYPE_NET | INTR_MPSAFE, msk_intr, NULL, sc, + &sc->msk_intrhand[i]); + if (error != 0) + break; + } } if (error != 0) { @@ -1829,6 +1833,7 @@ mskc_detach(device_t dev) { struct msk_softc *sc; + int i; sc = device_get_softc(dev); KASSERT(mtx_initialized(&sc->msk_mtx), ("msk mutex not initialized")); @@ -1866,14 +1871,20 @@ taskqueue_free(sc->msk_tq); sc->msk_tq = NULL; } - if (sc->msk_intrhand[0]) { + + if (sc->msk_msi == 0) { bus_teardown_intr(dev, sc->msk_irq[0], sc->msk_intrhand[0]); sc->msk_intrhand[0] = NULL; + } else { + for (i = 0; i < sc->msk_msi; i++) { + if (sc->msk_intrhand[i] != NULL) { + bus_teardown_intr(dev, sc->msk_irq[i], + sc->msk_intrhand[i]); + sc->msk_intrhand[i] = NULL; + } + } } - if (sc->msk_intrhand[1]) { - bus_teardown_intr(dev, sc->msk_irq[0], sc->msk_intrhand[0]); - sc->msk_intrhand[1] = NULL; - } + bus_release_resources(dev, sc->msk_irq_spec, sc->msk_irq); if (sc->msk_msi) pci_release_msi(dev); @@ -3585,6 +3596,14 @@ ifp->if_capenable &= ~(IFCAP_TSO4 | IFCAP_TXCSUM); } + /* GPHY Control reset. */ + CSR_WRITE_4(sc, MR_ADDR(sc_if->msk_port, GPHY_CTRL), GPC_RST_SET); + CSR_WRITE_4(sc, MR_ADDR(sc_if->msk_port, GPHY_CTRL), GPC_RST_CLR); + /* GMAC Control reset. */ + CSR_WRITE_4(sc, MR_ADDR(sc_if->msk_port, GMAC_CTRL), GMC_RST_SET); + CSR_WRITE_4(sc, MR_ADDR(sc_if->msk_port, GMAC_CTRL), GMC_RST_CLR); + CSR_WRITE_4(sc, MR_ADDR(sc_if->msk_port, GMAC_CTRL), GMC_F_LOOPB_OFF); + /* * Initialize GMAC first. * Without this initialization, Rx MAC did not work as expected --- sys/dev/msk/if_mskreg.h.orig 2008-02-29 12:38:12.000000000 +0900 +++ sys/dev/msk/if_mskreg.h 2008-07-07 16:18:39.000000000 +0900 @@ -2287,6 +2287,11 @@ #define MSK_TX_TIMEOUT 5 #define MSK_PUT_WM 10 +struct msk_mii_data { + int port; + int mii_flags; +}; + /* Forward decl. */ struct msk_if_softc; From eugen at kuzbass.ru Mon Jul 7 10:32:49 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Mon Jul 7 10:33:05 2008 Subject: RELENG_7: /boot/loader command prompt mode broken? Message-ID: <20080707102147.GA1221@grosbein.pp.ru> Hi! Today I've updated my 7.0-STABLE system using source upgrade path. loader(8) boots it just fine but it's impossible to issue commands using its command prompt mode (N.B.: beastie_disable="YES" and autoboot_delay="2" are in my /boot/loader.conf). At boot time, I hit "Space" button to reach its command prompt - that works. While typing of a command, I observe one of bad things: 1) it just hangs solid (keyboard LEDs do not switch) after a couple of characters entered, or 2) system spontaneously reboots while typing, or 3) it shows endless flow of hex dump, presumably from BTX. Most of time it hangs, a couple of times I've got reboot and once there was hex dump. I use vidconsole with PS/2 keyboard. Seldom I've allowed to type 'boot -s' and hit enter without a problem - it boots system OK then. So, I assume there is a problem with vidconsole input/output routines. I've rebuilt /boot/loader using sources of 7.0-RELEASE and it works nice now. My has Intel D975XBX motherboard, I use PS/2 keyboard. What should I try to debug this? Here is my /etc/src.conf: WITHOUT_ATM= WITHOUT_AUDIT= WITHOUT_AUTHPF= WITHOUT_ZFS= WITHOUT_CDDL= WITHOUT_FORTRAN= WITHOUT_GCOV= WITHOUT_HTML= WITHOUT_I4B= WITHOUT_INET6= WITHOUT_IPFILTER= WITHOUT_IPX= WITHOUT_KERBEROS= WITHOUT_PF= WITHOUT_PROFILE= And I have 'CPUTYPE?=pentium4' in /etc/make.conf Eugene Grosbein From gaijin.k at gmail.com Mon Jul 7 12:43:35 2008 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Mon Jul 7 12:43:42 2008 Subject: expand_number(3) silently truncates numeric part of the argument to 32 bit on i386, light impact on gjournal In-Reply-To: <20080706111511.GA68941@stack.nl> References: <1214770585.1079.13.camel@RabbitsDen> <20080706111511.GA68941@stack.nl> Message-ID: <1215434607.1035.1.camel@RabbitsDen> On Sun, 2008-07-06 at 13:15 +0200, Jilles Tjoelker wrote: > On Sun, Jun 29, 2008 at 04:16:25PM -0400, Alexandre Sunny Kovalenko wrote: > > I honestly don't know whether it should or should not do it, and if it > > should not, what errno should be set to. Program below gives following > > output on RELENG_7 as of June 28th: > > > sunny:RabbitsDen>./expand_number 5368709120k > > Result is 1099511627776 > > sunny:RabbitsDen>./expand_number 5120G > > Result is 5497558138880 > > sunny:RabbitsDen> > > > One of the more interesting manifestations in the userland is that > > > gjournal label -s 5368709120 -f /dev/da0s1a > > > quietly gives you 1G of the journal in the resulting file system. > > [snip program calling expand_number(3)] > > This happens because src/lib/libutil/expand_number.c does not include > the necessary header for calling strtoimax(3). The file is > compiled without compiler warnings, so the bug shows up as wrong > behaviour. > > Adding #include fixes it. > > The file is slightly changed in CURRENT but the same patch should apply. This worked beautifully on RELENG_7. Will you be commiting this or do I need to open a PR? Thank you. -- Alexandre "Sunny" Kovalenko (????????? ?????????) From beaker at hot.pl Mon Jul 7 19:00:53 2008 From: beaker at hot.pl (=?UTF-8?B?S3J6eXN6dG9mIErEmWRydWN6eWs=?=) Date: Mon Jul 7 19:01:03 2008 Subject: Marvell Yukon 88E8062 - media selection problem In-Reply-To: <20080707102433.GE8171@cdnetworks.co.kr> References: <1052423937.20080630135423@hot.pl> <20080701004855.GF83626@cdnetworks.co.kr> <486A07A4.1070406@hot.pl> <20080702010929.GA87933@cdnetworks.co.kr> <486C0E69.8020603@hot.pl> <20080703015948.GB92015@cdnetworks.co.kr> <486CBA1D.6000602@hot.pl> <20080705011612.GC671@cdnetworks.co.kr> <48712EE8.1000701@hot.pl> <20080707102433.GE8171@cdnetworks.co.kr> Message-ID: <487263EF.6070003@hot.pl> Pyun YongHyeon wrote: > Since the patch had lots of code not related with 88E8062 dual port > controller, would you try attached patch again? I think the attached > patch is minimal one that makes 88E8062 work. > > The patch also try to enable MSI for dual port controllers. At the > time of writing support for MSI I had no testers to experiment MSI so > MSI on dual port controllers were ignored. Please see if msk(4) take > advantage of MSI. irq256 or higher number would be showed in "vmstat > -i" output if MSI is active. > # vmstat -i interrupt total rate irq14: ata0 1450 1 irq16: fxp0 uhci0 2058 1 cpu0: timer 2705189 1999 irq256: mskc0 92 0 cpu1: timer 2704883 1999 Total 5413672 4001 I guess MSI is enabled. As of the results of tests I'm not sure what to start with... Initially both interfaces seemed non-functional with nothing getting transmitted to other machine. Then I noticed that it seems that msk1 seemed to receive packets that should be on msk0 (?): > # tcpdump -i msk1 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on msk1, link-type EN10MB (Ethernet), capture size 96 bytes > 20:28:41.757722 arp who-has 192.168.0.1 tell 192.168.0.2 192.168.0.2 is on em0 on other machine, and should be on the same switch as msk0. At least this was the case on previous tests in which both interfaces worked... Another time on the same test corrupted data was received: > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on msk1, link-type EN10MB (Ethernet), capture size 96 bytes > 20:31:29.806041 d3:04:ff:ff:ff:ff (oui Unknown) > 22:a0:00:00:02:f0 (oui Unknown), ethertype Unknown (0x3cc0), length 60: > 0x0000: de07 0000 0000 0000 0000 0000 0000 0000 ................ > 0x0010: 0000 ffff ffff ffff 0002 0406 0800 0806 ................ > 0x0020: 0001 0800 0604 0001 0002 0406 0800 .............. And later magically the msk1 <-> em0 link started working... Seems to work just fine after reboot (I didn't try to power down machine, just shutdown -r). So to sum up - in the end mks1 interface worked in some weird way - but it seemed to represent the link that was under msk0 previously. -- Best regards, Krzysztof J?druczyk From alan.bryan at yahoo.com Mon Jul 7 21:13:01 2008 From: alan.bryan at yahoo.com (alan bryan) Date: Mon Jul 7 21:13:08 2008 Subject: em0 no longer working after upgrading from 7.0 Release to Stable Message-ID: <917833.26158.qm@web50506.mail.re2.yahoo.com> I have a brand new Supermicro server that seems to be having issues with the em devices. I installed FreeBSD 7.0-Release from CDs and everything was working fine and then decided to cvsup to 7 stable and then I lost my em devices and thus networking. Reboots/power cycling didn't change it - no em at all since the upgrade to 7-Stable. I stuck in a USB to Ethernet stick (axe0) so I could get the server online to get this info. This is the Motherboard: http://www.supermicro.com/products/motherboard/Xeon1333/5400/X7DWN+.cfm Here's some more info: > > kenv | grep smbios > smbios.bios.reldate="04/30/2008" > smbios.bios.vendor="Phoenix Technologies LTD" > smbios.bios.version=" 1.1" > smbios.chassis.maker="Supermicro" > smbios.chassis.serial="0123456789" > smbios.chassis.tag=" " > smbios.chassis.version="0123456789" > smbios.planar.maker="Supermicro" > smbios.planar.product="X7DWN+" > smbios.planar.serial="0123456789" > smbios.planar.version="PCB Version" > smbios.socket.enabled="1" > smbios.socket.populated="1" > smbios.system.maker="Supermicro" > smbios.system.product="X7DW3" > smbios.system.serial="0123456789" > smbios.system.uuid="53d19f64-d663-a017-8922-003048c32782" > smbios.system.version="0123456789" > > > > > > pciconf -lv > hostb0@pci0:0:0:0: class=0x060000 card=0xa28015d9 chip=0x40038086 > rev=0x20 hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > pcib1@pci0:0:1:0: class=0x060400 card=0xa28015d9 chip=0x40218086 > rev=0x20 hdr=0x01 > vendor = 'Intel Corporation' > device = '(??) PCIe Port 1' > class = bridge > subclass = PCI-PCI > pcib2@pci0:0:3:0: class=0x060400 card=0xa28015d9 chip=0x40238086 > rev=0x20 hdr=0x01 > vendor = 'Intel Corporation' > device = '(??) PCIe Port 3' > class = bridge > subclass = PCI-PCI > pcib3@pci0:0:5:0: class=0x060400 card=0xa28015d9 chip=0x40258086 > rev=0x20 hdr=0x01 > vendor = 'Intel Corporation' > device = '(??) PCIe Port 5' > class = bridge > subclass = PCI-PCI > pcib4@pci0:0:7:0: class=0x060400 card=0xa28015d9 chip=0x40278086 > rev=0x20 hdr=0x01 > vendor = 'Intel Corporation' > device = '(??) PCIe Port 7' > class = bridge > subclass = PCI-PCI > pcib8@pci0:0:9:0: class=0x060400 card=0xa28015d9 chip=0x40298086 > rev=0x20 hdr=0x01 > vendor = 'Intel Corporation' > device = '(??) PCIe Port 9' > class = bridge > subclass = PCI-PCI > none0@pci0:0:15:0: class=0x088000 card=0xa28015d9 chip=0x402f8086 > rev=0x20 hdr=0x00 > vendor = 'Intel Corporation' > device = '(??) DMA/DCA Engine' > class = base peripheral > hostb1@pci0:0:16:0: class=0x060000 card=0xa28015d9 chip=0x40308086 > rev=0x20 hdr=0x00 > vendor = 'Intel Corporation' > device = '(??) FSB Registers' > class = bridge > subclass = HOST-PCI > hostb2@pci0:0:16:1: class=0x060000 card=0xa28015d9 chip=0x40308086 > rev=0x20 hdr=0x00 > vendor = 'Intel Corporation' > device = '(??) FSB Registers' > class = bridge > subclass = HOST-PCI > hostb3@pci0:0:16:2: class=0x060000 card=0xa28015d9 chip=0x40308086 > rev=0x20 hdr=0x00 > vendor = 'Intel Corporation' > device = '(??) FSB Registers' > class = bridge > subclass = HOST-PCI > hostb4@pci0:0:16:3: class=0x060000 card=0xa28015d9 chip=0x40308086 > rev=0x20 hdr=0x00 > vendor = 'Intel Corporation' > device = '(??) FSB Registers' > class = bridge > subclass = HOST-PCI > hostb5@pci0:0:16:4: class=0x060000 card=0xa28015d9 chip=0x40308086 > rev=0x20 hdr=0x00 > vendor = 'Intel Corporation' > device = '(??) FSB Registers' > class = bridge > subclass = HOST-PCI > hostb6@pci0:0:17:0: class=0x060000 card=0xa28015d9 chip=0x40318086 > rev=0x20 hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > hostb7@pci0:0:21:0: class=0x060000 card=0xa28015d9 chip=0x40358086 > rev=0x20 hdr=0x00 > vendor = 'Intel Corporation' > device = '(??) FBD Registers' > class = bridge > subclass = HOST-PCI > hostb8@pci0:0:21:1: class=0x060000 card=0xa28015d9 chip=0x40358086 > rev=0x20 hdr=0x00 > vendor = 'Intel Corporation' > device = '(??) FBD Registers' > class = bridge > subclass = HOST-PCI > hostb9@pci0:0:22:0: class=0x060000 card=0xa28015d9 chip=0x40368086 > rev=0x20 hdr=0x00 > vendor = 'Intel Corporation' > device = '(??) FBD Registers' > class = bridge > subclass = HOST-PCI > hostb10@pci0:0:22:1: class=0x060000 card=0xa28015d9 chip=0x40368086 > rev=0x20 hdr=0x00 > vendor = 'Intel Corporation' > device = '(??) FBD Registers' > class = bridge > subclass = HOST-PCI > pcib9@pci0:0:28:0: class=0x060400 card=0xa28015d9 chip=0x26908086 > rev=0x09 hdr=0x01 > vendor = 'Intel Corporation' > device = '631xESB/632xESB/3100 PCIe Root Port 1' > class = bridge > subclass = PCI-PCI > uhci0@pci0:0:29:0: class=0x0c0300 card=0xa28015d9 chip=0x26888086 > rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = '631xESB/632xESB/3100 Chipset USB Universal Host > Controller' > class = serial bus > subclass = USB > uhci1@pci0:0:29:1: class=0x0c0300 card=0xa28015d9 chip=0x26898086 > rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = '631xESB/632xESB/3100 Chipset USB Universal Host > Controller' > class = serial bus > subclass = USB > uhci2@pci0:0:29:2: class=0x0c0300 card=0xa28015d9 chip=0x268a8086 > rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = '631xESB/632xESB/3100 Chipset USB Universal Host > Controller' > class = serial bus > subclass = USB > ehci0@pci0:0:29:7: class=0x0c0320 card=0xa28015d9 chip=0x268c8086 > rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = '631xESB/632xESB/3100 Chipset USB2 Enhanced Host > Controller' > class = serial bus > subclass = USB > pcib10@pci0:0:30:0: class=0x060401 card=0xa28015d9 chip=0x244e8086 > rev=0xd9 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801 Family (ICH2/3/4/4/5/5/6/7/8/9,63xxESB) Hub > Interface to PCI Bridge' > class = bridge > subclass = PCI-PCI > isab0@pci0:0:31:0: class=0x060100 card=0xa28015d9 chip=0x26708086 > rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = '631xESB/632xESB/3100 LPC Interface Controller' > class = bridge > subclass = PCI-ISA > atapci0@pci0:0:31:1: class=0x01018a card=0xa28015d9 chip=0x269e8086 > rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = '631xESB/632xESB/3100 Ultra ATA Storage Controller' > class = mass storage > subclass = ATA > atapci1@pci0:0:31:2: class=0x010601 card=0xa28015d9 chip=0x26818086 > rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = '62089A2 LSI LOGIC, 62089A2, LSISAS1068 B0, T 0620, > WE 119200.1' > class = mass storage > none1@pci0:0:31:3: class=0x0c0500 card=0xa28015d9 chip=0x269b8086 > rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = '631xESB/632xESB/3100 SMBus Controller' > class = serial bus > subclass = SMBus > pcib5@pci0:4:0:0: class=0x060400 card=0xa28015d9 chip=0x35008086 > rev=0x01 hdr=0x01 > vendor = 'Intel Corporation' > device = '631xESB/632xESB PCIe Upstream Port' > class = bridge > subclass = PCI-PCI > pcib7@pci0:4:0:3: class=0x060400 card=0xa28015d9 chip=0x350c8086 > rev=0x01 hdr=0x01 > vendor = 'Intel Corporation' > device = '631xESB/632xESB PCIe to PCI-X Bridge' > class = bridge > subclass = PCI-PCI > pcib6@pci0:5:0:0: class=0x060400 card=0xa28015d9 chip=0x35108086 > rev=0x01 hdr=0x01 > vendor = 'Intel Corporation' > device = '631xESB/632xESB PCIe Downstream Port E1' > class = bridge > subclass = PCI-PCI > twa0@pci0:7:2:0: class=0x010400 card=0x100313c1 chip=0x100313c1 > rev=0x00 hdr=0x00 > vendor = '3ware Inc.' > device = '9550SX/9590SE Series SATA2 Raid Controller' > class = mass storage > subclass = RAID > none2@pci0:8:0:0: class=0x020000 card=0x10a715d9 chip=0x10a78086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > none3@pci0:8:0:1: class=0x020000 card=0x10a715d9 chip=0x10a78086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > vgapci0@pci0:10:1:0: class=0x030000 card=0xa28015d9 chip=0x515e1002 > rev=0x02 hdr=0x00 > vendor = 'ATI Technologies Inc' > device = 'Radeon ES1000 Radeon ES1000' > class = display > subclass = VGA From oberman at es.net Mon Jul 7 21:21:12 2008 From: oberman at es.net (Kevin Oberman) Date: Mon Jul 7 21:21:20 2008 Subject: RELENG_7: /boot/loader command prompt mode broken? In-Reply-To: Your message of "Mon, 07 Jul 2008 18:21:47 +0800." <20080707102147.GA1221@grosbein.pp.ru> Message-ID: <20080707211045.90F274500E@ptavv.es.net> > Date: Mon, 7 Jul 2008 18:21:47 +0800 > From: Eugene Grosbein > Sender: owner-freebsd-stable@freebsd.org > > Hi! > > Today I've updated my 7.0-STABLE system using source upgrade path. > loader(8) boots it just fine but it's impossible to issue commands > using its command prompt mode (N.B.: beastie_disable="YES" > and autoboot_delay="2" are in my /boot/loader.conf). > > At boot time, I hit "Space" button to reach its command prompt - that works. > While typing of a command, I observe one of bad things: > > 1) it just hangs solid (keyboard LEDs do not switch) after a couple > of characters entered, or > 2) system spontaneously reboots while typing, or > 3) it shows endless flow of hex dump, presumably from BTX. > > Most of time it hangs, a couple of times I've got reboot > and once there was hex dump. I use vidconsole with PS/2 keyboard. > > Seldom I've allowed to type 'boot -s' and hit enter without a problem - > it boots system OK then. So, I assume there is a problem > with vidconsole input/output routines. > > I've rebuilt /boot/loader using sources of 7.0-RELEASE and it works nice now. > My has Intel D975XBX motherboard, I use PS/2 keyboard. > What should I try to debug this? > > Here is my /etc/src.conf: > > WITHOUT_ATM= > WITHOUT_AUDIT= > WITHOUT_AUTHPF= > WITHOUT_ZFS= > WITHOUT_CDDL= > WITHOUT_FORTRAN= > WITHOUT_GCOV= > WITHOUT_HTML= > WITHOUT_I4B= > WITHOUT_INET6= > WITHOUT_IPFILTER= > WITHOUT_IPX= > WITHOUT_KERBEROS= > WITHOUT_PF= > WITHOUT_PROFILE= > > And I have 'CPUTYPE?=pentium4' in /etc/make.conf > > Eugene Grosbein > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > Eugene, Just a shot in the dark, but do you have a /boot.config file on the system? We have had a similar issue on a few systems and concluded that it could be "fixed' by rolling back to an older loader binary or by removing the /boot.config file. Added data on this would be helpful. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080707/6182cded/attachment.pgp From oberman at es.net Mon Jul 7 21:22:06 2008 From: oberman at es.net (Kevin Oberman) Date: Mon Jul 7 21:22:13 2008 Subject: RELENG_7: /boot/loader command prompt mode broken? In-Reply-To: Your message of "Mon, 07 Jul 2008 18:21:47 +0800." <20080707102147.GA1221@grosbein.pp.ru> Message-ID: <20080707211317.1913A4500E@ptavv.es.net> > Date: Mon, 7 Jul 2008 18:21:47 +0800 > From: Eugene Grosbein > Sender: owner-freebsd-stable@freebsd.org > > Hi! > > Today I've updated my 7.0-STABLE system using source upgrade path. > loader(8) boots it just fine but it's impossible to issue commands > using its command prompt mode (N.B.: beastie_disable="YES" > and autoboot_delay="2" are in my /boot/loader.conf). > > At boot time, I hit "Space" button to reach its command prompt - that works. > While typing of a command, I observe one of bad things: > > 1) it just hangs solid (keyboard LEDs do not switch) after a couple > of characters entered, or > 2) system spontaneously reboots while typing, or > 3) it shows endless flow of hex dump, presumably from BTX. > > Most of time it hangs, a couple of times I've got reboot > and once there was hex dump. I use vidconsole with PS/2 keyboard. > > Seldom I've allowed to type 'boot -s' and hit enter without a problem - > it boots system OK then. So, I assume there is a problem > with vidconsole input/output routines. > > I've rebuilt /boot/loader using sources of 7.0-RELEASE and it works nice now. > My has Intel D975XBX motherboard, I use PS/2 keyboard. > What should I try to debug this? > > Here is my /etc/src.conf: > > WITHOUT_ATM= > WITHOUT_AUDIT= > WITHOUT_AUTHPF= > WITHOUT_ZFS= > WITHOUT_CDDL= > WITHOUT_FORTRAN= > WITHOUT_GCOV= > WITHOUT_HTML= > WITHOUT_I4B= > WITHOUT_INET6= > WITHOUT_IPFILTER= > WITHOUT_IPX= > WITHOUT_KERBEROS= > WITHOUT_PF= > WITHOUT_PROFILE= > > And I have 'CPUTYPE?=pentium4' in /etc/make.conf > > Eugene Grosbein Eugene, I forgot to mention that you should probably look at the "Problem with /boot/loader" thread from June 26 and a bit later. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080707/3b1cf1fa/attachment.pgp From delphij at delphij.net Mon Jul 7 21:22:45 2008 From: delphij at delphij.net (Xin LI) Date: Mon Jul 7 21:22:52 2008 Subject: em0 no longer working after upgrading from 7.0 Release to Stable In-Reply-To: <917833.26158.qm@web50506.mail.re2.yahoo.com> References: <917833.26158.qm@web50506.mail.re2.yahoo.com> Message-ID: <48728913.7050105@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Alan, alan bryan wrote: | I have a brand new Supermicro server that seems to be having issues with the em devices. I installed FreeBSD 7.0-Release from CDs and everything was working fine and then decided to cvsup to 7 stable and then I lost my em devices and thus networking. Reboots/power cycling didn't change it - no em at all since the upgrade to 7-Stable. I stuck in a USB to Ethernet stick (axe0) so I could get the server online to get this info. | | This is the Motherboard: | http://www.supermicro.com/products/motherboard/Xeon1333/5400/X7DWN+.cfm | | Here's some more info: [...] |> none2@pci0:8:0:0: class=0x020000 card=0x10a715d9 chip=0x10a78086 |> rev=0x02 hdr=0x00 |> vendor = 'Intel Corporation' |> class = network |> subclass = ethernet |> none3@pci0:8:0:1: class=0x020000 card=0x10a715d9 chip=0x10a78086 |> rev=0x02 hdr=0x00 |> vendor = 'Intel Corporation' |> class = network |> subclass = ethernet Looks like you are using 82575EB, which is now using igb(4) driver. Are you running a customized kernel which does not have igb in it? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkhyiRMACgkQi+vbBBjt66CzEQCgtDetU3LVkUYxgArq6ljPpuph JJMAnjs70h2/QCkzYqqBZseyR4ibwklG =TRPV -----END PGP SIGNATURE----- From maya at negeta.com Mon Jul 7 21:46:22 2008 From: maya at negeta.com (NAGATA Shinya) Date: Mon Jul 7 21:46:33 2008 Subject: Realtek 8102EL Message-ID: <86wsjxpehl.wl%maya@negeta.com> I got Intel D945GCLF and it has Realtek 8102EL chip. But it is not found by kernel. dmesg does not display as 're' or 'rl'. How to find hwrev (revision code) to add if_rlreg.h and if_re.c ? I'm using 6.3-R and added this change, but revision is not displayed. http://www.jp.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/re/if_re.c.diff?r1=1.122&r2=1.123 Here is a result of pciconf. | % pciconf -lv | none2@pci1:0:0: class=0x020000 card=0x00018086 chip=0x813610ec rev=0x02 hdr=0x00 | vendor = 'Realtek Semiconductor' | device = 'RTL8139/810x Family Fast Ethernet NIC' | class = network | subclass = ethernet -- NAGATA Shinya From delphij at delphij.net Mon Jul 7 21:57:23 2008 From: delphij at delphij.net (Xin LI) Date: Mon Jul 7 21:57:31 2008 Subject: Realtek 8102EL In-Reply-To: <86wsjxpehl.wl%maya@negeta.com> References: <86wsjxpehl.wl%maya@negeta.com> Message-ID: <48729132.10307@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 NAGATA Shinya wrote: | I got Intel D945GCLF and it has Realtek 8102EL chip. | But it is not found by kernel. dmesg does not display as 're' or 'rl'. | | How to find hwrev (revision code) to add if_rlreg.h and if_re.c ? | I'm using 6.3-R and added this change, but revision is not displayed. | http://www.jp.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/re/if_re.c.diff?r1=1.122&r2=1.123 | | Here is a result of pciconf. | | % pciconf -lv | | none2@pci1:0:0: class=0x020000 card=0x00018086 chip=0x813610ec rev=0x02 hdr=0x00 | | vendor = 'Realtek Semiconductor' | | device = 'RTL8139/810x Family Fast Ethernet NIC' | | class = network | | subclass = ethernet Er.... Actually I have no idea why this does not get probed, the required change was merged back in 2006. Could you please try 'boot -v' and see if there is some error messages? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkhykTEACgkQi+vbBBjt66AGeACeOz1xDQ2nUuK7S1zXQnwMUKki USgAn2U7+g75Yl7ybJ8FmlsiDeD8a2p+ =SgaI -----END PGP SIGNATURE----- From maya at negeta.com Mon Jul 7 22:35:35 2008 From: maya at negeta.com (NAGATA Shinya) Date: Mon Jul 7 22:35:43 2008 Subject: Realtek 8102EL In-Reply-To: <48729132.10307@delphij.net> References: <86wsjxpehl.wl%maya@negeta.com> <48729132.10307@delphij.net> Message-ID: <86lk0ds4p9.wl%maya@negeta.com> > Could you please try 'boot -v' and see if there is some error messages? 're0' is displayed. But it seems like kernel couldn't find a driver. | re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x2000 | pci1: at device 0.0 (no driver attached) -- NAGATA Shinya -------------- next part -------------- Consoles: internal video/keyboard serial port BIOS drive C: is disk0 BIOS 572kB/2085068kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 (root@example.com, Sun Jan 20 16:55:43 JST 2008) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x5de988 data=0xa52e0+0x5494c syms=[0x4+0x6f1c0+0x4+0x8a85c] /boot/kernel/accf_data.ko text=0x4fc data=0xd4 syms=[0x4+0x210+0x4+0x1a0] /boot/kernel/accf_http.ko text=0xc1c data=0x154+0x4 syms=[0x4+0x310+0x4+0x334] \ Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 9 seconds... Type '?' for a list of commands, 'help' for more detailed help. OK boot -v /boot/kernel/acpi.ko text=0x47c9c data=0x24c0+0x1b8c syms=[0x4+0x7d50+0x4+0xaae0] SMAP type=01 base=0000000000000000 len=000000000008f000 SMAP type=02 base=000000000008f000 len=0000000000011000 SMAP type=02 base=00000000000e0000 len=0000000000020000 SMAP type=01 base=0000000000100000 len=000000007f433000 SMAP type=02 base=000000007f533000 len=0000000000008000 SMAP type=01 base=000000007f53b000 len=0000000000090000 SMAP type=02 base=000000007f5cb000 len=0000000000004000 SMAP type=01 base=000000007f5cf000 len=0000000000092000 SMAP type=04 base=000000007f661000 len=000000000008f000 SMAP type=01 base=000000007f6f0000 len=0000000000003000 SMAP type=03 base=000000007f6f3000 len=000000000000c000 SMAP type=01 base=000000007f6ff000 len=0000000000001000 SMAP type=02 base=000000007f700000 len=0000000000100000 SMAP type=02 base=000000007f800000 len=0000000000800000 SMAP type=02 base=00000000f0000000 len=000000000ff80000 SMAP type=02 base=00000000fff80000 len=0000000000080000 Copyright (c) 1992-2008 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.3-RELEASE-p2 #2: Mon Jul 7 22:49:30 JST 2008 root@example.com:/usr/obj/usr/src/sys/Atom Preloaded elf kernel "/boot/kernel/kernel" at 0xc0c39000. Preloaded elf module "/boot/kernel/accf_data.ko" at 0xc0c39220. Preloaded elf module "/boot/kernel/accf_http.ko" at 0xc0c392d0. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0c39380. MP Configuration Table version 1.4 found at 0xc00fe210 Table 'FACP' at 0x7f6fc000 Table 'APIC' at 0x7f6f6000 MADT: Found table at 0x7f6f6000 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled MADT: Found CPU APIC ID 1 ACPI ID 2: enabled MADT: Found CPU APIC ID 130 ACPI ID 3: disabled MADT: Found CPU APIC ID 131 ACPI ID 4: disabled ACPI APIC Table: Calibrating clock(s) ... i8254 clock: 1190829 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1599284340 Hz CPU: Intel(R) Atom(TM) CPU 230 @ 1.60GHz (1599.28-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106c2 Stepping = 2 Features=0xbfe9fbff Features2=0x40e31d> AMD Features=0x20100000 AMD Features2=0x1 Logical CPUs per core: 2 real memory = 2137395200 (2038 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000008efff, 581632 bytes (142 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001025000 - 0x000000007d11dfff, 2081394688 bytes (508153 pages) 0x000000007f53b000 - 0x000000007f5cafff, 589824 bytes (144 pages) 0x000000007f5cf000 - 0x000000007f650fff, 532480 bytes (130 pages) avail memory = 2082291712 (1985 MB) pnpbios: Found PnP BIOS data at 0xc00fe0e0 pnpbios: Entry = f0000:af29 Rev = 1.0 pnpbios: OEM ID 8224744e Other BIOS signatures found: APIC: CPU 0 has ACPI ID 1 MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level lapic0: Routing NMI -> LINT1 lapic1: Routing NMI -> LINT1 ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 wlan: <802.11 Link Layer> ath_rate: version 1.2 null: random: nfslock: pseudo-device io: kbd0 at kbdmux0 mem: Pentium Pro MTRR support enabled ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) rr232x: RocketRAID 232x controller driver v1.02 (Jul 7 2008 22:49:02) hptrr: HPT RocketRAID controller driver v1.1 (Jul 7 2008 22:48:58) npx0: INT 16 interface acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80001014 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=27708086) pcibios: No call entry point acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \_SB_.PCI0.LPC_.PRR0 -> bus 0 dev 31 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \_SB_.PCI0.LPC_.PRR1 -> bus 0 dev 31 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \_SB_.PCI0.LPC_.IELK.ELR0 -> bus 0 dev 0 func 0 acpi0: Power Button (fixed) acpi0: wakeup code va 0xda72c000 pa 0x8e000 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \_SB_.PCI0.TMEM -> bus 0 dev 0 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \_SB_.PCI0.PAMX -> bus 0 dev 0 func 0 ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 7 9 10 11 12 Validation 0 11 N 0 3 4 5 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 9 10 11 12 Validation 0 255 N 0 3 4 5 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 9 N 0 3 4 5 7 9 10 11 12 Validation 0 9 N 0 3 4 5 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 7 9 10 11 12 Validation 0 11 N 0 3 4 5 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 9 10 11 12 Validation 0 255 N 0 3 4 5 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 7 9 10 11 12 Validation 0 10 N 0 3 4 5 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 9 N 0 3 4 5 7 9 10 11 12 Validation 0 9 N 0 3 4 5 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 7 9 10 11 12 Validation 0 10 N 0 3 4 5 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 cpu0: on acpi0 cpu0: switching to generic Cx mode acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x8086, dev=0x2770, revid=0x02 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2772, revid=0x02 bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type 1, range 32, base 90300000, size 19, enabled map[14]: type 4, range 32, base 000030e0, size 3, enabled map[18]: type 3, range 32, base 80000000, size 28, enabled map[1c]: type 1, range 32, base 90380000, size 18, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27d8, revid=0x01 bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=9 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 1, range 64, base 903c0000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x27d0, revid=0x01 bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x8086, dev=0x27d4, revid=0x01 bus=0, slot=28, func=2 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=c, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x8086, dev=0x27d6, revid=0x01 bus=0, slot=28, func=3 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=d, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x8086, dev=0x27c8, revid=0x01 bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[20]: type 4, range 32, base 00003080, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x27c9, revid=0x01 bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type 4, range 32, base 00003060, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x27ca, revid=0x01 bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=9 map[20]: type 4, range 32, base 00003040, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x27cb, revid=0x01 bus=0, slot=29, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 map[20]: type 4, range 32, base 00003020, size 5, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27cc, revid=0x01 bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base 903c4000, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x244e, revid=0xe1 bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27b8, revid=0x01 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27df, revid=0x01 bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0288, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=9 map[20]: type 4, range 32, base 000030b0, size 4, enabled pcib0: matched entry for 0.31.INTA pcib0: slot 31 INTA hardwired to IRQ 18 found-> vendor=0x8086, dev=0x27c0, revid=0x01 bus=0, slot=31, func=2 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 000030c8, size 3, enabled map[14]: type 4, range 32, base 000030ec, size 2, enabled map[18]: type 4, range 32, base 000030c0, size 3, enabled map[1c]: type 4, range 32, base 000030e8, size 2, enabled map[20]: type 4, range 32, base 000030a0, size 4, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x27da, revid=0x01 bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type 4, range 32, base 00003000, size 5, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 agp0: port 0x30e0-0x30e7 mem 0x90300000-0x9037ffff,0x80000000-0x8fffffff,0x90380000-0x903bffff irq 16 at device 2.0 on pci0 agp0: Reserved 0x80000 bytes for rid 0x10 type 3 at 0x90300000 agp0: Reserved 0x80000 bytes for rid 0x10 type 3 at 0x90300000 agp0: Reserved 0x40000 bytes for rid 0x1c type 3 at 0x90380000 agp0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0x80000000 agp0: detected 7932k stolen memory agp0: aperture size is 256M pci0: at device 27.0 (no driver attached) pcib1: at device 28.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x2000-0x2fff pcib1: memory decode 0x90200000-0x902fffff pcib1: prefetched decode 0x90000000-0x900fffff pci1: on pcib1 pci1: physical bus=1 found-> vendor=0x10ec, dev=0x8136, revid=0x02 bus=1, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 2 messages in map 0x20 map[10]: type 4, range 32, base 00002000, size 8, enabled pcib1: requested I/O range 0x2000-0x20ff: in range map[18]: type 1, range 64, base 90200000, size 12, enabled pcib1: requested memory range 0x90200000-0x90200fff: good map[20]: type 3, range 64, base 90000000, size 16, enabled pcib1: requested memory range 0x90000000-0x9000ffff: good pcib1: matched entry for 1.0.INTA pcib1: slot 0 INTA hardwired to IRQ 16 re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x2000 pci1: at device 0.0 (no driver attached) pcib2: at device 28.2 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xf000-0xfff pcib2: memory decode 0xfff00000-0xfffff pcib2: prefetched decode 0xfff00000-0xfffff pci2: on pcib2 pci2: physical bus=2 pcib3: at device 28.3 on pci0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xf000-0xfff pcib3: memory decode 0xfff00000-0xfffff pcib3: prefetched decode 0xfff00000-0xfffff pci3: on pcib3 pci3: physical bus=3 uhci0: port 0x3080-0x309f irq 23 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3080 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 49 uhci0: [GIANT-LOCKED] usb0: 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: port 0x3060-0x307f irq 19 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3060 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 50 uhci1: [GIANT-LOCKED] usb1: 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: port 0x3040-0x305f irq 18 at device 29.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3040 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 51 uhci2: [GIANT-LOCKED] usb2: 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: port 0x3020-0x303f irq 16 at device 29.3 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3020 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 52 uhci3: [GIANT-LOCKED] usb3: 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: mem 0x903c4000-0x903c43ff irq 23 at device 29.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0x903c4000 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib4: at device 30.0 on pci0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0x1000-0x1fff pcib4: memory decode 0x90100000-0x901fffff pcib4: prefetched decode 0xfff00000-0xfffff pcib4: Subtractively decoded bridge. pci4: on pcib4 pci4: physical bus=4 found-> vendor=0x9005, dev=0x0080, revid=0x02 bus=4, slot=0, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x28 (10000 ns), maxlat=0x19 (6250 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 00001000, size 8, enabled pcib4: requested I/O range 0x1000-0x10ff: in range map[14]: type 1, range 64, base 90100000, size 12, enabled pcib4: requested memory range 0x90100000-0x90100fff: good pcib4: matched entry for 4.0.INTA pcib4: slot 0 INTA hardwired to IRQ 21 ahc0: port 0x1000-0x10ff mem 0x90100000-0x90100fff irq 21 at device 0.0 on pci4 ahc0: Defaulting to MEMIO off ahc0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x1000 ahc0: Reading SEEPROM...done. ahc0: BIOS eeprom is present ahc0: Secondary Low byte termination Enabled ahc0: Primary Low Byte termination Enabled ahc0: Primary High Byte termination Enabled ahc0: Downloading Sequencer Program... 423 instructions downloaded ahc0: Features 0x1def6, Bugs 0x40, Flags 0x20485560 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 53 ahc0: [GIANT-LOCKED] aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30b0-0x30bf irq 18 at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x30b0 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=00 ostat1=00 ata0: stat0=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: stat1=0x0f err=0x0f lsb=0x0f msb=0x0f ata0: stat1=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat1=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat1=0x0f err=0x0f lsb=0x0f msb=0x0f ata0: stat1=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat1=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat1=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat1=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat1=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat1=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=00 stat1=00 devices=0x0 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 54 ata0: [MPSAFE] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=00 ostat0=ff ostat1=ff ioapic0: routing intpin 15 (ISA IRQ 15) to vector 55 ata1: [MPSAFE] atapci1: port 0x30c8-0x30cf,0x30ec-0x30ef,0x30c0-0x30c7,0x30e8-0x30eb,0x30a0-0x30af irq 19 at device 31.2 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0x30a0 atapci1: [MPSAFE] ata2: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x30c8 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0x30ec ata2: reset tp1 mask=03 ostat0=7f ostat1=7f ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat1=0x7f err=0xff lsb=0xff msb=0xff ata2: reset tp2 stat0=ff stat1=ff devices=0x0 ata2: [MPSAFE] ata3: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x30c0 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0x30e8 ata3: reset tp1 mask=03 ostat0=7f ostat1=7f ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat1=0x7f err=0xff lsb=0xff msb=0xff ata3: reset tp2 stat0=ff stat1=ff devices=0x0 ata3: [MPSAFE] pci0: at device 31.3 (no driver attached) ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0: port 0x378-0x37f,0x778-0x77f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ioapic0: routing intpin 7 (ISA IRQ 7) to vector 56 sio0: irq maps: 0xc81 0xc91 0xc81 0xc81 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console ioapic0: routing intpin 4 (ISA IRQ 4) to vector 57 unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff ex_isa_identify() ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) atkbdc0: at port 0x60,0x64 on isa0 kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 psm0: current command byte:0067 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 psm0: failed to reset the aux device. bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0xc81 0xc81 0xc81 0xc81 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 vt0: not probed (disabled) isa_probe_children: probing PnP devices aue0: LUA-TX MELCO LUA-TX, rev 1.10/1.01, addr 2 miibus0: on aue0 acphy0: on miibus0 acphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto aue0: bpf attached aue0: Ethernet address: 00:40:26:--:--:-- aue0: if_start running deferred for Giant ugen0: APC APC ES 500 FW:803.p6.A USB FW:p6, rev 1.10/1.06, addr 3 Device configuration finished. Reducing kern.maxvnodes 133498 -> 100000 procfs registered lapic: Divisor 2, Frequency 66636869 hz Timecounter "TSC" frequency 1599284340 Hz quality 800 Timecounters tick every 1.000 msec lo0: bpf attached rr232x: no controller detected. hptrr: no controller detected. Waiting 5 seconds for SCSI devices to settle (noperiph:ahc0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. ahc0: Selection Timeout on A:3. 0 SCBs aborted ahc0: Selection Timeout on A:11. 0 SCBs aborted ahc0: Selection Timeout on A:1. 0 SCBs aborted ahc0: Selection Timeout on A:2. 0 SCBs aborted ahc0: Selection Timeout on A:4. 0 SCBs aborted ahc0: Selection Timeout on A:5. 0 SCBs aborted ahc0: Selection Timeout on A:6. 0 SCBs aborted ahc0: Selection Timeout on A:8. 0 SCBs aborted ahc0: Selection Timeout on A:9. 0 SCBs aborted ahc0: Selection Timeout on A:10. 0 SCBs aborted ahc0: Selection Timeout on A:12. 0 SCBs aborted ahc0: Selection Timeout on A:13. 0 SCBs aborted ahc0: Selection Timeout on A:14. 0 SCBs aborted ahc0: Selection Timeout on A:15. 0 SCBs aborted (probe0:ahc0:0:0:0): Retrying Command (ahc0:A:0:0): Sending PPR bus_width 1, period 9, offset 7f, ppr_options 2 (ahc0:A:0:0): Received PPR width 1, period 9, offset 7f,options 2 Filtered to width 1, period 9, offset 7f, options 2 ahc0: target 0 using 16bit transfers ahc0: target 0 synchronous at 80.0MHz DT, offset = 0x7f pass0 at ahc0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-3 device pass0: Serial Number E20C--- pass0: 160.000MB/s transfers (80.000MHz, offset 127, 16bit), Tagged Queueing Enabled Gda0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: Serial Number E20C---- da0: 160.000MB/s transfers (80.000MHz, offset 127, 16bit), Tagged Queueing Enabled da0: 35074MB (71833096 512 byte sectors: 255H 63S/T 4471C) EOM: new disk da0 ATA PseudoRAID loaded Trying to mount root from ufs:/dev/da0s1a start_init: trying /sbin/init Loading configuration files. Entropy harvesting: interrupts ethernet point_to_point kickstart. swapon: adding /dev/da0s1b as swap device Starting file system checks: From alan.bryan at yahoo.com Mon Jul 7 22:47:30 2008 From: alan.bryan at yahoo.com (alan bryan) Date: Mon Jul 7 22:47:39 2008 Subject: em0 no longer working after upgrading from 7.0 Release to Stable In-Reply-To: <48728913.7050105@delphij.net> Message-ID: <758546.91889.qm@web50511.mail.re2.yahoo.com> Should igb be in the GENERIC config file? > pwd /usr/src/sys/amd64/conf > cat GENERIC | grep igb > I did a "kldload if_igb" and that seemed to work and I now have a igb0 device. I get an error though on the other (unused igb1) network port: igb0: port 0x3000-0x301f mem 0xda020000-0xda03ffff,0xda000000-0xda01ffff,0xda080000-0xda083fff irq 56 at device 0.0 on pci8 igb0: Using MSIX interrupts with 3 vectors igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: Ethernet address: 00:30:48:c3:27:82 igb1: port 0x3020-0x303f mem 0xda060000-0xda07ffff,0xda040000-0xda05ffff,0xda084000-0xda087fff irq 70 at device 0.1 on pci8 igb1: Using MSIX interrupts with 3 vectors igb1: igb_allocate_receive_buffers: bus_dmamap_create failed: 12 igb1: Critical Failure setting up receive buffers device_attach: igb1 attach returned 12 igb0: link state changed to UP Thanks, Alan --- On Mon, 7/7/08, Xin LI wrote: > From: Xin LI > Subject: Re: em0 no longer working after upgrading from 7.0 Release to Stable > To: "alan bryan" > Cc: freebsd-stable@freebsd.org > Date: Monday, July 7, 2008, 2:22 PM > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, Alan, > > alan bryan wrote: > | I have a brand new Supermicro server that seems to be > having issues > with the em devices. I installed FreeBSD 7.0-Release from > CDs and > everything was working fine and then decided to cvsup to 7 > stable and > then I lost my em devices and thus networking. > Reboots/power cycling > didn't change it - no em at all since the upgrade to > 7-Stable. I stuck > in a USB to Ethernet stick (axe0) so I could get the server > online to > get this info. > | > | This is the Motherboard: > | > http://www.supermicro.com/products/motherboard/Xeon1333/5400/X7DWN+.cfm > | > | Here's some more info: > [...] > |> none2@pci0:8:0:0: class=0x020000 card=0x10a715d9 > chip=0x10a78086 > |> rev=0x02 hdr=0x00 > |> vendor = 'Intel Corporation' > |> class = network > |> subclass = ethernet > |> none3@pci0:8:0:1: class=0x020000 card=0x10a715d9 > chip=0x10a78086 > |> rev=0x02 hdr=0x00 > |> vendor = 'Intel Corporation' > |> class = network > |> subclass = ethernet > > Looks like you are using 82575EB, which is now using igb(4) > driver. Are > you running a customized kernel which does not have igb in > it? > > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (FreeBSD) > > iEYEARECAAYFAkhyiRMACgkQi+vbBBjt66CzEQCgtDetU3LVkUYxgArq6ljPpuph > JJMAnjs70h2/QCkzYqqBZseyR4ibwklG > =TRPV > -----END PGP SIGNATURE----- From delphij at delphij.net Mon Jul 7 23:18:49 2008 From: delphij at delphij.net (Xin LI) Date: Mon Jul 7 23:18:56 2008 Subject: em0 no longer working after upgrading from 7.0 Release to Stable In-Reply-To: <758546.91889.qm@web50511.mail.re2.yahoo.com> References: <758546.91889.qm@web50511.mail.re2.yahoo.com> Message-ID: <4872A1AB.6020700@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 alan bryan wrote: | Should igb be in the GENERIC config file? | |> pwd | /usr/src/sys/amd64/conf |> cat GENERIC | grep igb Ah... I really thought it is supposed to be there. Jack, I think we will want this in GENERIC kernel, do you have objections? | I did a "kldload if_igb" and that seemed to work and I now have a igb0 device. | | I get an error though on the other (unused igb1) network port: | | igb0: port 0x3000-0x301f mem 0xda020000-0xda03ffff,0xda000000-0xda01ffff,0xda080000-0xda083fff irq 56 at device 0.0 on pci8 | igb0: Using MSIX interrupts with 3 vectors | igb0: [ITHREAD] | igb0: [ITHREAD] | igb0: [ITHREAD] | igb0: Ethernet address: 00:30:48:c3:27:82 | igb1: port 0x3020-0x303f mem 0xda060000-0xda07ffff,0xda040000-0xda05ffff,0xda084000-0xda087fff irq 70 at device 0.1 on pci8 | igb1: Using MSIX interrupts with 3 vectors | igb1: igb_allocate_receive_buffers: bus_dmamap_create failed: 12 | igb1: Critical Failure setting up receive buffers | device_attach: igb1 attach returned 12 | igb0: link state changed to UP I have no idea on this. I have cc'ed Jack to see if he has some comments. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkhyoaoACgkQi+vbBBjt66AjDwCgltD3KBzi+lrAi7AtojGtkEXb TsYAnRFBy/Ujj7RlkXCPn7Lo84F7Oy9K =WHTP -----END PGP SIGNATURE----- From pyunyh at gmail.com Tue Jul 8 00:26:22 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Tue Jul 8 00:26:28 2008 Subject: em0 no longer working after upgrading from 7.0 Release to Stable In-Reply-To: <758546.91889.qm@web50511.mail.re2.yahoo.com> References: <48728913.7050105@delphij.net> <758546.91889.qm@web50511.mail.re2.yahoo.com> Message-ID: <20080708002406.GA12415@cdnetworks.co.kr> On Mon, Jul 07, 2008 at 03:47:28PM -0700, alan bryan wrote: > Should igb be in the GENERIC config file? > > > pwd > /usr/src/sys/amd64/conf > > cat GENERIC | grep igb > > > > I did a "kldload if_igb" and that seemed to work and I now have a igb0 device. > > I get an error though on the other (unused igb1) network port: > > igb0: port 0x3000-0x301f mem 0xda020000-0xda03ffff,0xda000000-0xda01ffff,0xda080000-0xda083fff irq 56 at device 0.0 on pci8 > igb0: Using MSIX interrupts with 3 vectors > igb0: [ITHREAD] > igb0: [ITHREAD] > igb0: [ITHREAD] > igb0: Ethernet address: 00:30:48:c3:27:82 > igb1: port 0x3020-0x303f mem 0xda060000-0xda07ffff,0xda040000-0xda05ffff,0xda084000-0xda087fff irq 70 at device 0.1 on pci8 > igb1: Using MSIX interrupts with 3 vectors > igb1: igb_allocate_receive_buffers: bus_dmamap_create failed: 12 > igb1: Critical Failure setting up receive buffers > device_attach: igb1 attach returned 12 Either add 'device igb' to your kernel or add the following line to /boot/loader.conf. if_igb_load="YES" > igb0: link state changed to UP > > Thanks, > Alan > -- Regards, Pyun YongHyeon From pyunyh at gmail.com Tue Jul 8 00:54:38 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Tue Jul 8 00:54:44 2008 Subject: Realtek 8102EL In-Reply-To: <86lk0ds4p9.wl%maya@negeta.com> References: <86wsjxpehl.wl%maya@negeta.com> <48729132.10307@delphij.net> <86lk0ds4p9.wl%maya@negeta.com> Message-ID: <20080708005226.GB12415@cdnetworks.co.kr> On Tue, Jul 08, 2008 at 07:35:30AM +0900, NAGATA Shinya wrote: > > Could you please try 'boot -v' and see if there is some error messages? > > 're0' is displayed. But it seems like kernel couldn't find a driver. > | re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x2000 > | pci1: at device 0.0 (no driver attached) > > > -- > NAGATA Shinya > Consoles: internal video/keyboard serial port > BIOS drive C: is disk0 > BIOS 572kB/2085068kB available memory > [...] > found-> vendor=0x10ec, dev=0x8136, revid=0x02 ^^^^^^^^^^^^^^^^^^^^^^^^^ This looks like RealTek 8101 PCIe fast ethernet controller. > bus=1, slot=0, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 3 supports D0 D1 D2 D3 current D0 > MSI supports 1 message, 64 bit > MSI-X supports 2 messages in map 0x20 > map[10]: type 4, range 32, base 00002000, size 8, enabled > pcib1: requested I/O range 0x2000-0x20ff: in range > map[18]: type 1, range 64, base 90200000, size 12, enabled > pcib1: requested memory range 0x90200000-0x90200fff: good > map[20]: type 3, range 64, base 90000000, size 16, enabled > pcib1: requested memory range 0x90000000-0x9000ffff: good > pcib1: matched entry for 1.0.INTA > pcib1: slot 0 INTA hardwired to IRQ 16 > re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x2000 > pci1: at device 0.0 (no driver attached) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This indicates re(4) probe didn't recognize the hardware. I have no idea why this can happen. Would you try 7-stable? 7-stable changed device probe/attach routine so it compares PCI device ids in probe stage intead of allocating resources as 6.x. -- Regards, Pyun YongHyeon From takahashi.tadashi at nifty.com Tue Jul 8 01:26:49 2008 From: takahashi.tadashi at nifty.com (Tadashi Takahashi) Date: Tue Jul 8 01:26:57 2008 Subject: Realtek 8102EL In-Reply-To: <20080708005226.GB12415@cdnetworks.co.kr> References: <86wsjxpehl.wl%maya@negeta.com> <48729132.10307@delphij.net> <86lk0ds4p9.wl%maya@negeta.com> <20080708005226.GB12415@cdnetworks.co.kr> Message-ID: <6.2.3.4.2.20080708100506.02775558@pop.nifty.com> I have same motherboard and I tried re patch as follows. The result is still failed. http://people.freebsd.org/~yongari/re/re.HEAD.20080624 re0: port 0x2000-0x20ff mem 0x48200000-0x48200 fff,0x48000000-0x4800ffff irq 16 at device 0.0 on pci1 re0: Chip rev. 0x24800000 re0: MAC rev. 0x00200000 re0: Unknown H/W revision: 0x24800000 device_attach: re0 attach returned 6 Thanks, Tadashi Takahashi At 09:52 08/07/08, Pyun YongHyeon wrote: >On Tue, Jul 08, 2008 at 07:35:30AM +0900, NAGATA Shinya wrote: > > > Could you please try 'boot -v' and see if there is some error messages? > > > > 're0' is displayed. But it seems like kernel couldn't find a driver. > > | re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x2000 > > | pci1: at device 0.0 (no driver attached) > > > > > > -- > > NAGATA Shinya > > > Consoles: internal video/keyboard serial port > > BIOS drive C: is disk0 > > BIOS 572kB/2085068kB available memory > > > >[...] > > > found-> vendor=0x10ec, dev=0x8136, revid=0x02 > ^^^^^^^^^^^^^^^^^^^^^^^^^ > >This looks like RealTek 8101 PCIe fast ethernet controller. > > > bus=1, slot=0, func=0 > > class=02-00-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=11 > > powerspec 3 supports D0 D1 D2 D3 current D0 > > MSI supports 1 message, 64 bit > > MSI-X supports 2 messages in map 0x20 > > map[10]: type 4, range 32, base 00002000, size 8, enabled > > pcib1: requested I/O range 0x2000-0x20ff: in range > > map[18]: type 1, range 64, base 90200000, size 12, enabled > > pcib1: requested memory range 0x90200000-0x90200fff: good > > map[20]: type 3, range 64, base 90000000, size 16, enabled > > pcib1: requested memory range 0x90000000-0x9000ffff: good > > pcib1: matched entry for 1.0.INTA > > pcib1: slot 0 INTA hardwired to IRQ 16 > > re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x2000 > > pci1: at device 0.0 (no driver attached) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >This indicates re(4) probe didn't recognize the hardware. I have no >idea why this can happen. Would you try 7-stable? 7-stable changed >device probe/attach routine so it compares PCI device ids in probe >stage intead of allocating resources as 6.x. > >-- >Regards, >Pyun YongHyeon >_______________________________________________ >freebsd-stable@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-stable >To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From pyunyh at gmail.com Tue Jul 8 01:45:32 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Tue Jul 8 01:45:39 2008 Subject: Realtek 8102EL In-Reply-To: <6.2.3.4.2.20080708100506.02775558@pop.nifty.com> References: <86wsjxpehl.wl%maya@negeta.com> <48729132.10307@delphij.net> <86lk0ds4p9.wl%maya@negeta.com> <20080708005226.GB12415@cdnetworks.co.kr> <6.2.3.4.2.20080708100506.02775558@pop.nifty.com> Message-ID: <20080708014321.GD12415@cdnetworks.co.kr> On Tue, Jul 08, 2008 at 10:14:15AM +0900, Tadashi Takahashi wrote: > I have same motherboard and I tried re patch as follows. > The result is still failed. > > http://people.freebsd.org/~yongari/re/re.HEAD.20080624 > > > re0: port 0x2000-0x20ff mem > 0x48200000-0x48200 > fff,0x48000000-0x4800ffff irq 16 at device 0.0 on pci1 > re0: Chip rev. 0x24800000 ^^^^^^^^^^ Aha, this explains why it wasn't probed in 6.x. This looks like a new revision. > re0: MAC rev. 0x00200000 > re0: Unknown H/W revision: 0x24800000 > device_attach: re0 attach returned 6 > Apply attached one and let me know how it goes. > Thanks, > Tadashi Takahashi > > > > At 09:52 08/07/08, Pyun YongHyeon wrote: > >On Tue, Jul 08, 2008 at 07:35:30AM +0900, NAGATA Shinya wrote: > > > > Could you please try 'boot -v' and see if there is some error > > messages? > > > > > > 're0' is displayed. But it seems like kernel couldn't find a driver. > > > | re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x2000 > > > | pci1: at device 0.0 (no driver attached) > > > > > > > > > -- > > > NAGATA Shinya > > > > > Consoles: internal video/keyboard serial port > > > BIOS drive C: is disk0 > > > BIOS 572kB/2085068kB available memory > > > > > > >[...] > > > > > found-> vendor=0x10ec, dev=0x8136, revid=0x02 > > ^^^^^^^^^^^^^^^^^^^^^^^^^ > > > >This looks like RealTek 8101 PCIe fast ethernet controller. > > > > > bus=1, slot=0, func=0 > > > class=02-00-00, hdrtype=0x00, mfdev=0 > > > cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) > > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > > intpin=a, irq=11 > > > powerspec 3 supports D0 D1 D2 D3 current D0 > > > MSI supports 1 message, 64 bit > > > MSI-X supports 2 messages in map 0x20 > > > map[10]: type 4, range 32, base 00002000, size 8, enabled > > > pcib1: requested I/O range 0x2000-0x20ff: in range > > > map[18]: type 1, range 64, base 90200000, size 12, enabled > > > pcib1: requested memory range 0x90200000-0x90200fff: good > > > map[20]: type 3, range 64, base 90000000, size 16, enabled > > > pcib1: requested memory range 0x90000000-0x9000ffff: good > > > pcib1: matched entry for 1.0.INTA > > > pcib1: slot 0 INTA hardwired to IRQ 16 > > > re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x2000 > > > pci1: at device 0.0 (no driver attached) > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > >This indicates re(4) probe didn't recognize the hardware. I have no > >idea why this can happen. Would you try 7-stable? 7-stable changed > >device probe/attach routine so it compares PCI device ids in probe > >stage intead of allocating resources as 6.x. > > > >-- > >Regards, > >Pyun YongHyeon > >_______________________________________________ > >freebsd-stable@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Regards, Pyun YongHyeon -------------- next part -------------- --- sys/dev/re/if_re.c.orig 2008-07-02 17:00:14.000000000 +0900 +++ sys/dev/re/if_re.c 2008-07-08 10:38:14.000000000 +0900 @@ -206,6 +206,7 @@ { RL_HWREV_8101, RL_8139, "8101"}, { RL_HWREV_8100E, RL_8169, "8100E"}, { RL_HWREV_8101E, RL_8169, "8101E"}, + { RL_HWREV_8101E_SPIN2, RL_8169, "8101E"}, { RL_HWREV_8168_SPIN2, RL_8169, "8168"}, { RL_HWREV_8168_SPIN3, RL_8169, "8168"}, { RL_HWREV_8168C, RL_8169, "8168C/8111C"}, --- sys/pci/if_rlreg.h.orig 2008-03-31 13:03:14.000000000 +0900 +++ sys/pci/if_rlreg.h 2008-07-08 10:40:48.000000000 +0900 @@ -156,6 +156,7 @@ #define RL_HWREV_8169S 0x04000000 #define RL_HWREV_8169_8110SB 0x10000000 #define RL_HWREV_8169_8110SC 0x18000000 +#define RL_HWREV_8101E_SPIN2 0x24800000 #define RL_HWREV_8168_SPIN1 0x30000000 #define RL_HWREV_8100E 0x30800000 #define RL_HWREV_8101E 0x34000000 From jfvogel at gmail.com Tue Jul 8 02:17:26 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Tue Jul 8 02:17:33 2008 Subject: em0 no longer working after upgrading from 7.0 Release to Stable In-Reply-To: <4872A1AB.6020700@delphij.net> References: <758546.91889.qm@web50511.mail.re2.yahoo.com> <4872A1AB.6020700@delphij.net> Message-ID: <2a41acea0807071917i7b11a606r194771eaedf02f80@mail.gmail.com> Yes, I guess the time has arrived to add igb into GENERIC, I would add into your kernel config now, I will add into the tree at my next opportunity. As for that failure on igb1, try building in the kernel and see if that still happens, that one I have not seen. Cheers, Jack On Mon, Jul 7, 2008 at 4:07 PM, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > alan bryan wrote: > | Should igb be in the GENERIC config file? > | > |> pwd > | /usr/src/sys/amd64/conf > |> cat GENERIC | grep igb > > Ah... I really thought it is supposed to be there. Jack, I think we > will want this in GENERIC kernel, do you have objections? > > | I did a "kldload if_igb" and that seemed to work and I now have a igb0 > device. > | > | I get an error though on the other (unused igb1) network port: > | > | igb0: port > 0x3000-0x301f mem > 0xda020000-0xda03ffff,0xda000000-0xda01ffff,0xda080000-0xda083fff irq 56 > at device 0.0 on pci8 > | igb0: Using MSIX interrupts with 3 vectors > | igb0: [ITHREAD] > | igb0: [ITHREAD] > | igb0: [ITHREAD] > | igb0: Ethernet address: 00:30:48:c3:27:82 > | igb1: port > 0x3020-0x303f mem > 0xda060000-0xda07ffff,0xda040000-0xda05ffff,0xda084000-0xda087fff irq 70 > at device 0.1 on pci8 > | igb1: Using MSIX interrupts with 3 vectors > | igb1: igb_allocate_receive_buffers: bus_dmamap_create failed: 12 > | igb1: Critical Failure setting up receive buffers > | device_attach: igb1 attach returned 12 > | igb0: link state changed to UP > > I have no idea on this. I have cc'ed Jack to see if he has some comments. > > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (FreeBSD) > > iEYEARECAAYFAkhyoaoACgkQi+vbBBjt66AjDwCgltD3KBzi+lrAi7AtojGtkEXb > TsYAnRFBy/Ujj7RlkXCPn7Lo84F7Oy9K > =WHTP > -----END PGP SIGNATURE----- > From pyunyh at gmail.com Tue Jul 8 06:26:55 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Tue Jul 8 06:27:03 2008 Subject: Marvell Yukon 88E8062 - media selection problem In-Reply-To: <487263EF.6070003@hot.pl> References: <20080701004855.GF83626@cdnetworks.co.kr> <486A07A4.1070406@hot.pl> <20080702010929.GA87933@cdnetworks.co.kr> <486C0E69.8020603@hot.pl> <20080703015948.GB92015@cdnetworks.co.kr> <486CBA1D.6000602@hot.pl> <20080705011612.GC671@cdnetworks.co.kr> <48712EE8.1000701@hot.pl> <20080707102433.GE8171@cdnetworks.co.kr> <487263EF.6070003@hot.pl> Message-ID: <20080708062443.GE12415@cdnetworks.co.kr> On Mon, Jul 07, 2008 at 08:43:59PM +0200, Krzysztof J??druczyk wrote: > Pyun YongHyeon wrote: > >Since the patch had lots of code not related with 88E8062 dual port > >controller, would you try attached patch again? I think the attached > >patch is minimal one that makes 88E8062 work. > > > >The patch also try to enable MSI for dual port controllers. At the > >time of writing support for MSI I had no testers to experiment MSI so > >MSI on dual port controllers were ignored. Please see if msk(4) take > >advantage of MSI. irq256 or higher number would be showed in "vmstat > >-i" output if MSI is active. > > > # vmstat -i > interrupt total rate > irq14: ata0 1450 1 > irq16: fxp0 uhci0 2058 1 > cpu0: timer 2705189 1999 > irq256: mskc0 92 0 > cpu1: timer 2704883 1999 > Total 5413672 4001 > > I guess MSI is enabled. > That's great! > As of the results of tests I'm not sure what to start with... Initially > both interfaces seemed non-functional with nothing getting transmitted > to other machine. Then I noticed that it seems that msk1 seemed to > receive packets that should be on msk0 (?): > > ># tcpdump -i msk1 > >tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > >listening on msk1, link-type EN10MB (Ethernet), capture size 96 bytes > >20:28:41.757722 arp who-has 192.168.0.1 tell 192.168.0.2 > > 192.168.0.2 is on em0 on other machine, and should be on the same switch > as msk0. At least this was the case on previous tests in which both > interfaces worked... > > Another time on the same test corrupted data was received: > > >tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > >listening on msk1, link-type EN10MB (Ethernet), capture size 96 bytes > >20:31:29.806041 d3:04:ff:ff:ff:ff (oui Unknown) > 22:a0:00:00:02:f0 (oui > >Unknown), ethertype Unknown (0x3cc0), length 60: > > 0x0000: de07 0000 0000 0000 0000 0000 0000 0000 ................ > > 0x0010: 0000 ffff ffff ffff 0002 0406 0800 0806 ................ > > 0x0020: 0001 0800 0604 0001 0002 0406 0800 .............. > > And later magically the msk1 <-> em0 link started working... Seems to > work just fine after reboot (I didn't try to power down machine, just > shutdown -r). > > So to sum up - in the end mks1 interface worked in some weird way - but > it seemed to represent the link that was under msk0 previously. It may still have some odd cases for dual port controllers. I guess the reset sequence of the controller is important as status LEs are shared between ports. The patch you tried in previous patch( msk.88E8040.patch5) has a couple of fixes which might also help to stability under certain conditions. Orignally msk.88E8040.patch5 was generated for 88E8040 fast ethernet controller but it miserably failed to support the controller so I had to think harder to make it work. :-( Anyway I'll commit the minimal patch in a couple of days as it seems that it wouldn't affect other Yukon II controllers. Thanks a lot for your time and testing! -- Regards, Pyun YongHyeon From bu7cher at yandex.ru Tue Jul 8 06:42:55 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Tue Jul 8 06:43:02 2008 Subject: Realtek 8102EL In-Reply-To: <20080708014321.GD12415@cdnetworks.co.kr> References: <86wsjxpehl.wl%maya@negeta.com> <48729132.10307@delphij.net> <86lk0ds4p9.wl%maya@negeta.com> <20080708005226.GB12415@cdnetworks.co.kr> <6.2.3.4.2.20080708100506.02775558@pop.nifty.com> <20080708014321.GD12415@cdnetworks.co.kr> Message-ID: <48730C49.1010401@yandex.ru> Pyun YongHyeon wrote: > > re0: port 0x2000-0x20ff mem > > 0x48200000-0x48200 > > fff,0x48000000-0x4800ffff irq 16 at device 0.0 on pci1 > > re0: Chip rev. 0x24800000 > ^^^^^^^^^^ Hi, Pyun Did you look to the last vendors driver? It seems it has different probe code and supports newest cards. ftp://66.104.77.130/cn/nic/rtl_bsd_drv_v175.tgz -- WBR, Andrey V. Elsukov From pyunyh at gmail.com Tue Jul 8 07:12:35 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Tue Jul 8 07:12:41 2008 Subject: Realtek 8102EL In-Reply-To: <48730C49.1010401@yandex.ru> References: <86wsjxpehl.wl%maya@negeta.com> <48729132.10307@delphij.net> <86lk0ds4p9.wl%maya@negeta.com> <20080708005226.GB12415@cdnetworks.co.kr> <6.2.3.4.2.20080708100506.02775558@pop.nifty.com> <20080708014321.GD12415@cdnetworks.co.kr> <48730C49.1010401@yandex.ru> Message-ID: <20080708071022.GF12415@cdnetworks.co.kr> On Tue, Jul 08, 2008 at 10:42:17AM +0400, Andrey V. Elsukov wrote: > Pyun YongHyeon wrote: > > > re0: port 0x2000-0x20ff mem > > > 0x48200000-0x48200 > > > fff,0x48000000-0x4800ffff irq 16 at device 0.0 on pci1 > > > re0: Chip rev. 0x24800000 > > ^^^^^^^^^^ > > Hi, Pyun > > Did you look to the last vendors driver? It seems it has > different probe code and supports newest cards. > > ftp://66.104.77.130/cn/nic/rtl_bsd_drv_v175.tgz > I already seen this vendor driver. Both rl(4) and re(4) in RELENG_7 use standard PCI probe code. However re(4) has a additional check to verify the existence of supported chip revision. If we want to support hardware assitance such as TSO, checksum offload, re(4) should know exact chip revision as each revision requires different workaround for its silicon bug. The vedor driver for FreeBSD ignores all hardware assistance and it works like dumb controller. Also the vendor driver has a lot of DSP fixups and magic programming sequence which are really hard to understand what/why they do that. I'd like to say to check Linux driver released by the vendor which takes full advantage of hardware assistance. I tried to contact the vendor to get programming information for newer controllers but they rejected to answer my specific questions. :-( > -- > WBR, Andrey V. Elsukov -- Regards, Pyun YongHyeon From beaker at hot.pl Tue Jul 8 09:47:55 2008 From: beaker at hot.pl (=?UTF-8?B?S3J6eXN6dG9mIErEmWRydWN6eWs=?=) Date: Tue Jul 8 09:48:03 2008 Subject: Marvell Yukon 88E8062 - media selection problem In-Reply-To: <20080708062443.GE12415@cdnetworks.co.kr> References: <20080701004855.GF83626@cdnetworks.co.kr> <486A07A4.1070406@hot.pl> <20080702010929.GA87933@cdnetworks.co.kr> <486C0E69.8020603@hot.pl> <20080703015948.GB92015@cdnetworks.co.kr> <486CBA1D.6000602@hot.pl> <20080705011612.GC671@cdnetworks.co.kr> <48712EE8.1000701@hot.pl> <20080707102433.GE8171@cdnetworks.co.kr> <487263EF.6070003@hot.pl> <20080708062443.GE12415@cdnetworks.co.kr> Message-ID: <487337C7.7030705@hot.pl> Pyun YongHyeon wrote: > It may still have some odd cases for dual port controllers. I guess > the reset sequence of the controller is important as status LEs are > shared between ports. The patch you tried in previous patch( > msk.88E8040.patch5) has a couple of fixes which might also help to > stability under certain conditions. Orignally msk.88E8040.patch5 > was generated for 88E8040 fast ethernet controller but it miserably > failed to support the controller so I had to think harder to make > it work. :-( > > Anyway I'll commit the minimal patch in a couple of days as it > seems that it wouldn't affect other Yukon II controllers. Ok. I'm not sure I've been clear though: with the smaller patch only one interface worked (but it was msk1 for whatever reason this time). So my question would be: once this patch gets in the tree, would it possible to for me to apply some parts of msk.88E8040.patch5 parts to get both interfaces running? I need to put the only two msk-boxes I currently have in kind of production stage. Currently for testing, but it will be harder for me to test fixes. As of today, I'll set them up with 7-STABLE + msk.88E040.patch5 since this setup was only one that seemed fully functional. Testing will still be possible, since I could schedule some maintenance work on one of the boxes during evenings (luckily only one of affected machines will have to run 24/7). In my current testing I just rebuilt kernel/rebooted with every test which is a bit annoying. I'm certain it would be possible to build affected parts as modules and rebuild->kldunload->kldload only those. Am I right? If it is indeed possible I'd appreciate some instructions on how to do that properly. -- Best regards, Krzysztof J?druczyk From maya at negeta.com Tue Jul 8 09:52:25 2008 From: maya at negeta.com (NAGATA Shinya) Date: Tue Jul 8 09:52:33 2008 Subject: Realtek 8102EL In-Reply-To: <20080708014321.GD12415@cdnetworks.co.kr> References: <86wsjxpehl.wl%maya@negeta.com> <48729132.10307@delphij.net> <86lk0ds4p9.wl%maya@negeta.com> <20080708005226.GB12415@cdnetworks.co.kr> <6.2.3.4.2.20080708100506.02775558@pop.nifty.com> <20080708014321.GD12415@cdnetworks.co.kr> Message-ID: <86hcb0r9d7.wl%maya@negeta.com> > > re0: MAC rev. 0x00200000 > > re0: Unknown H/W revision: 0x24800000 > > device_attach: re0 attach returned 6 > > > > Apply attached one and let me know how it goes. Thank you for your patch. It doesn't work on 6.3-p2. > pci1: on pcib1 > pci1: at device 0.0 (no driver attached) It can find this chip on RELENG_7, and can up as re0. But ping does not reach to other host / from other host. > pci1: on pcib1 > re0: port 0x2000-0x20ff mem 0x90200000-0x90200fff,0x90000000-0x9000ffff irq 16 at device 0.0 on pci1 > miibus0: on re0 > rlphy0: PHY 1 on miibus0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > re0: Ethernet address: 00:1c:c0:47:32:5d > re0: [FILTER] In addition, intel says this chip is 8102, and the print on IC too. http://www.intel.com/support/motherboards/desktop/D945GCLF/sb/CS-029163.htm -- NAGATA Shinya From pyunyh at gmail.com Tue Jul 8 11:46:58 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Tue Jul 8 11:47:05 2008 Subject: Realtek 8102EL In-Reply-To: <86hcb0r9d7.wl%maya@negeta.com> References: <86wsjxpehl.wl%maya@negeta.com> <48729132.10307@delphij.net> <86lk0ds4p9.wl%maya@negeta.com> <20080708005226.GB12415@cdnetworks.co.kr> <6.2.3.4.2.20080708100506.02775558@pop.nifty.com> <20080708014321.GD12415@cdnetworks.co.kr> <86hcb0r9d7.wl%maya@negeta.com> Message-ID: <20080708114446.GH12415@cdnetworks.co.kr> On Tue, Jul 08, 2008 at 06:52:20PM +0900, NAGATA Shinya wrote: > > > re0: MAC rev. 0x00200000 > > > re0: Unknown H/W revision: 0x24800000 > > > device_attach: re0 attach returned 6 > > > > > > > Apply attached one and let me know how it goes. > > Thank you for your patch. > > It doesn't work on 6.3-p2. :-( > > pci1: on pcib1 > > pci1: at device 0.0 (no driver attached) > > It can find this chip on RELENG_7, and can up as re0. > But ping does not reach to other host / from other host. > > pci1: on pcib1 > > re0: port 0x2000-0x20ff mem 0x90200000-0x90200fff,0x90000000-0x9000ffff irq 16 at device 0.0 on pci1 > > miibus0: on re0 > > rlphy0: PHY 1 on miibus0 > > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > re0: Ethernet address: 00:1c:c0:47:32:5d > > re0: [FILTER] > Thanks! This is good information. It seems that newer 810x PCIe controllers seems to use different descriptor format such that checksum offload didn't work on these controllers. Backout previous patch and try attached patch. > > In addition, intel says this chip is 8102, and the print on IC too. > http://www.intel.com/support/motherboards/desktop/D945GCLF/sb/CS-029163.htm > Yeah, I've corrected controller name and added a new one too. -- Regards, Pyun YongHyeon -------------- next part -------------- --- sys/dev/re/if_re.c.orig 2008-07-08 20:35:11.000000000 +0900 +++ sys/dev/re/if_re.c 2008-07-08 20:36:04.000000000 +0900 @@ -170,7 +170,7 @@ { RT_VENDORID, RT_DEVICEID_8139, 0, "RealTek 8139C+ 10/100BaseTX" }, { RT_VENDORID, RT_DEVICEID_8101E, 0, - "RealTek 8101E PCIe 10/100baseTX" }, + "RealTek 8101/8102/8102E(L) PCIe 10/100baseTX" }, { RT_VENDORID, RT_DEVICEID_8168, 0, "RealTek 8168/8168B/8168C/8168CP/8111B/8111C/8111CP PCIe " "Gigabit Ethernet" }, @@ -206,6 +206,8 @@ { RL_HWREV_8101, RL_8139, "8101"}, { RL_HWREV_8100E, RL_8169, "8100E"}, { RL_HWREV_8101E, RL_8169, "8101E"}, + { RL_HWREV_8102E, RL_8169, "8102E"}, + { RL_HWREV_8102EL, RL_8169, "8102EL"}, { RL_HWREV_8168_SPIN2, RL_8169, "8168"}, { RL_HWREV_8168_SPIN3, RL_8169, "8168"}, { RL_HWREV_8168C, RL_8169, "8168C/8111C"}, @@ -1271,7 +1273,13 @@ break; case RL_HWREV_8100E: case RL_HWREV_8101E: - sc->rl_flags |= RL_FLAG_INVMAR | RL_FLAG_PHYWAKE; + sc->rl_flags |= RL_FLAG_NOJUMBO | RL_FLAG_INVMAR | + RL_FLAG_PHYWAKE; + break; + case RL_HWREV_8102E: + case RL_HWREV_8102EL: + sc->rl_flags |= RL_FLAG_NOJUMBO | RL_FLAG_INVMAR | + RL_FLAG_PHYWAKE | RL_FLAG_DESCV2 | RL_FLAG_MACSTAT; break; case RL_HWREV_8168_SPIN1: case RL_HWREV_8168_SPIN2: --- sys/pci/if_rlreg.h.orig 2008-07-08 20:32:14.000000000 +0900 +++ sys/pci/if_rlreg.h 2008-07-08 20:37:56.000000000 +0900 @@ -156,9 +156,11 @@ #define RL_HWREV_8169S 0x04000000 #define RL_HWREV_8169_8110SB 0x10000000 #define RL_HWREV_8169_8110SC 0x18000000 +#define RL_HWREV_8102EL 0x24800000 #define RL_HWREV_8168_SPIN1 0x30000000 #define RL_HWREV_8100E 0x30800000 #define RL_HWREV_8101E 0x34000000 +#define RL_HWREV_8102E 0x34800000 #define RL_HWREV_8168_SPIN2 0x38000000 #define RL_HWREV_8168_SPIN3 0x38400000 #define RL_HWREV_8168C 0x3C000000 From pyunyh at gmail.com Tue Jul 8 12:02:10 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Tue Jul 8 12:02:18 2008 Subject: Realtek 8102EL In-Reply-To: <20080708114446.GH12415@cdnetworks.co.kr> References: <86wsjxpehl.wl%maya@negeta.com> <48729132.10307@delphij.net> <86lk0ds4p9.wl%maya@negeta.com> <20080708005226.GB12415@cdnetworks.co.kr> <6.2.3.4.2.20080708100506.02775558@pop.nifty.com> <20080708014321.GD12415@cdnetworks.co.kr> <86hcb0r9d7.wl%maya@negeta.com> <20080708114446.GH12415@cdnetworks.co.kr> Message-ID: <20080708115958.GI12415@cdnetworks.co.kr> On Tue, Jul 08, 2008 at 08:44:46PM +0900, To NAGATA Shinya wrote: > On Tue, Jul 08, 2008 at 06:52:20PM +0900, NAGATA Shinya wrote: > > > > re0: MAC rev. 0x00200000 > > > > re0: Unknown H/W revision: 0x24800000 > > > > device_attach: re0 attach returned 6 > > > > > > > > > > Apply attached one and let me know how it goes. > > > > Thank you for your patch. > > > > It doesn't work on 6.3-p2. > > :-( > > > > pci1: on pcib1 > > > pci1: at device 0.0 (no driver attached) > > > > It can find this chip on RELENG_7, and can up as re0. > > But ping does not reach to other host / from other host. > > > pci1: on pcib1 > > > re0: port 0x2000-0x20ff mem 0x90200000-0x90200fff,0x90000000-0x9000ffff irq 16 at device 0.0 on pci1 > > > miibus0: on re0 > > > rlphy0: PHY 1 on miibus0 > > > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > > re0: Ethernet address: 00:1c:c0:47:32:5d > > > re0: [FILTER] > > > > Thanks! This is good information. It seems that newer 810x PCIe > controllers seems to use different descriptor format such that > checksum offload didn't work on these controllers. > Backout previous patch and try attached patch. Forgot to say that the patch was generated against HEAD. Copy if_re.c and if_rlreg.h from HEAD to RELENG_7 and apply the patch. -- Regards, Pyun YongHyeon From imb at protected-networks.net Tue Jul 8 12:55:40 2008 From: imb at protected-networks.net (Michael Butler) Date: Tue Jul 8 12:55:49 2008 Subject: bridge breakage? Message-ID: <487363C1.1040700@protected-networks.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The recent change to the bridge interface causes the 7-stable kernel to complain. In this case tap0 is the only member of the bridge: Jul 8 08:36:30 aaron kernel: tap0: promiscuous mode enabled Jul 8 08:36:37 aaron kernel: rtfree: 0xc3ed04b0 has 2 refs Jul 8 08:36:39 aaron last message repeated 2 times Jul 8 08:37:52 aaron kernel: rtfree: 0xc3ed04b0 has 2 refs Jul 8 08:37:53 aaron kernel: rtfree: 0xc3ed04b0 has 2 refs Jul 8 08:37:54 aaron kernel: rtfree: 0xc3ed04b0 has 2 refs Jul 8 08:39:03 aaron kernel: rtfree: 0xc3ed04b0 has 2 refs Jul 8 08:39:47 aaron last message repeated 9 times Jul 8 08:40:05 aaron last message repeated 8 times Jul 8 08:40:12 aaron kernel: rtfree: 0xc3ed04b0 has 2 refs Jul 8 08:40:14 aaron last message repeated 2 times Jul 8 08:40:20 aaron kernel: rtfree: 0xc3ed04b0 has 2 refs Jul 8 08:40:21 aaron kernel: rtfree: 0xc3ed04b0 has 2 refs Jul 8 08:40:22 aaron kernel: rtfree: 0xc3ed04b0 has 2 refs Jul 8 08:40:53 aaron last message repeated 7 times Jul 8 08:42:46 aaron last message repeated 14 times Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkhzY8AACgkQQv9rrgRC1JKvFwCgn4ZHyk+PVuWrFez2Sdh4TC0S ZD8AoL5rDOvBds/Yi777yYy3UoLd5nIX =955V -----END PGP SIGNATURE----- From kjblack at gmail.com Tue Jul 8 13:54:31 2008 From: kjblack at gmail.com (Kelly Black) Date: Tue Jul 8 13:54:39 2008 Subject: RELENG_7: /boot/loader command prompt mode broken? Message-ID: <1b1b33f10807080654s785f0f8aj487730337026a9e6@mail.gmail.com> >Message: 4 >Date: Mon, 07 Jul 2008 14:10:45 -0700 >From: "Kevin Oberman" >Subject: Re: RELENG_7: /boot/loader command prompt mode broken? >To: Eugene Grosbein >Cc: stable@freebsd.org >Message-ID: <20080707211045.90F274500E@ptavv.es.net> >Content-Type: text/plain; charset="us-ascii" > >> Date: Mon, 7 Jul 2008 18:21:47 +0800 >> From: Eugene Grosbein >> Sender: owner-freebsd-stable@freebsd.org >> >> Hi! >> >> Today I've updated my 7.0-STABLE system using source upgrade path. >> loader(8) boots it just fine but it's impossible to issue commands >> using its command prompt mode (N.B.: beastie_disable="YES" >> and autoboot_delay="2" are in my /boot/loader.conf). >> >> At boot time, I hit "Space" button to reach its command prompt - that works. >> While typing of a command, I observe one of bad things: >> >> 1) it just hangs solid (keyboard LEDs do not switch) after a couple >> of characters entered, or >> 2) system spontaneously reboots while typing, or >> 3) it shows endless flow of hex dump, presumably from BTX. >> >> Most of time it hangs, a couple of times I've got reboot >> and once there was hex dump. I use vidconsole with PS/2 keyboard. >> >> Seldom I've allowed to type 'boot -s' and hit enter without a problem - >> it boots system OK then. So, I assume there is a problem >> with vidconsole input/output routines. >> [Snip ... ] >> I am having a similar problem. I removed the config.boot file with no change. Someone in this list posted the following links: > documented here; and yes, I realise you don't get a screen full of > continual register dumps, but different people saw different behaviour: > > http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues > > Also see these mailing list threads: > > http://lists.freebsd.org/pipermail/freebsd-current/2007-October/078755.html > http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/038214.html > Unfortunately I have not had a chance to test them yet. (It is hard to bring a machine down while it is running.) Sincerely, Kel -- _______________________________________________________ Kelly Black Phone: (518) 388-8727 Department of Mathematics FAX: (603) 388-6005 Union College e-mail: kelly.black@union.edu Schenectady NY 12308 (USA) WWW: http://blackk.union.edu/~black From maya at negeta.com Tue Jul 8 14:10:00 2008 From: maya at negeta.com (NAGATA Shinya) Date: Tue Jul 8 14:10:07 2008 Subject: Realtek 8102EL In-Reply-To: <20080708114446.GH12415@cdnetworks.co.kr> References: <86wsjxpehl.wl%maya@negeta.com> <48729132.10307@delphij.net> <86lk0ds4p9.wl%maya@negeta.com> <20080708005226.GB12415@cdnetworks.co.kr> <6.2.3.4.2.20080708100506.02775558@pop.nifty.com> <20080708014321.GD12415@cdnetworks.co.kr> <86hcb0r9d7.wl%maya@negeta.com> <20080708114446.GH12415@cdnetworks.co.kr> Message-ID: <86bq18a2mh.wl%maya@negeta.com> > Thanks! This is good information. It seems that newer 810x PCIe > controllers seems to use different descriptor format such that > checksum offload didn't work on these controllers. > Backout previous patch and try attached patch. I can connect via SSH. It seems work fine. Thank you! -- NAGATA Shinya From alan.bryan at yahoo.com Tue Jul 8 18:42:06 2008 From: alan.bryan at yahoo.com (alan bryan) Date: Tue Jul 8 18:42:15 2008 Subject: em0 no longer working after upgrading from 7.0 Release to Stable In-Reply-To: <2a41acea0807071917i7b11a606r194771eaedf02f80@mail.gmail.com> Message-ID: <814664.79857.qm@web50507.mail.re2.yahoo.com> --- On Mon, 7/7/08, Jack Vogel wrote: > As for that failure on igb1, try building in the kernel and > see if that still happens, that one I have not seen. I rebuilt the kernel and there is now no igb1 failure. So, that only happened when loading the module after bootup. I'll also add that I am using ZFS on this machine in case that has any influence to what's going on. Thanks everyone, Alan From pschmehl_lists at tx.rr.com Tue Jul 8 18:56:30 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Tue Jul 8 18:56:51 2008 Subject: UMASS problem on 7.0 STABLE Message-ID: Ever since I upgraded this workstation to 7.0 STABLE, I have been unable to reboot with my USB hard drive attached. During the boot sequence, the device is properly detected and identified, but then I get an error message, a crash dump and a reboot. I enabled /var/log/console.log in the hope that I would catch the error message, but it doesn't appear in the log. I also don't have any kernel dumps, so I can't trace those to see what the problem might be. An additional problem that I have is that, during boot, the system says there is no dump device available. This is despite the fact that swap is twice the real memory size and /etc/defaults/rc.conf defines dumpdev as auto. I even tried defining dumpdev as the swap partition (in /etc/rc.conf), but nothing changed. I have to be doing something wrong, but I'm at a loss to know what it is. I've rebuilt world and kernel nine times now, in the desparate hope that something might have changed in the usb code that would solve this problem. (Every time "#find /usr/src -newer /boot/kernel" returns changes in the usb code, I rebuild kernel and world.) Is there something I can enable that will capture the boot sequence during a failed boot while devices are still being detected? # grep -i umass /var/log/console.log Any helpful hints would be gratefully appreciated. # uname -a FreeBSD utd65257.utdallas.edu 7.0-STABLE FreeBSD 7.0-STABLE #8: Mon Jul 7 10:41:03 CDT 2008 root@utd65257.utdallas.edu:/usr/obj/usr/src/sys/GENERIC i386 # sysctl -a | grep hw.physmem hw.physmem: 3474407424 # dmesg | grep -i umass umass0: on uhub5 da0 at umass-sim0 bus 0 target 0 lun 0 # grep swap /etc/fstab /dev/ad8s1b none swap sw 0 0 # swapctl -l Device: 1024-blocks Used: /dev/ad8s1b 8388608 0 # grep -i usb /var/run/dmesg.boot uhci0: port 0xff20-0xff3f irq 16 at device 26.0 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhci1: port 0xff00-0xff1f irq 17 at device 26.1 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 ehci0: mem 0xfebd9c00-0xfebd9fff irq 22 at device 26.7 on pci0 usb2: waiting for BIOS to give up control usb2: EHCI version 1.0 usb2: wrong number of companions (3 != 2) usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 ums0: on uhub3 uhci2: port 0xff80-0xff9f irq 23 at device 29.0 on pci0 usb3: on uhci2 usb3: USB revision 1.0 uhub4: on usb3 uhci3: port 0xff60-0xff7f irq 17 at device 29.1 on pci0 usb4: on uhci3 usb4: USB revision 1.0 uhub5: on usb4 uhci4: port 0xff40-0xff5f irq 18 at device 29.2 on pci0 usb5: on uhci4 usb5: USB revision 1.0 uhub6: on usb5 ehci1: mem 0xff980800-0xff980bff irq 23 at device 29.7 on pci0 usb6: waiting for BIOS to give up control usb6: timed out waiting for BIOS usb6: EHCI version 1.0 usb6: companion controllers, 2 ports each: usb3 usb4 usb5 usb6: on ehci1 usb6: USB revision 2.0 uhub7: on usb6 -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. From alanbryan1234 at yahoo.com Tue Jul 8 19:18:07 2008 From: alanbryan1234 at yahoo.com (alan bryan) Date: Tue Jul 8 19:18:14 2008 Subject: em0 no longer working after upgrading from 7.0 Release to Stable In-Reply-To: <814664.79857.qm@web50507.mail.re2.yahoo.com> Message-ID: <521756.8254.qm@web50511.mail.re2.yahoo.com> --- On Tue, 7/8/08, alan bryan wrote: > I rebuilt the kernel and there is now no igb1 failure. So, > that only happened when loading the module after bootup. > > I'll also add that I am using ZFS on this machine in > case that has any influence to what's going on. Well, maybe I celebrated too soon. After recompiling the kernel with "device igb" it shows no errors in the dmesg and I did ifconfig and igb0 and igb1 both showed up. But, it wasn't actually usable. I tried to ping the gateway and got this on the console: vm_thread_new: kstack allocation failed No more processes. and the pings were unsuccessful. I tried doing ifconfig igb0 down and then up again and same thing. Ideas? Thanks, Alan From matheus at eternamente.info Wed Jul 9 01:01:51 2008 From: matheus at eternamente.info (matheus@eternamente.info) Date: Wed Jul 9 01:01:59 2008 Subject: disk questions: geom and zfs Message-ID: <2c7aa7cb6f8acbc18993b802bb3a5016.squirrel@cygnus> hail, I have a 7-stable: [matheus@xxx /usr/home/matheus]$ uname -a FreeBSD xxx 7.0-STABLE FreeBSD 7.0-STABLE #2: Sun Jul 6 15:03:26 BRT 2008 root@lamneth:/usr/obj/usr/src/sys/xxx_7 i386 and there exists three geom things. gconcat status Name Status Components concat/concat0 UP ad4 ad5 gmirror status Name Status Components mirror/mirror0 COMPLETE ad8s1 ad10s1 gstripe status Name Status Components stripe/stripe0 UP ad8s2 ad10s2 and a small (100GB) zfs pool. the thing is, if I take all these disks to a 6.3R-p2 system, will I get in trouble ? what if this 6.3R becomes 7-stable also, will this trouble disappear ? the 7-stable is now a old epox motherboard with highpoint ide raid (used as normal ide) and two sata ports, the 6.3R is a pentium II two port regular ide motherboard, I'll add a 4 port sata pci card. lets forget about the zfs need for memory (noew runs fine since sunday with 512MB), just the disk order change (ad4 probably won be ad4 anymore). thanks, matheus From pyunyh at gmail.com Wed Jul 9 02:01:30 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Jul 9 02:01:38 2008 Subject: Realtek 8102EL In-Reply-To: <86bq18a2mh.wl%maya@negeta.com> References: <86wsjxpehl.wl%maya@negeta.com> <48729132.10307@delphij.net> <86lk0ds4p9.wl%maya@negeta.com> <20080708005226.GB12415@cdnetworks.co.kr> <6.2.3.4.2.20080708100506.02775558@pop.nifty.com> <20080708014321.GD12415@cdnetworks.co.kr> <86hcb0r9d7.wl%maya@negeta.com> <20080708114446.GH12415@cdnetworks.co.kr> <86bq18a2mh.wl%maya@negeta.com> Message-ID: <20080709015918.GC16513@cdnetworks.co.kr> On Tue, Jul 08, 2008 at 11:09:58PM +0900, NAGATA Shinya wrote: > > Thanks! This is good information. It seems that newer 810x PCIe > > controllers seems to use different descriptor format such that > > checksum offload didn't work on these controllers. > > Backout previous patch and try attached patch. > > I can connect via SSH. It seems work fine. Thank you! > Committed with svn r180377. Thanks a lot for testing! > > -- > NAGATA Shinya -- Regards, Pyun YongHyeon From ronald-freebsd8 at klop.yi.org Wed Jul 9 09:50:31 2008 From: ronald-freebsd8 at klop.yi.org (Ronald Klop) Date: Wed Jul 9 09:50:45 2008 Subject: UMASS problem on 7.0 STABLE In-Reply-To: References: Message-ID: On Tue, 08 Jul 2008 20:27:26 +0200, Paul Schmehl wrote: > Ever since I upgraded this workstation to 7.0 STABLE, I have been unable > to reboot with my USB hard drive attached. During the boot sequence, > the device is properly detected and identified, but then I get an error > message, a crash dump and a reboot. I enabled /var/log/console.log in > the hope that I would catch the error message, but it doesn't appear in > the log. I also don't have any kernel dumps, so I can't trace those to > see what the problem might be. > > An additional problem that I have is that, during boot, the system says > there is no dump device available. This is despite the fact that swap > is twice the real memory size and /etc/defaults/rc.conf defines dumpdev > as auto. I even tried defining dumpdev as the swap partition (in > /etc/rc.conf), but nothing changed. > > I have to be doing something wrong, but I'm at a loss to know what it > is. I've rebuilt world and kernel nine times now, in the desparate hope > that something might have changed in the usb code that would solve this > problem. (Every time "#find /usr/src -newer /boot/kernel" returns > changes in the usb code, I rebuild kernel and world.) > > Is there something I can enable that will capture the boot sequence > during a failed boot while devices are still being detected? > > # grep -i umass /var/log/console.log > > > Any helpful hints would be gratefully appreciated. > > # uname -a > FreeBSD utd65257.utdallas.edu 7.0-STABLE FreeBSD 7.0-STABLE #8: Mon Jul > 7 10:41:03 CDT 2008 > root@utd65257.utdallas.edu:/usr/obj/usr/src/sys/GENERIC i386 > > # sysctl -a | grep hw.physmem > hw.physmem: 3474407424 > > # dmesg | grep -i umass > umass0: 2> on uhub5 > da0 at umass-sim0 bus 0 target 0 lun 0 > > # grep swap /etc/fstab > /dev/ad8s1b none swap sw 0 0 > > # swapctl -l > Device: 1024-blocks Used: > /dev/ad8s1b 8388608 0 > > # grep -i usb /var/run/dmesg.boot > uhci0: port 0xff20-0xff3f irq 16 at > device 26.0 on pci0 > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhci1: port 0xff00-0xff1f irq 17 at > device 26.1 on pci0 > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: on usb1 > ehci0: mem 0xfebd9c00-0xfebd9fff irq > 22 at device 26.7 on pci0 > usb2: waiting for BIOS to give up control > usb2: EHCI version 1.0 > usb2: wrong number of companions (3 != 2) > usb2: companion controllers, 2 ports each: usb0 usb1 > usb2: on ehci0 > usb2: USB revision 2.0 > uhub2: on usb2 > ums0: on > uhub3 > uhci2: port 0xff80-0xff9f irq 23 at > device 29.0 on pci0 > usb3: on uhci2 > usb3: USB revision 1.0 > uhub4: on usb3 > uhci3: port 0xff60-0xff7f irq 17 at > device 29.1 on pci0 > usb4: on uhci3 > usb4: USB revision 1.0 > uhub5: on usb4 > uhci4: port 0xff40-0xff5f irq 18 at > device 29.2 on pci0 > usb5: on uhci4 > usb5: USB revision 1.0 > uhub6: on usb5 > ehci1: mem 0xff980800-0xff980bff irq > 23 at device 29.7 on pci0 > usb6: waiting for BIOS to give up control > usb6: timed out waiting for BIOS > usb6: EHCI version 1.0 > usb6: companion controllers, 2 ports each: usb3 usb4 usb5 > usb6: on ehci1 > usb6: USB revision 2.0 > uhub7: on usb6 > It might be something else, but I had usb problems in 6-STABLE until I disabled usb support in the bios. FreeBSD still detects the usb hardware. In my case there was some sort of conflict between the usb detection of the bios and the detection FreeBSD. The symptoms where very weird, because it also depended on the connected usb devices on time of boot. Connecting theme after booting did work. Ronald. From kris at FreeBSD.org Wed Jul 9 10:32:07 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Wed Jul 9 10:32:14 2008 Subject: disk questions: geom and zfs In-Reply-To: <2c7aa7cb6f8acbc18993b802bb3a5016.squirrel@cygnus> References: <2c7aa7cb6f8acbc18993b802bb3a5016.squirrel@cygnus> Message-ID: <487493A5.2010208@FreeBSD.org> matheus@eternamente.info wrote: > hail, > > I have a 7-stable: > > [matheus@xxx /usr/home/matheus]$ uname -a > FreeBSD xxx 7.0-STABLE FreeBSD 7.0-STABLE #2: Sun Jul 6 15:03:26 BRT 2008 > root@lamneth:/usr/obj/usr/src/sys/xxx_7 i386 > > and there exists three geom things. > > gconcat status > Name Status Components > concat/concat0 UP ad4 > ad5 > gmirror status > Name Status Components > mirror/mirror0 COMPLETE ad8s1 > ad10s1 > gstripe status > Name Status Components > stripe/stripe0 UP ad8s2 > ad10s2 > > and a small (100GB) zfs pool. > > the thing is, if I take all these disks to a 6.3R-p2 system, will I get in > trouble ? what if this 6.3R becomes 7-stable also, will this trouble > disappear ? I think it should just ignore the parts it can't recognise. I have a vague memory that something about the metadata format changed in one of the geom providers (mirror/stripe/something) so there might be a problem there. Try to research whether that is the case. In general you'll be better off if you just run it on 7.0 of course. Kris From 000.fbsd at quip.cz Wed Jul 9 10:59:38 2008 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Wed Jul 9 11:05:58 2008 Subject: disk questions: geom and zfs In-Reply-To: <2c7aa7cb6f8acbc18993b802bb3a5016.squirrel@cygnus> References: <2c7aa7cb6f8acbc18993b802bb3a5016.squirrel@cygnus> Message-ID: <48749A2C.4070805@quip.cz> matheus@eternamente.info wrote: > hail, > > I have a 7-stable: > > [matheus@xxx /usr/home/matheus]$ uname -a > FreeBSD xxx 7.0-STABLE FreeBSD 7.0-STABLE #2: Sun Jul 6 15:03:26 BRT 2008 > root@lamneth:/usr/obj/usr/src/sys/xxx_7 i386 > > and there exists three geom things. > > gconcat status > Name Status Components > concat/concat0 UP ad4 > ad5 > gmirror status > Name Status Components > mirror/mirror0 COMPLETE ad8s1 > ad10s1 > gstripe status > Name Status Components > stripe/stripe0 UP ad8s2 > ad10s2 > > and a small (100GB) zfs pool. > > the thing is, if I take all these disks to a 6.3R-p2 system, will I get in > trouble ? what if this 6.3R becomes 7-stable also, will this trouble > disappear ? There is incompatible change in gmirror metadata format and 6.x will not recognize gmirrors created or even booted with 7.x kernel. Miroslav Lachman From matheus at eternamente.info Wed Jul 9 11:42:08 2008 From: matheus at eternamente.info (matheus@eternamente.info) Date: Wed Jul 9 11:42:14 2008 Subject: disk questions: geom and zfs In-Reply-To: <487493A5.2010208@FreeBSD.org> References: <2c7aa7cb6f8acbc18993b802bb3a5016.squirrel@cygnus> <487493A5.2010208@FreeBSD.org> Message-ID: <0c213d395e7b8febf23e86c1124fd2f7.squirrel@cygnus.homeunix.com> first of all thanks, and, so far no gmirror and I wouldn't be surprised if after this info other couldn't work as well. no problem cause I can upgrade, just have to plan that. But about the disk order ? will both geom_* and zfs work ? thanks again, matheus From kris at FreeBSD.org Wed Jul 9 11:53:59 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Wed Jul 9 11:54:09 2008 Subject: disk questions: geom and zfs In-Reply-To: <0c213d395e7b8febf23e86c1124fd2f7.squirrel@cygnus.homeunix.com> References: <2c7aa7cb6f8acbc18993b802bb3a5016.squirrel@cygnus> <487493A5.2010208@FreeBSD.org> <0c213d395e7b8febf23e86c1124fd2f7.squirrel@cygnus.homeunix.com> Message-ID: <4874A6D4.90903@FreeBSD.org> matheus@eternamente.info wrote: > first of all thanks, > > and, so far no gmirror and I wouldn't be surprised if after this info > other couldn't work as well. no problem cause I can upgrade, just have to > plan that. But about the disk order ? will both geom_* and zfs work ? zpool works on top of GEOM, so it's all fine. e.g. you can build a zpool on top of a gmirror if you wanted to (although that example would probably be pointless) Kris From aragon at phat.za.net Wed Jul 9 16:16:04 2008 From: aragon at phat.za.net (Aragon Gouveia) Date: Wed Jul 9 16:16:10 2008 Subject: UMASS problem on 7.0 STABLE In-Reply-To: References: Message-ID: <20080709154425.GA50924@phat.za.net> Hi, | By Ronald Klop | [ 2008-07-09 11:51 +0200 ] > It might be something else, but I had usb problems in 6-STABLE until I > disabled usb support in the bios. FreeBSD still detects the usb hardware. > In my case there was some sort of conflict between the usb detection of > the bios and the detection FreeBSD. > The symptoms where very weird, because it also depended on the connected > usb devices on time of boot. Connecting theme after booting did work. I have a similar problem. If I boot up with a umass device connected, my 7.0-STABLE system core dumps when hald starts. http://www.freebsd.org/cgi/query-pr.cgi?pr=123714 I guess don't boot up with a umass device plugged in. :) Regards, Aragon From mike at sentex.net Wed Jul 9 19:31:38 2008 From: mike at sentex.net (Mike Tancsa) Date: Wed Jul 9 19:31:45 2008 Subject: AMD Geode LX crypto accelerator (glxsb) In-Reply-To: <20080622170507.5ac469d2@baby-jane-lamaiziere-net.local> References: <20080606234135.46144207@baby-jane-lamaiziere-net.local> <20080622170507.5ac469d2@baby-jane-lamaiziere-net.local> Message-ID: <200807091931.m69JVWej032290@lava.sentex.ca> At 11:05 AM 6/22/2008, Patrick Lamaizi?re wrote: >Le Fri, 6 Jun 2008 23:41:35 +0200, >Patrick Lamaizi?re a ?crit : > >Hello, > > > I'm trying to port the glxsb driver from OpenBSD to FreeBSD 7-STABLE > > (via the NetBSD port). > > " The glxsb driver supports the security block of the Geode LX > > series processors. The Geode LX is a member of the AMD Geode family > > of integrated x86 system chips. Hi, Thanks for porting this over! I am just trying it now with ipsec on a soekris 5501 Without the module loaded, I can do something simple like # sh s # cat s MEOUTSIDE=64.x.x.x MEINSIDE=192.168.5.0/24 REMOTEOUTSIDE=64.y.y.y REMOTEINSIDE=192.168.1.0/24 IPSECKEY=zxzpprlNH61N11SGfrCa8dxZ setkey -c < mem 0xa0000000-0xa0003fff irq 10 at device 1.2 on pci0 # sh s The result of line 1: Invalid argument. The result of line 2: Invalid argument. # What is the proper AES encryption to use for IPSEC ? Why is there a difference in syntax ? This is RELENG_7 from a few days ago. If I change the crypto to 3des-cbc, it works, but its not making use of the crypto offload of course. ---Mike From pschmehl_lists at tx.rr.com Wed Jul 9 22:04:00 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Wed Jul 9 22:04:07 2008 Subject: UMASS problem on 7.0 STABLE In-Reply-To: References: Message-ID: <397CB693D79D10BC90707DFF@utd65257.utdallas.edu> --On Wednesday, July 09, 2008 11:50:25 +0200 Ronald Klop wrote: > On Tue, 08 Jul 2008 20:27:26 +0200, Paul Schmehl > wrote: > >> Ever since I upgraded this workstation to 7.0 STABLE, I have been unable >> to reboot with my USB hard drive attached. During the boot sequence, >> the device is properly detected and identified, but then I get an error >> message, a crash dump and a reboot. I enabled /var/log/console.log in >> the hope that I would catch the error message, but it doesn't appear in >> the log. I also don't have any kernel dumps, so I can't trace those to >> see what the problem might be. >> >> An additional problem that I have is that, during boot, the system says >> there is no dump device available. This is despite the fact that swap >> is twice the real memory size and /etc/defaults/rc.conf defines dumpdev >> as auto. I even tried defining dumpdev as the swap partition (in >> /etc/rc.conf), but nothing changed. >> >> I have to be doing something wrong, but I'm at a loss to know what it >> is. I've rebuilt world and kernel nine times now, in the desparate hope >> that something might have changed in the usb code that would solve this >> problem. (Every time "#find /usr/src -newer /boot/kernel" returns >> changes in the usb code, I rebuild kernel and world.) >> >> Is there something I can enable that will capture the boot sequence >> during a failed boot while devices are still being detected? >> >> # grep -i umass /var/log/console.log >> >> >> Any helpful hints would be gratefully appreciated. >> >> # uname -a >> FreeBSD utd65257.utdallas.edu 7.0-STABLE FreeBSD 7.0-STABLE #8: Mon Jul >> 7 10:41:03 CDT 2008 >> root@utd65257.utdallas.edu:/usr/obj/usr/src/sys/GENERIC i386 >> >> # sysctl -a | grep hw.physmem >> hw.physmem: 3474407424 >> >> # dmesg | grep -i umass >> umass0: > 2> on uhub5 >> da0 at umass-sim0 bus 0 target 0 lun 0 >> >> # grep swap /etc/fstab >> /dev/ad8s1b none swap sw 0 0 >> >> # swapctl -l >> Device: 1024-blocks Used: >> /dev/ad8s1b 8388608 0 >> >> # grep -i usb /var/run/dmesg.boot >> uhci0: port 0xff20-0xff3f irq 16 at >> device 26.0 on pci0 >> usb0: on uhci0 >> usb0: USB revision 1.0 >> uhub0: on usb0 >> uhci1: port 0xff00-0xff1f irq 17 at >> device 26.1 on pci0 >> usb1: on uhci1 >> usb1: USB revision 1.0 >> uhub1: on usb1 >> ehci0: mem 0xfebd9c00-0xfebd9fff irq >> 22 at device 26.7 on pci0 >> usb2: waiting for BIOS to give up control >> usb2: EHCI version 1.0 >> usb2: wrong number of companions (3 != 2) >> usb2: companion controllers, 2 ports each: usb0 usb1 >> usb2: on ehci0 >> usb2: USB revision 2.0 >> uhub2: on usb2 >> ums0: on >> uhub3 >> uhci2: port 0xff80-0xff9f irq 23 at >> device 29.0 on pci0 >> usb3: on uhci2 >> usb3: USB revision 1.0 >> uhub4: on usb3 >> uhci3: port 0xff60-0xff7f irq 17 at >> device 29.1 on pci0 >> usb4: on uhci3 >> usb4: USB revision 1.0 >> uhub5: on usb4 >> uhci4: port 0xff40-0xff5f irq 18 at >> device 29.2 on pci0 >> usb5: on uhci4 >> usb5: USB revision 1.0 >> uhub6: on usb5 >> ehci1: mem 0xff980800-0xff980bff irq >> 23 at device 29.7 on pci0 >> usb6: waiting for BIOS to give up control >> usb6: timed out waiting for BIOS >> usb6: EHCI version 1.0 >> usb6: companion controllers, 2 ports each: usb3 usb4 usb5 >> usb6: on ehci1 >> usb6: USB revision 2.0 >> uhub7: on usb6 >> > > It might be something else, but I had usb problems in 6-STABLE until I > disabled usb support in the bios. FreeBSD still detects the usb hardware. In > my case there was some sort of conflict between the usb detection of the bios > and the detection FreeBSD. > The symptoms where very weird, because it also depended on the connected usb > devices on time of boot. Connecting theme after booting did work. > Thanks. I will give that a try, right after I finish running portupgrade. I'll report the results here. -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. From patfbsd at davenulle.org Thu Jul 10 06:34:17 2008 From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=) Date: Thu Jul 10 06:34:25 2008 Subject: AMD Geode LX crypto accelerator (glxsb) In-Reply-To: <200807091931.m69JVWej032290@lava.sentex.ca> References: <20080606234135.46144207@baby-jane-lamaiziere-net.local> <20080622170507.5ac469d2@baby-jane-lamaiziere-net.local> <200807091931.m69JVWej032290@lava.sentex.ca> Message-ID: <20080710083411.0842ba20@baby-jane-lamaiziere-net.local> Le Wed, 09 Jul 2008 15:31:30 -0400, Mike Tancsa a ?crit : > Without the module loaded, I can do something simple like > > > # sh s > # cat s > MEOUTSIDE=64.x.x.x > MEINSIDE=192.168.5.0/24 > REMOTEOUTSIDE=64.y.y.y > REMOTEINSIDE=192.168.1.0/24 > IPSECKEY=zxzpprlNH61N11SGfrCa8dxZ > > > setkey -c < add $MEOUTSIDE $REMOTEOUTSIDE esp 1049 > -m any -E rijndael-cbc "$IPSECKEY"; > add $REMOTEOUTSIDE $MEOUTSIDE esp 1049 > -m any -E rijndael-cbc "$IPSECKEY"; > spdadd $MEINSIDE $REMOTEINSIDE any -P > out ipsec esp/tunnel/$MEOUTSIDE-$REMOTEOUTSIDE/require; > spdadd $REMOTEINSIDE $MEINSIDE any -P > in ipsec esp/tunnel/$REMOTEOUTSIDE-$MEOUTSIDE/require; > EOF > > > But if I load the glxsb modules, setkey fails on the same policy. > > # setkey -F > # setkey -FP > # setkey -DP > No SPD entries. > # kldload glxsb > # dmesg | tail > vr0: link state changed to DOWN > vr0: link state changed to UP > vr0: promiscuous mode enabled > vr0: promiscuous mode disabled > vr1: promiscuous mode enabled > vr1: promiscuous mode disabled > vr1: promiscuous mode enabled > vr1: promiscuous mode disabled > glxsb0: detached > glxsb0: (AES-128-CBC,RNG)> mem 0xa0000000-0xa0003fff irq 10 at device 1.2 on > pci0 # sh s > The result of line 1: Invalid argument. > The result of line 2: Invalid argument. > # > > What is the proper AES encryption to use for > IPSEC ? It is rijndael-cbc. > Why is there a difference in syntax ? I don't know. May be the key ? The length of your key is 24 characters, it should be 16 (128 bits). Does it work with a 128 bits key ? My setkey setup is flush; spdflush; add 192.168.1.21 192.168.1.200 esp 1011 -E rijndael-cbc "0123456789012345" -A hmac-sha1 "98765432109876543210"; add 192.168.1.200 192.168.1.21 esp 1012 -E rijndael-cbc "0123456789012345" -A hmac-sha1 "98765432109876543210"; spdadd 192.168.1.200 192.168.1.21 any -P out ipsec esp/transport//require; spdadd 192.168.1.21 192.168.1.200 any -P in ipsec esp/transport//require; Regards. From hausen at punkt.de Thu Jul 10 08:52:38 2008 From: hausen at punkt.de (Patrick M. Hausen) Date: Thu Jul 10 08:52:48 2008 Subject: dhclient and resolv.conf.sav Message-ID: <20080710085234.GD38495@hugo10.ka.punkt.de> Hello, we have been bitten by something that obvoiusly is a feature, not a bug, but I do not quite understand the intentions and reasoning behind it. I have a host with manual interface and resolver configuration and an additional interface that should get it's IP address via DHCP. But only it's IP address and netmask, nothing else. The DHCP server used hands out only IP addresses/netmasks, no domain-name-servers, domain-name, etc. configured. Yet, if there happens to exist a /etc/resolv.conf.sav file, every renewal of the lease by dhclient overwrites the contents of /etc/resolv.conf with those of resolv.conf.sav. In my particular case the .sav file contained an internal nameserver that was used when I initially set up the host in the lab. This entry was of no use to the server after it had been deployed in our datacenter. Can anyone shed some light on the intended mechanism? Studying the dhclient-script was not too helpful, either. Thanks, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: J?rgen Egeling AG Mannheim 108285 From ob at e-Gitt.NET Thu Jul 10 09:40:07 2008 From: ob at e-Gitt.NET (Oliver Brandmueller) Date: Thu Jul 10 09:40:14 2008 Subject: BIND update? Message-ID: <20080710094006.GX6902@e-Gitt.NET> Hi, shouldn't there be a very urgent BIND update somewhere around? I understand the latest flaw doesn't impact system security directly. Nevertheless, it might impact the security of the whole network indirectly. - Olli -- | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | | Ich bin das Internet. Sowahr ich Gott helfe. | | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! | From peterjeremy at optushome.com.au Thu Jul 10 09:44:54 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Thu Jul 10 09:45:01 2008 Subject: BIND update? In-Reply-To: <20080710094006.GX6902@e-Gitt.NET> References: <20080710094006.GX6902@e-Gitt.NET> Message-ID: <20080710094451.GS62764@server.vk2pj.dyndns.org> On 2008-Jul-10 11:40:06 +0200, Oliver Brandmueller wrote: >shouldn't there be a very urgent BIND update somewhere around? There has been a very long thread about this in -security. Leaving out the trolls and flaming, the salient points are: - The bind port has been updated to include the relevant patches - The security team is aware of the issue and is working on a fix. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080710/1ad275fe/attachment.pgp From koitsu at FreeBSD.org Thu Jul 10 09:58:09 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Jul 10 09:58:17 2008 Subject: BIND update? In-Reply-To: <20080710094451.GS62764@server.vk2pj.dyndns.org> References: <20080710094006.GX6902@e-Gitt.NET> <20080710094451.GS62764@server.vk2pj.dyndns.org> Message-ID: <20080710095809.GA59288@eos.sc1.parodius.com> On Thu, Jul 10, 2008 at 07:44:51PM +1000, Peter Jeremy wrote: > On 2008-Jul-10 11:40:06 +0200, Oliver Brandmueller wrote: > >shouldn't there be a very urgent BIND update somewhere around? > > There has been a very long thread about this in -security. Leaving > out the trolls and flaming, the salient points are: > - The bind port has been updated to include the relevant patches > - The security team is aware of the issue and is working on a fix. I'm curious to know why the BIND ports were updated before the base system BIND. Absolutely no offence intended towards Doug, but the priority seems reversed. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From delphij at delphij.net Thu Jul 10 10:17:50 2008 From: delphij at delphij.net (Xin LI) Date: Thu Jul 10 10:17:57 2008 Subject: BIND update? In-Reply-To: <20080710095809.GA59288@eos.sc1.parodius.com> References: <20080710094006.GX6902@e-Gitt.NET> <20080710094451.GS62764@server.vk2pj.dyndns.org> <20080710095809.GA59288@eos.sc1.parodius.com> Message-ID: <4875E1B6.3010407@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeremy Chadwick wrote: | On Thu, Jul 10, 2008 at 07:44:51PM +1000, Peter Jeremy wrote: |> On 2008-Jul-10 11:40:06 +0200, Oliver Brandmueller wrote: |>> shouldn't there be a very urgent BIND update somewhere around? |> There has been a very long thread about this in -security. Leaving |> out the trolls and flaming, the salient points are: |> - The bind port has been updated to include the relevant patches |> - The security team is aware of the issue and is working on a fix. | | I'm curious to know why the BIND ports were updated before the base | system BIND. Absolutely no offence intended towards Doug, but the | priority seems reversed. Speaking as my own: Base system needs more conservative QA process, e.g. we want to minimize the change, we need to analyst the impact (FWIW the security fix would negatively affect heavy traffic sites) and document it (i.e. the security advisory), and we want to make the change a one-time one (for instance, shall we patch libc's resolver as well?), so rushing into a "presumably patched" state would not be a very good solution. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkh14bYACgkQi+vbBBjt66ALTQCdEozuYtUUgI1bn/nitLeIZHqj 6Y0AnRb1wOIklk3h6Q5MFB4keEy9ZRDP =PAr6 -----END PGP SIGNATURE----- From ob at e-Gitt.NET Thu Jul 10 10:25:35 2008 From: ob at e-Gitt.NET (Oliver Brandmueller) Date: Thu Jul 10 10:25:51 2008 Subject: BIND update? In-Reply-To: <20080710094451.GS62764@server.vk2pj.dyndns.org> References: <20080710094006.GX6902@e-Gitt.NET> <20080710094451.GS62764@server.vk2pj.dyndns.org> Message-ID: <20080710102533.GZ6902@e-Gitt.NET> Hi, On Thu, Jul 10, 2008 at 07:44:51PM +1000, Peter Jeremy wrote: > On 2008-Jul-10 11:40:06 +0200, Oliver Brandmueller wrote: > >shouldn't there be a very urgent BIND update somewhere around? > > There has been a very long thread about this in -security. Leaving > out the trolls and flaming, the salient points are: > - The bind port has been updated to include the relevant patches > - The security team is aware of the issue and is working on a fix. OK, thanx for clarification. I totally overlooked the updated bind port; anyhow, I use base system bind and didn't plan to change that (although it might me a good idea, as this situation clearly shows). - Olli -- | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | | Ich bin das Internet. Sowahr ich Gott helfe. | | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080710/d49a110b/attachment.pgp From ob at e-Gitt.NET Thu Jul 10 10:29:56 2008 From: ob at e-Gitt.NET (Oliver Brandmueller) Date: Thu Jul 10 10:30:04 2008 Subject: BIND update? In-Reply-To: <4875E1B6.3010407@delphij.net> References: <20080710094006.GX6902@e-Gitt.NET> <20080710094451.GS62764@server.vk2pj.dyndns.org> <20080710095809.GA59288@eos.sc1.parodius.com> <4875E1B6.3010407@delphij.net> Message-ID: <20080710102955.GA6902@e-Gitt.NET> Hi, On Thu, Jul 10, 2008 at 03:17:26AM -0700, Xin LI wrote: > Speaking as my own: Base system needs more conservative QA process, > e.g. we want to minimize the change, we need to analyst the impact > (FWIW the security fix would negatively affect heavy traffic sites) > and document it (i.e. the security advisory), and we want to make the > change a one-time one (for instance, shall we patch libc's resolver as > well?), so rushing into a "presumably patched" state would not be a > very good solution. I understand the reasons and that surely needs to be taken into account. Does that imply that the FreeBSD project got the information later than f.e. M$ or Debian, who are usually not really known for coming up too fast with such fixes? - Olli -- | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | | Ich bin das Internet. Sowahr ich Gott helfe. | | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080710/6f495f93/attachment.pgp From andrew at modulus.org Thu Jul 10 10:53:19 2008 From: andrew at modulus.org (Andrew Snow) Date: Thu Jul 10 10:53:26 2008 Subject: BIND update? In-Reply-To: <4875E1B6.3010407@delphij.net> References: <20080710094006.GX6902@e-Gitt.NET> <20080710094451.GS62764@server.vk2pj.dyndns.org> <20080710095809.GA59288@eos.sc1.parodius.com> <4875E1B6.3010407@delphij.net> Message-ID: <4875EA0C.5010109@modulus.org> Xin LI wrote: > Speaking as my own: Base system needs more conservative QA process, e.g. ... > rushing into a "presumably patched" state would not be a very good > solution. I second this opinion. When there is hype all over the net about a new vulnerability, it is too easy to allow ill-considered changes to be rushed in without enough critical thought and testing. - Andrew From imb at protected-networks.net Thu Jul 10 10:57:45 2008 From: imb at protected-networks.net (Michael Butler) Date: Thu Jul 10 10:57:52 2008 Subject: BIND update? In-Reply-To: <4875EA0C.5010109@modulus.org> References: <20080710094006.GX6902@e-Gitt.NET> <20080710094451.GS62764@server.vk2pj.dyndns.org> <20080710095809.GA59288@eos.sc1.parodius.com> <4875E1B6.3010407@delphij.net> <4875EA0C.5010109@modulus.org> Message-ID: <4875EB21.6@protected-networks.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Snow wrote: | Xin LI wrote: |> Speaking as my own: Base system needs more conservative QA process, e.g. | ... |> rushing into a "presumably patched" state would not be a very good |> solution. | | I second this opinion. When there is hype all over the net about a new | vulnerability, it is too easy to allow ill-considered changes to be | rushed in without enough critical thought and testing. And even more so when the perceived "breakage" is in the design rather than any specific implementation, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkh16yEACgkQQv9rrgRC1JKtCgCgoMbmQ+clRgDvZBbHzLJxB0No EgYAn15Hk/jUcDnnahN0msD1J6+xUa48 =oIUJ -----END PGP SIGNATURE----- From patfbsd at davenulle.org Thu Jul 10 11:09:08 2008 From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=) Date: Thu Jul 10 11:09:16 2008 Subject: AMD Geode LX crypto accelerator (glxsb) In-Reply-To: <200807091931.m69JVWej032290@lava.sentex.ca> References: <20080606234135.46144207@baby-jane-lamaiziere-net.local> <20080622170507.5ac469d2@baby-jane-lamaiziere-net.local> <200807091931.m69JVWej032290@lava.sentex.ca> Message-ID: <20080710130904.6c06fdfb@baby-jane-lamaiziere-net.local> Le Wed, 09 Jul 2008 15:31:30 -0400, Mike Tancsa a ?crit : > Without the module loaded, I can do something simple like > glxsb0: detached > glxsb0: (AES-128-CBC,RNG)> mem 0xa0000000-0xa0003fff irq 10 at device 1.2 on > pci0 # sh s > The result of line 1: Invalid argument. > The result of line 2: Invalid argument. > > What is the proper AES encryption to use for > IPSEC ? Why is there a difference in syntax > ? I've found, i think. The Geode handles only AES with a 128 bits key. When setkey/ipsec opens a crypto session, the driver returns an error (EINVAL) if the key length is != 128. So setkey fails. There is no way to tell to the crypto framework that we can do only AES with 128 bits keys. It is a problem in this case. I don't have any solution, I can just add a BUG section in the man page for this case. Thank you for the report. Regards. From mike at sentex.net Thu Jul 10 11:46:26 2008 From: mike at sentex.net (Mike Tancsa) Date: Thu Jul 10 11:46:33 2008 Subject: AMD Geode LX crypto accelerator (glxsb) In-Reply-To: <20080710130904.6c06fdfb@baby-jane-lamaiziere-net.local> References: <20080606234135.46144207@baby-jane-lamaiziere-net.local> <20080622170507.5ac469d2@baby-jane-lamaiziere-net.local> <200807091931.m69JVWej032290@lava.sentex.ca> <20080710130904.6c06fdfb@baby-jane-lamaiziere-net.local> Message-ID: <200807101146.m6ABkJib035927@lava.sentex.ca> At 07:09 AM 7/10/2008, Patrick Lamaizi?re wrote: >I've found, i think. The Geode handles only AES with a 128 bits key. > >When setkey/ipsec opens a crypto session, the driver returns an error >(EINVAL) if the key length is != 128. So setkey fails. > >There is no way to tell to the crypto framework that we can do only AES >with 128 bits keys. It is a problem in this case. Hi, Yes, that appears to be it! >I don't have any solution, I can just add a BUG section in the man >page for this case. Perhaps just a limitation/caveat as opposed to a bug :) Thanks for porting this over! I will give it a try with openvpn next. Any plans to integrate it into the tree ? ---Mike From edwin at mavetju.org Thu Jul 10 12:08:26 2008 From: edwin at mavetju.org (Edwin Groothuis) Date: Thu Jul 10 12:08:35 2008 Subject: BIND update? In-Reply-To: <20080710102533.GZ6902@e-Gitt.NET> References: <20080710094006.GX6902@e-Gitt.NET> <20080710094451.GS62764@server.vk2pj.dyndns.org> <20080710102533.GZ6902@e-Gitt.NET> Message-ID: <20080710120753.GA41541@k7.mavetju> On Thu, Jul 10, 2008 at 12:25:33PM +0200, Oliver Brandmueller wrote: > OK, thanx for clarification. I totally overlooked the updated bind port; > anyhow, I use base system bind and didn't plan to change that (although > it might me a good idea, as this situation clearly shows). You can always use the WITH_REPLACE_BASE option in the port to overwrite the base system named, or use the differences in the extracted tarball of 9.5.0 vs 9.5.0-P1 to update the source of the base one yourself. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From edwin at mavetju.org Thu Jul 10 12:17:49 2008 From: edwin at mavetju.org (Edwin Groothuis) Date: Thu Jul 10 12:17:56 2008 Subject: BIND update? In-Reply-To: <20080710102955.GA6902@e-Gitt.NET> References: <20080710094006.GX6902@e-Gitt.NET> <20080710094451.GS62764@server.vk2pj.dyndns.org> <20080710095809.GA59288@eos.sc1.parodius.com> <4875E1B6.3010407@delphij.net> <20080710102955.GA6902@e-Gitt.NET> Message-ID: <20080710121715.GB41541@k7.mavetju> On Thu, Jul 10, 2008 at 12:29:55PM +0200, Oliver Brandmueller wrote: > Hi, > > On Thu, Jul 10, 2008 at 03:17:26AM -0700, Xin LI wrote: > > Speaking as my own: Base system needs more conservative QA process, > > e.g. we want to minimize the change, we need to analyst the impact > > (FWIW the security fix would negatively affect heavy traffic sites) > > and document it (i.e. the security advisory), and we want to make the > > change a one-time one (for instance, shall we patch libc's resolver as > > well?), so rushing into a "presumably patched" state would not be a > > very good solution. > > I understand the reasons and that surely needs to be taken into account. > Does that imply that the FreeBSD project got the information later than > f.e. M$ or Debian, who are usually not really known for coming up too > fast with such fixes? According to http://www.kb.cert.org/vuls/id/800113, FreeBSD was tested, but it doesn't say if it was informed. Microsoft knew about it earlier than yesterday, because they are a DNS software provider. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From ml at t-b-o-h.net Thu Jul 10 14:03:43 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Thu Jul 10 14:03:50 2008 Subject: [freebsd-stable] Re: BIND update? In-Reply-To: <20080710120753.GA41541@k7.mavetju> Message-ID: <200807101403.m6AE3OIl095039@himinbjorg.tucs-beachin-obx-house.com> > > On Thu, Jul 10, 2008 at 12:25:33PM +0200, Oliver Brandmueller wrote: > > OK, thanx for clarification. I totally overlooked the updated bind port; > > anyhow, I use base system bind and didn't plan to change that (although > > it might me a good idea, as this situation clearly shows). > > You can always use the WITH_REPLACE_BASE option in the port to > overwrite the base system named, or use the differences in the > extracted tarball of 9.5.0 vs 9.5.0-P1 to update the source of the > base one yourself. > Shouldn't you also add : NO_BIND= true # do not build BIND into /etc/make.conf if you do, so it doesn't get clobbered? Tuc/TBOH From koitsu at FreeBSD.org Thu Jul 10 14:10:24 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Jul 10 14:10:31 2008 Subject: [freebsd-stable] Re: BIND update? In-Reply-To: <200807101403.m6AE3OIl095039@himinbjorg.tucs-beachin-obx-house.com> References: <20080710120753.GA41541@k7.mavetju> <200807101403.m6AE3OIl095039@himinbjorg.tucs-beachin-obx-house.com> Message-ID: <20080710141023.GA70961@eos.sc1.parodius.com> On Thu, Jul 10, 2008 at 10:03:24AM -0400, Tuc at T-B-O-H.NET wrote: > > On Thu, Jul 10, 2008 at 12:25:33PM +0200, Oliver Brandmueller wrote: > > > OK, thanx for clarification. I totally overlooked the updated bind port; > > > anyhow, I use base system bind and didn't plan to change that (although > > > it might me a good idea, as this situation clearly shows). > > > > You can always use the WITH_REPLACE_BASE option in the port to > > overwrite the base system named, or use the differences in the > > extracted tarball of 9.5.0 vs 9.5.0-P1 to update the source of the > > base one yourself. > > > Shouldn't you also add : > > NO_BIND= true # do not build BIND > > into /etc/make.conf if you do, so it doesn't get clobbered? That would be WITHOUT_BIND=true in /etc/src.conf on RELENG_7 and later, just for added clarification. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From stefan.lambrev at moneybookers.com Thu Jul 10 14:13:50 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Thu Jul 10 14:13:56 2008 Subject: [freebsd-stable] Re: BIND update? In-Reply-To: <200807101403.m6AE3OIl095039@himinbjorg.tucs-beachin-obx-house.com> References: <200807101403.m6AE3OIl095039@himinbjorg.tucs-beachin-obx-house.com> Message-ID: <48761919.8050807@moneybookers.com> Tuc at T-B-O-H.NET wrote: >> On Thu, Jul 10, 2008 at 12:25:33PM +0200, Oliver Brandmueller wrote: >> >>> OK, thanx for clarification. I totally overlooked the updated bind port; >>> anyhow, I use base system bind and didn't plan to change that (although >>> it might me a good idea, as this situation clearly shows). >>> >> You can always use the WITH_REPLACE_BASE option in the port to >> overwrite the base system named, or use the differences in the >> extracted tarball of 9.5.0 vs 9.5.0-P1 to update the source of the >> base one yourself. >> >> > Shouldn't you also add : > > NO_BIND= true # do not build BIND > > into /etc/make.conf if you do, so it doesn't get clobbered? > Last time I checked WITH_REPLACE_BASE was conflicting with firefox, mozilla, thunderbird and everything released from Mozzila ... I suggest using bind from ports without replacing - just look at /etc/defaults/rc.conf & named_program="XX" > Tuc/TBOH > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Best Wishes, Stefan Lambrev ICQ# 24134177 From ml at t-b-o-h.net Thu Jul 10 14:22:57 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Thu Jul 10 14:23:03 2008 Subject: [freebsd-stable] Re: BIND update? In-Reply-To: <20080710141023.GA70961@eos.sc1.parodius.com> Message-ID: <200807101422.m6AEMeMI095414@himinbjorg.tucs-beachin-obx-house.com> > > On Thu, Jul 10, 2008 at 10:03:24AM -0400, Tuc at T-B-O-H.NET wrote: > > > On Thu, Jul 10, 2008 at 12:25:33PM +0200, Oliver Brandmueller wrote: > > > > OK, thanx for clarification. I totally overlooked the updated bind port; > > > > anyhow, I use base system bind and didn't plan to change that (although > > > > it might me a good idea, as this situation clearly shows). > > > > > > You can always use the WITH_REPLACE_BASE option in the port to > > > overwrite the base system named, or use the differences in the > > > extracted tarball of 9.5.0 vs 9.5.0-P1 to update the source of the > > > base one yourself. > > > > > Shouldn't you also add : > > > > NO_BIND= true # do not build BIND > > > > into /etc/make.conf if you do, so it doesn't get clobbered? > > That would be WITHOUT_BIND=true in /etc/src.conf on RELENG_7 and later, > just for added clarification. > Thanks for the catch. I was looking at a 5.5 system I was doing that on. I haven't replaced base on my 7.0's, those were only changes to /etc/rc.conf for named_program="/usr/local/sbin/named". Tuc/TBOH From mike at sentex.net Thu Jul 10 14:58:28 2008 From: mike at sentex.net (Mike Tancsa) Date: Thu Jul 10 14:58:40 2008 Subject: BIND update? In-Reply-To: <20080710102955.GA6902@e-Gitt.NET> References: <20080710094006.GX6902@e-Gitt.NET> <20080710094451.GS62764@server.vk2pj.dyndns.org> <20080710095809.GA59288@eos.sc1.parodius.com> <4875E1B6.3010407@delphij.net> <20080710102955.GA6902@e-Gitt.NET> Message-ID: <200807101457.m6AEvvlD036748@lava.sentex.ca> At 06:29 AM 7/10/2008, Oliver Brandmueller wrote: >Hi, > >On Thu, Jul 10, 2008 at 03:17:26AM -0700, Xin LI wrote: > > Speaking as my own: Base system needs more conservative QA process, > > e.g. we want to minimize the change, we need to analyst the impact > > (FWIW the security fix would negatively affect heavy traffic sites) > > and document it (i.e. the security advisory), and we want to make the > > change a one-time one (for instance, shall we patch libc's resolver as > > well?), so rushing into a "presumably patched" state would not be a > > very good solution. > >I understand the reasons and that surely needs to be taken into account. >Does that imply that the FreeBSD project got the information later than >f.e. M$ or Debian, who are usually not really known for coming up too >fast with such fixes? Even with all the extra time and resources MS had, look at the breakage their fix has caused. ---Mike From pschmehl_lists at tx.rr.com Thu Jul 10 16:00:14 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Thu Jul 10 16:00:26 2008 Subject: UMASS problem on 7.0 STABLE In-Reply-To: References: Message-ID: <94439F09F64DAEEE70087136@utd65257.utdallas.edu> --On Wednesday, July 09, 2008 11:50:25 +0200 Ronald Klop wrote: > On Tue, 08 Jul 2008 20:27:26 +0200, Paul Schmehl > wrote: > >> Ever since I upgraded this workstation to 7.0 STABLE, I have been unable >> to reboot with my USB hard drive attached. During the boot sequence, >> the device is properly detected and identified, but then I get an error >> message, a crash dump and a reboot. I enabled /var/log/console.log in >> the hope that I would catch the error message, but it doesn't appear in >> the log. I also don't have any kernel dumps, so I can't trace those to >> see what the problem might be. >> >> An additional problem that I have is that, during boot, the system says >> there is no dump device available. This is despite the fact that swap >> is twice the real memory size and /etc/defaults/rc.conf defines dumpdev >> as auto. I even tried defining dumpdev as the swap partition (in >> /etc/rc.conf), but nothing changed. >> >> I have to be doing something wrong, but I'm at a loss to know what it >> is. I've rebuilt world and kernel nine times now, in the desparate hope >> that something might have changed in the usb code that would solve this >> problem. (Every time "#find /usr/src -newer /boot/kernel" returns >> changes in the usb code, I rebuild kernel and world.) >> >> Is there something I can enable that will capture the boot sequence >> during a failed boot while devices are still being detected? >> >> # grep -i umass /var/log/console.log >> >> >> Any helpful hints would be gratefully appreciated. >> >> # uname -a >> FreeBSD utd65257.utdallas.edu 7.0-STABLE FreeBSD 7.0-STABLE #8: Mon Jul >> 7 10:41:03 CDT 2008 >> root@utd65257.utdallas.edu:/usr/obj/usr/src/sys/GENERIC i386 >> >> # sysctl -a | grep hw.physmem >> hw.physmem: 3474407424 >> >> # dmesg | grep -i umass >> umass0: > 2> on uhub5 >> da0 at umass-sim0 bus 0 target 0 lun 0 >> >> # grep swap /etc/fstab >> /dev/ad8s1b none swap sw 0 0 >> >> # swapctl -l >> Device: 1024-blocks Used: >> /dev/ad8s1b 8388608 0 >> >> # grep -i usb /var/run/dmesg.boot >> uhci0: port 0xff20-0xff3f irq 16 at >> device 26.0 on pci0 >> usb0: on uhci0 >> usb0: USB revision 1.0 >> uhub0: on usb0 >> uhci1: port 0xff00-0xff1f irq 17 at >> device 26.1 on pci0 >> usb1: on uhci1 >> usb1: USB revision 1.0 >> uhub1: on usb1 >> ehci0: mem 0xfebd9c00-0xfebd9fff irq >> 22 at device 26.7 on pci0 >> usb2: waiting for BIOS to give up control >> usb2: EHCI version 1.0 >> usb2: wrong number of companions (3 != 2) >> usb2: companion controllers, 2 ports each: usb0 usb1 >> usb2: on ehci0 >> usb2: USB revision 2.0 >> uhub2: on usb2 >> ums0: on >> uhub3 >> uhci2: port 0xff80-0xff9f irq 23 at >> device 29.0 on pci0 >> usb3: on uhci2 >> usb3: USB revision 1.0 >> uhub4: on usb3 >> uhci3: port 0xff60-0xff7f irq 17 at >> device 29.1 on pci0 >> usb4: on uhci3 >> usb4: USB revision 1.0 >> uhub5: on usb4 >> uhci4: port 0xff40-0xff5f irq 18 at >> device 29.2 on pci0 >> usb5: on uhci4 >> usb5: USB revision 1.0 >> uhub6: on usb5 >> ehci1: mem 0xff980800-0xff980bff irq >> 23 at device 29.7 on pci0 >> usb6: waiting for BIOS to give up control >> usb6: timed out waiting for BIOS >> usb6: EHCI version 1.0 >> usb6: companion controllers, 2 ports each: usb3 usb4 usb5 >> usb6: on ehci1 >> usb6: USB revision 2.0 >> uhub7: on usb6 >> > > It might be something else, but I had usb problems in 6-STABLE until I > disabled usb support in the bios. FreeBSD still detects the usb hardware. In > my case there was some sort of conflict between the usb detection of the bios > and the detection FreeBSD. > The symptoms where very weird, because it also depended on the connected usb > devices on time of boot. Connecting theme after booting did work. > Dell's BIOS has three options for the USB controller; off, on and no umass device support. Off allows the box to boot properly, but I have no keyboard. (Kind of not useful.) The other two manifest the same problem. So this didn't solve the problem for me. -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. From pschmehl_lists at tx.rr.com Thu Jul 10 16:09:24 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Thu Jul 10 16:09:31 2008 Subject: Any idea when a bind update will be forthcoming? Message-ID: <6288FD55AC2A881165583218@utd65257.utdallas.edu> Given the serious nature of the vulnerability, I'm sure this is at the top of someone's list. Do we have a scheduled release date yet? -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. From kkutzko at teksavvy.com Thu Jul 10 16:23:55 2008 From: kkutzko at teksavvy.com (Kevin K) Date: Thu Jul 10 16:24:02 2008 Subject: Any idea when a bind update will be forthcoming? In-Reply-To: <6288FD55AC2A881165583218@utd65257.utdallas.edu> References: <6288FD55AC2A881165583218@utd65257.utdallas.edu> Message-ID: <003e01c8e2a9$27641540$762c3fc0$@com> > Given the serious nature of the vulnerability, I'm sure this is at the > top of > someone's list. Do we have a scheduled release date yet? >From -security : >Dear all, > >Doug just updated the ports tree with the updated BIND ports. If you >urgently want to upgrade and really cannot wait for the advisory. Please >use the ports system to get up to speed. > >Thanks Doug for working on this on such short notice! > >Cheers, >remko I understand you can implement the patch manually and rebuild BIND yourself, someone listed the steps needed to do that in -security as well. ~k From sullrich at gmail.com Thu Jul 10 16:38:04 2008 From: sullrich at gmail.com (Scott Ullrich) Date: Thu Jul 10 16:38:14 2008 Subject: Any idea when a bind update will be forthcoming? In-Reply-To: <6288FD55AC2A881165583218@utd65257.utdallas.edu> References: <6288FD55AC2A881165583218@utd65257.utdallas.edu> Message-ID: On Thu, Jul 10, 2008 at 12:09 PM, Paul Schmehl wrote: > Given the serious nature of the vulnerability, I'm sure this is at the top > of someone's list. Do we have a scheduled release date yet? See the thread "BIND update?". Scott PS: please do not crosspost. From brooks at freebsd.org Thu Jul 10 16:57:15 2008 From: brooks at freebsd.org (Brooks Davis) Date: Thu Jul 10 16:57:23 2008 Subject: dhclient and resolv.conf.sav In-Reply-To: <20080710085234.GD38495@hugo10.ka.punkt.de> References: <20080710085234.GD38495@hugo10.ka.punkt.de> Message-ID: <20080710165741.GA12966@lor.one-eyed-alien.net> On Thu, Jul 10, 2008 at 10:52:35AM +0200, Patrick M. Hausen wrote: > Hello, > > we have been bitten by something that obvoiusly > is a feature, not a bug, but I do not quite understand > the intentions and reasoning behind it. > > I have a host with manual interface and resolver configuration > and an additional interface that should get it's IP address > via DHCP. But only it's IP address and netmask, nothing else. > > The DHCP server used hands out only IP addresses/netmasks, > no domain-name-servers, domain-name, etc. configured. > > Yet, if there happens to exist a /etc/resolv.conf.sav file, > every renewal of the lease by dhclient overwrites the contents > of /etc/resolv.conf with those of resolv.conf.sav. > > In my particular case the .sav file contained an internal > nameserver that was used when I initially set up the host > in the lab. This entry was of no use to the server after > it had been deployed in our datacenter. > > Can anyone shed some light on the intended mechanism? > Studying the dhclient-script was not too helpful, either. I suspect the theory is that you can have a static resolv.conf around that gets installed when there isn't anything else to use. In practice, I think it mostly causes problems. I'm somewhat tempted to remove the creation of the file and add something like a resolv.conf.default in it's place. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080710/18a7a016/attachment.pgp From ronald-freebsd8 at klop.yi.org Thu Jul 10 19:47:22 2008 From: ronald-freebsd8 at klop.yi.org (Ronald Klop) Date: Thu Jul 10 19:47:36 2008 Subject: UMASS problem on 7.0 STABLE In-Reply-To: <94439F09F64DAEEE70087136@utd65257.utdallas.edu> References: <94439F09F64DAEEE70087136@utd65257.utdallas.edu> Message-ID: On Thu, 10 Jul 2008 17:31:51 +0200, Paul Schmehl wrote: > --On Wednesday, July 09, 2008 11:50:25 +0200 Ronald Klop > wrote: > >> On Tue, 08 Jul 2008 20:27:26 +0200, Paul Schmehl >> >> wrote: >> >>> Ever since I upgraded this workstation to 7.0 STABLE, I have been >>> unable >>> to reboot with my USB hard drive attached. During the boot sequence, >>> the device is properly detected and identified, but then I get an error >>> message, a crash dump and a reboot. I enabled /var/log/console.log in >>> the hope that I would catch the error message, but it doesn't appear in >>> the log. I also don't have any kernel dumps, so I can't trace those to >>> see what the problem might be. >>> >>> An additional problem that I have is that, during boot, the system says >>> there is no dump device available. This is despite the fact that swap >>> is twice the real memory size and /etc/defaults/rc.conf defines dumpdev >>> as auto. I even tried defining dumpdev as the swap partition (in >>> /etc/rc.conf), but nothing changed. >>> >>> I have to be doing something wrong, but I'm at a loss to know what it >>> is. I've rebuilt world and kernel nine times now, in the desparate >>> hope >>> that something might have changed in the usb code that would solve this >>> problem. (Every time "#find /usr/src -newer /boot/kernel" returns >>> changes in the usb code, I rebuild kernel and world.) >>> >>> Is there something I can enable that will capture the boot sequence >>> during a failed boot while devices are still being detected? >>> >>> # grep -i umass /var/log/console.log >>> >>> >>> Any helpful hints would be gratefully appreciated. >>> >>> # uname -a >>> FreeBSD utd65257.utdallas.edu 7.0-STABLE FreeBSD 7.0-STABLE #8: Mon Jul >>> 7 10:41:03 CDT 2008 >>> root@utd65257.utdallas.edu:/usr/obj/usr/src/sys/GENERIC i386 >>> >>> # sysctl -a | grep hw.physmem >>> hw.physmem: 3474407424 >>> >>> # dmesg | grep -i umass >>> umass0: >> 2> on uhub5 >>> da0 at umass-sim0 bus 0 target 0 lun 0 >>> >>> # grep swap /etc/fstab >>> /dev/ad8s1b none swap sw >>> 0 0 >>> >>> # swapctl -l >>> Device: 1024-blocks Used: >>> /dev/ad8s1b 8388608 0 >>> >>> # grep -i usb /var/run/dmesg.boot >>> uhci0: port 0xff20-0xff3f irq 16 at >>> device 26.0 on pci0 >>> usb0: on uhci0 >>> usb0: USB revision 1.0 >>> uhub0: on usb0 >>> uhci1: port 0xff00-0xff1f irq 17 at >>> device 26.1 on pci0 >>> usb1: on uhci1 >>> usb1: USB revision 1.0 >>> uhub1: on usb1 >>> ehci0: mem 0xfebd9c00-0xfebd9fff >>> irq >>> 22 at device 26.7 on pci0 >>> usb2: waiting for BIOS to give up control >>> usb2: EHCI version 1.0 >>> usb2: wrong number of companions (3 != 2) >>> usb2: companion controllers, 2 ports each: usb0 usb1 >>> usb2: on ehci0 >>> usb2: USB revision 2.0 >>> uhub2: on usb2 >>> ums0: on >>> uhub3 >>> uhci2: port 0xff80-0xff9f irq 23 at >>> device 29.0 on pci0 >>> usb3: on uhci2 >>> usb3: USB revision 1.0 >>> uhub4: on usb3 >>> uhci3: port 0xff60-0xff7f irq 17 at >>> device 29.1 on pci0 >>> usb4: on uhci3 >>> usb4: USB revision 1.0 >>> uhub5: on usb4 >>> uhci4: port 0xff40-0xff5f irq 18 at >>> device 29.2 on pci0 >>> usb5: on uhci4 >>> usb5: USB revision 1.0 >>> uhub6: on usb5 >>> ehci1: mem 0xff980800-0xff980bff >>> irq >>> 23 at device 29.7 on pci0 >>> usb6: waiting for BIOS to give up control >>> usb6: timed out waiting for BIOS >>> usb6: EHCI version 1.0 >>> usb6: companion controllers, 2 ports each: usb3 usb4 usb5 >>> usb6: on ehci1 >>> usb6: USB revision 2.0 >>> uhub7: on usb6 >>> >> >> It might be something else, but I had usb problems in 6-STABLE until I >> disabled usb support in the bios. FreeBSD still detects the usb >> hardware. In >> my case there was some sort of conflict between the usb detection of >> the bios >> and the detection FreeBSD. >> The symptoms where very weird, because it also depended on the >> connected usb >> devices on time of boot. Connecting theme after booting did work. >> > > Dell's BIOS has three options for the USB controller; off, on and no > umass device support. Off allows the box to boot properly, but I have > no keyboard. (Kind of not useful.) The other two manifest the same > problem. So this didn't solve the problem for me. > Does 'off' still let FreeBSD detect the usb controller? If so, this might point you in the right direction for pinpointing the reason of the problem. Ronald. From pschmehl_lists at tx.rr.com Thu Jul 10 20:58:23 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Thu Jul 10 20:58:30 2008 Subject: UMASS problem on 7.0 STABLE In-Reply-To: References: <94439F09F64DAEEE70087136@utd65257.utdallas.edu> Message-ID: <88ED49A127DF53BD47C26143@utd65257.utdallas.edu> --On Thursday, July 10, 2008 21:47:17 +0200 Ronald Klop wrote: > On Thu, 10 Jul 2008 17:31:51 +0200, Paul Schmehl > wrote: > >> --On Wednesday, July 09, 2008 11:50:25 +0200 Ronald Klop >> wrote: >> >>> On Tue, 08 Jul 2008 20:27:26 +0200, Paul Schmehl >>> >>> wrote: >>> >>>> Ever since I upgraded this workstation to 7.0 STABLE, I have been >>>> unable >>>> to reboot with my USB hard drive attached. During the boot sequence, >>>> the device is properly detected and identified, but then I get an error >>>> message, a crash dump and a reboot. I enabled /var/log/console.log in >>>> the hope that I would catch the error message, but it doesn't appear in >>>> the log. I also don't have any kernel dumps, so I can't trace those to >>>> see what the problem might be. >>>> >>>> An additional problem that I have is that, during boot, the system says >>>> there is no dump device available. This is despite the fact that swap >>>> is twice the real memory size and /etc/defaults/rc.conf defines dumpdev >>>> as auto. I even tried defining dumpdev as the swap partition (in >>>> /etc/rc.conf), but nothing changed. >>>> >>>> I have to be doing something wrong, but I'm at a loss to know what it >>>> is. I've rebuilt world and kernel nine times now, in the desparate >>>> hope >>>> that something might have changed in the usb code that would solve this >>>> problem. (Every time "#find /usr/src -newer /boot/kernel" returns >>>> changes in the usb code, I rebuild kernel and world.) >>>> >>>> Is there something I can enable that will capture the boot sequence >>>> during a failed boot while devices are still being detected? >>>> >>>> # grep -i umass /var/log/console.log >>>> >>>> >>>> Any helpful hints would be gratefully appreciated. >>>> >>>> # uname -a >>>> FreeBSD utd65257.utdallas.edu 7.0-STABLE FreeBSD 7.0-STABLE #8: Mon Jul >>>> 7 10:41:03 CDT 2008 >>>> root@utd65257.utdallas.edu:/usr/obj/usr/src/sys/GENERIC i386 >>>> >>>> # sysctl -a | grep hw.physmem >>>> hw.physmem: 3474407424 >>>> >>>> # dmesg | grep -i umass >>>> umass0: >>> 2> on uhub5 >>>> da0 at umass-sim0 bus 0 target 0 lun 0 >>>> >>>> # grep swap /etc/fstab >>>> /dev/ad8s1b none swap sw >>>> 0 0 >>>> >>>> # swapctl -l >>>> Device: 1024-blocks Used: >>>> /dev/ad8s1b 8388608 0 >>>> >>>> # grep -i usb /var/run/dmesg.boot >>>> uhci0: port 0xff20-0xff3f irq 16 at >>>> device 26.0 on pci0 >>>> usb0: on uhci0 >>>> usb0: USB revision 1.0 >>>> uhub0: on usb0 >>>> uhci1: port 0xff00-0xff1f irq 17 at >>>> device 26.1 on pci0 >>>> usb1: on uhci1 >>>> usb1: USB revision 1.0 >>>> uhub1: on usb1 >>>> ehci0: mem 0xfebd9c00-0xfebd9fff >>>> irq >>>> 22 at device 26.7 on pci0 >>>> usb2: waiting for BIOS to give up control >>>> usb2: EHCI version 1.0 >>>> usb2: wrong number of companions (3 != 2) >>>> usb2: companion controllers, 2 ports each: usb0 usb1 >>>> usb2: on ehci0 >>>> usb2: USB revision 2.0 >>>> uhub2: on usb2 >>>> ums0: on >>>> uhub3 >>>> uhci2: port 0xff80-0xff9f irq 23 at >>>> device 29.0 on pci0 >>>> usb3: on uhci2 >>>> usb3: USB revision 1.0 >>>> uhub4: on usb3 >>>> uhci3: port 0xff60-0xff7f irq 17 at >>>> device 29.1 on pci0 >>>> usb4: on uhci3 >>>> usb4: USB revision 1.0 >>>> uhub5: on usb4 >>>> uhci4: port 0xff40-0xff5f irq 18 at >>>> device 29.2 on pci0 >>>> usb5: on uhci4 >>>> usb5: USB revision 1.0 >>>> uhub6: on usb5 >>>> ehci1: mem 0xff980800-0xff980bff >>>> irq >>>> 23 at device 29.7 on pci0 >>>> usb6: waiting for BIOS to give up control >>>> usb6: timed out waiting for BIOS >>>> usb6: EHCI version 1.0 >>>> usb6: companion controllers, 2 ports each: usb3 usb4 usb5 >>>> usb6: on ehci1 >>>> usb6: USB revision 2.0 >>>> uhub7: on usb6 >>>> >>> >>> It might be something else, but I had usb problems in 6-STABLE until I >>> disabled usb support in the bios. FreeBSD still detects the usb >>> hardware. In >>> my case there was some sort of conflict between the usb detection of >>> the bios >>> and the detection FreeBSD. >>> The symptoms where very weird, because it also depended on the >>> connected usb >>> devices on time of boot. Connecting theme after booting did work. >>> >> >> Dell's BIOS has three options for the USB controller; off, on and no >> umass device support. Off allows the box to boot properly, but I have >> no keyboard. (Kind of not useful.) The other two manifest the same >> problem. So this didn't solve the problem for me. >> > > Does 'off' still let FreeBSD detect the usb controller? If so, this might > point you in the right direction for pinpointing the reason of the problem. > Unfortunately, no. When the USB Controller is disabled in the BIOS, I have no keyboard functionality at all in FreeBSD. -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. From unixmania at gmail.com Fri Jul 11 03:09:05 2008 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Fri Jul 11 03:09:12 2008 Subject: Looking for a GPT-aware boot manager Message-ID: Hello, I'm attempting quad-boot my notebook with STABLE and CURRENT, both i386 and AMD64. I installed them manually by booting from a thumb drive, partitioning the hard disk and extracting the distributions from ISO images that I had stored on an external hard drive. My disk layout is as follows: ad0p1 boot ad0p2 freebsd, partitioned with disklabel for 7.0/AMD64 ad0p2a 7.0 AMD64 root ad0p2d 7.0 AMD64 /var ad0p2f 7.0 AMD64 /usr ad0p3 freebsd, partitioned with disklabel for 7.0/i386 ad0p3a 7.0 i386 root ad0p3d 7.0 i386 /var ad0p3f 7.0 i386 /usr ad0p4 freebsd, partitioned with disklabel for 7.0/AMD64 ad0p4a 8.0 AMD64 root ad0p4d 8.0 AMD64 /var ad0p4f 8.0 AMD64 /usr ad0p5 freebsd, partitioned with disklabel for 7.0/AMD64 ad0p5a 8.0 i386 root ad0p5d 8.0 i386 /var ad0p5f 8.0 i386 /usr ad0p6 freebsd, partitioned with disklabel for all ad0p6b swap ad0p6d /temp ad0p6e /local The problem now is that I don't have a boot manager capable of selecting a partition to boot from. The FreeBSD boot manager (boot0) does not recognize GPT. I atempted to pass "0:ad(0p3)/boot/loader" to gptboot but had no success. I did a lot of googling and even attempted to read the source code of gptboot but could not figure out how to solve the problem, so any help will be appreciated. -- If you think things can't get worse it's probably only because you lack sufficient imagination. From peter at wemm.org Fri Jul 11 03:35:34 2008 From: peter at wemm.org (Peter Wemm) Date: Fri Jul 11 03:36:03 2008 Subject: Looking for a GPT-aware boot manager In-Reply-To: References: Message-ID: On Thu, Jul 10, 2008 at 8:09 PM, Carlos A. M. dos Santos wrote: > Hello, > > I'm attempting quad-boot my notebook with STABLE and CURRENT, both > i386 and AMD64. I installed them manually by booting from a thumb > drive, partitioning the hard disk and extracting the distributions > from ISO images that I had stored on an external hard drive. My disk > layout is as follows: > > ad0p1 boot > ad0p2 freebsd, partitioned with disklabel for 7.0/AMD64 > ad0p2a 7.0 AMD64 root > ad0p2d 7.0 AMD64 /var > ad0p2f 7.0 AMD64 /usr > ad0p3 freebsd, partitioned with disklabel for 7.0/i386 > ad0p3a 7.0 i386 root > ad0p3d 7.0 i386 /var > ad0p3f 7.0 i386 /usr > ad0p4 freebsd, partitioned with disklabel for 7.0/AMD64 > ad0p4a 8.0 AMD64 root > ad0p4d 8.0 AMD64 /var > ad0p4f 8.0 AMD64 /usr > ad0p5 freebsd, partitioned with disklabel for 7.0/AMD64 > ad0p5a 8.0 i386 root > ad0p5d 8.0 i386 /var > ad0p5f 8.0 i386 /usr > ad0p6 freebsd, partitioned with disklabel for all > ad0p6b swap > ad0p6d /temp > ad0p6e /local > > The problem now is that I don't have a boot manager capable of > selecting a partition to boot from. The FreeBSD boot manager (boot0) > does not recognize GPT. I atempted to pass "0:ad(0p3)/boot/loader" to > gptboot but had no success. > > I did a lot of googling and even attempted to read the source code of > gptboot but could not figure out how to solve the problem, so any help > will be appreciated. I think your biggest mistake was putting a disklabel inside a gpt partition. You've kind of missed the point of gpt. There are 16,000 partitions so that we don't have to deal with nested partition tables. Even loader doesn't handle this scenario. It understands the mbr/disklabel style disk0s1a, disk0s1, as well as gpt style disk0p1, but not gpt+disklabel disk0p1a. If it wasn't for that, you could do a simple menu in the loader scripts that did something like: set currdev=disk0p3: boot kernel .. to select the root partition that you wanted. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From peter at wemm.org Fri Jul 11 03:38:06 2008 From: peter at wemm.org (Peter Wemm) Date: Fri Jul 11 03:38:13 2008 Subject: Looking for a GPT-aware boot manager In-Reply-To: References: Message-ID: On Thu, Jul 10, 2008 at 8:35 PM, Peter Wemm wrote: > On Thu, Jul 10, 2008 at 8:09 PM, Carlos A. M. dos Santos > wrote: >> Hello, >> >> I'm attempting quad-boot my notebook with STABLE and CURRENT, both >> i386 and AMD64. I installed them manually by booting from a thumb >> drive, partitioning the hard disk and extracting the distributions >> from ISO images that I had stored on an external hard drive. My disk >> layout is as follows: >> >> ad0p1 boot >> ad0p2 freebsd, partitioned with disklabel for 7.0/AMD64 >> ad0p2a 7.0 AMD64 root >> ad0p2d 7.0 AMD64 /var >> ad0p2f 7.0 AMD64 /usr >> ad0p3 freebsd, partitioned with disklabel for 7.0/i386 >> ad0p3a 7.0 i386 root >> ad0p3d 7.0 i386 /var >> ad0p3f 7.0 i386 /usr >> ad0p4 freebsd, partitioned with disklabel for 7.0/AMD64 >> ad0p4a 8.0 AMD64 root >> ad0p4d 8.0 AMD64 /var >> ad0p4f 8.0 AMD64 /usr >> ad0p5 freebsd, partitioned with disklabel for 7.0/AMD64 >> ad0p5a 8.0 i386 root >> ad0p5d 8.0 i386 /var >> ad0p5f 8.0 i386 /usr >> ad0p6 freebsd, partitioned with disklabel for all >> ad0p6b swap >> ad0p6d /temp >> ad0p6e /local >> >> The problem now is that I don't have a boot manager capable of >> selecting a partition to boot from. The FreeBSD boot manager (boot0) >> does not recognize GPT. I atempted to pass "0:ad(0p3)/boot/loader" to >> gptboot but had no success. >> >> I did a lot of googling and even attempted to read the source code of >> gptboot but could not figure out how to solve the problem, so any help >> will be appreciated. > > I think your biggest mistake was putting a disklabel inside a gpt > partition. You've kind of missed the point of gpt. There are 16,000 > partitions so that we don't have to deal with nested partition tables. > > Even loader doesn't handle this scenario. It understands the > mbr/disklabel style disk0s1a, disk0s1, as well as gpt style disk0p1, > but not gpt+disklabel disk0p1a. > > If it wasn't for that, you could do a simple menu in the loader > scripts that did something like: > set currdev=disk0p3: > boot kernel > .. to select the root partition that you wanted. I forgot to mention.. You can use the same loader for all of these. We use an identical loader for i386 and amd64. The 8.0 loader is functionally identical to 7.0 as well. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From Willy at Offermans.Rompen.nl Fri Jul 11 06:44:14 2008 From: Willy at Offermans.Rompen.nl (Willy Offermans) Date: Fri Jul 11 06:44:21 2008 Subject: dhclient and resolv.conf.sav In-Reply-To: <20080710165741.GA12966@lor.one-eyed-alien.net> References: <20080710085234.GD38495@hugo10.ka.punkt.de> <20080710165741.GA12966@lor.one-eyed-alien.net> Message-ID: <20080711063249.GB4382@wiz.vpn.offrom.nl> Dear FreeBSD friends, Is this behavior, related to dhclient and /etc/resolv.conf.sav, FreeBSD specific or is it a general feature of dhclient? I might have a use for it on my debian linux laptop. On Thu, Jul 10, 2008 at 11:57:41AM -0500, Brooks Davis wrote: > On Thu, Jul 10, 2008 at 10:52:35AM +0200, Patrick M. Hausen wrote: > > Hello, > > > > we have been bitten by something that obvoiusly > > is a feature, not a bug, but I do not quite understand > > the intentions and reasoning behind it. > > > > I have a host with manual interface and resolver configuration > > and an additional interface that should get it's IP address > > via DHCP. But only it's IP address and netmask, nothing else. > > > > The DHCP server used hands out only IP addresses/netmasks, > > no domain-name-servers, domain-name, etc. configured. > > > > Yet, if there happens to exist a /etc/resolv.conf.sav file, > > every renewal of the lease by dhclient overwrites the contents > > of /etc/resolv.conf with those of resolv.conf.sav. > > > > In my particular case the .sav file contained an internal > > nameserver that was used when I initially set up the host > > in the lab. This entry was of no use to the server after > > it had been deployed in our datacenter. > > > > Can anyone shed some light on the intended mechanism? > > Studying the dhclient-script was not too helpful, either. > > I suspect the theory is that you can have a static resolv.conf around > that gets installed when there isn't anything else to use. In practice, > I think it mostly causes problems. I'm somewhat tempted to remove the > creation of the file and add something like a resolv.conf.default in > it's place. > > -- Brooks -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Willy ************************************* Dr. W.K. Offermans CAT Postdoctoral Fellow CAT Catalytic Center Institut f?r Technische und Makromolekulare Chemie RWTH Aachen Worringerweg 1, Raum 38C-150 D-52074 Aachen, Germany Phone: +49 241 80 28592 Home: +31 45 544 49 44 Mobile: +31 653 27 16 23 e-mail: Willy@Offermans.Rompen.nl e-mail: Willy.Offermans@CatalyticCenter.RWTH-Aachen.de Powered by .... (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org From hostmaster at netconsonance.com Fri Jul 11 08:24:31 2008 From: hostmaster at netconsonance.com (Jo Rhett) Date: Fri Jul 11 08:24:38 2008 Subject: how to get more logging from GEOM? Message-ID: About 10 days ago one of my personal machines started hanging at random. This is the first bit of instability I've ever experienced on this machine (2+ years running) FreeBSD triceratops.netconsonance.com 6.2-RELEASE-p11 FreeBSD 6.2- RELEASE-p11 #0: Wed Feb 13 06:44:57 UTC 2008 root@i386-builder.daemonology.net :/usr/obj/usr/src/sys/GENERIC i386 After about 2 weeks of watching it carefully I've learned almost nothing. It's not a disk failure (AFAIK) it's not cpu overheat (now running healthd without complaints) it's not based on any given network traffic... however it does appear to accompany heavy cpu/disk activity. It usually dies when indexing my websites at night (but not always) and it sometimes dies when compiling programs. Just heavy disk isn't enough to do the job, as backups proceed without problems. Heavy cpu by itself isn't enough to do it either. But if I start compiling things and keep going a while, it will eventually hang. My best guess is that geom is having a problem and locking up. There's no log entry before failure to back this idea up, but I think this because during boot I see the following: ad0: 286168MB at ata0-master UDMA100 GEOM_MIRROR: Device gm0 created (id=575427344). GEOM_MIRROR: Device gm0: provider ad0 detected. ad1: 286168MB at ata0-slave UDMA100 GEOM_MIRROR: Device gm0: provider ad1 detected. GEOM_MIRROR: Device gm0: provider ad1 activated. GEOM_MIRROR: Device gm0: provider mirror/gm0 launched. GEOM_MIRROR: Device gm0: rebuilding provider ad0. Every time it is rebuilding ad0. Every single boot in the last two weeks. Is this any way to get more logging from geom, to confirm or deny this theory? Is there anything else I should be looking at? FWIW, this never happened before the p11 patch to 6.2. I don't know if that is related or not. Obviously, I can't upgrade to 6.3 if heavy cpu/disk activity kills the system. No, I don't have any other insights. I'm not prone to posting "duh help me please!" posts, so I'm quite a bit frustrated by this one. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jhary at unsane.co.uk Fri Jul 11 09:59:23 2008 From: jhary at unsane.co.uk (Vince Hoffman) Date: Fri Jul 11 09:59:29 2008 Subject: how to get more logging from GEOM? In-Reply-To: References: Message-ID: <48772EE5.2060401@unsane.co.uk> Jo Rhett wrote: > About 10 days ago one of my personal machines started hanging at > random. This is the first bit of instability I've ever experienced on > this machine (2+ years running) > > FreeBSD triceratops.netconsonance.com 6.2-RELEASE-p11 FreeBSD > 6.2-RELEASE-p11 #0: Wed Feb 13 06:44:57 UTC 2008 > root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 > > After about 2 weeks of watching it carefully I've learned almost > nothing. It's not a disk failure (AFAIK) it's not cpu overheat (now > running healthd without complaints) it's not based on any given network > traffic... however it does appear to accompany heavy cpu/disk > activity. It usually dies when indexing my websites at night (but not > always) and it sometimes dies when compiling programs. Just heavy disk > isn't enough to do the job, as backups proceed without problems. Heavy > cpu by itself isn't enough to do it either. But if I start compiling > things and keep going a while, it will eventually hang. > > My best guess is that geom is having a problem and locking up. There's > no log entry before failure to back this idea up, but I think this > because during boot I see the following: > > ad0: 286168MB at ata0-master UDMA100 > GEOM_MIRROR: Device gm0 created (id=575427344). > GEOM_MIRROR: Device gm0: provider ad0 detected. > ad1: 286168MB at ata0-slave UDMA100 > GEOM_MIRROR: Device gm0: provider ad1 detected. > GEOM_MIRROR: Device gm0: provider ad1 activated. > GEOM_MIRROR: Device gm0: provider mirror/gm0 launched. > GEOM_MIRROR: Device gm0: rebuilding provider ad0. > > Every time it is rebuilding ad0. Every single boot in the last two weeks. > > Is this any way to get more logging from geom, to confirm or deny this > theory? Just a guess but try kern.geom.debugflags > 0 This certainly spews out far more geom info, as to how helpful this will be... Vince > > Is there anything else I should be looking at? > > FWIW, this never happened before the p11 patch to 6.2. I don't know if > that is related or not. > > Obviously, I can't upgrade to 6.3 if heavy cpu/disk activity kills the > system. > > No, I don't have any other insights. I'm not prone to posting "duh help > me please!" posts, so I'm quite a bit frustrated by this one. > From maxim at macomnet.ru Fri Jul 11 10:43:28 2008 From: maxim at macomnet.ru (Maxim Konovalov) Date: Fri Jul 11 10:43:37 2008 Subject: cvsup server reachable via IPv6... In-Reply-To: <1215119650.75067.10.camel@neo.cse.buffalo.edu> References: <1215119650.75067.10.camel@neo.cse.buffalo.edu> Message-ID: <20080711141217.B19592@mp2.macomnet.net> On Thu, 3 Jul 2008, 17:14-0400, Ken Smith wrote: > > If any of you have been wishing there was an IPv6-capable cvsup server > you could use (with csup as the client obviously since cvsup doesn't do > IPv6...) give cvsup18.freebsd.org a try. With the help of a few other > folks I got nudged into giving inetd/netcat a try as a means to feed > IPv6 connections to the cvsupd server process. > > If you try it and have problems let me know. cvsup18 is my "little > server" (handles between 200 and 300 connects a day) but if this seems > to work OK I can give it a try on my "big server" (handles between 3000 > and 4000 connects a day...). > FWIW, we already running ipv6 cvsup server at cvsup4.ru.freebsd.org. -- Maxim Konovalov From ronald-freebsd8 at klop.yi.org Fri Jul 11 11:48:39 2008 From: ronald-freebsd8 at klop.yi.org (Ronald Klop) Date: Fri Jul 11 11:48:52 2008 Subject: how to get more logging from GEOM? In-Reply-To: References: Message-ID: On Fri, 11 Jul 2008 09:59:33 +0200, Jo Rhett wrote: > About 10 days ago one of my personal machines started hanging at > random. This is the first bit of instability I've ever experienced on > this machine (2+ years running) > > FreeBSD triceratops.netconsonance.com 6.2-RELEASE-p11 FreeBSD 6.2- > RELEASE-p11 #0: Wed Feb 13 06:44:57 UTC 2008 > root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 > > After about 2 weeks of watching it carefully I've learned almost > nothing. It's not a disk failure (AFAIK) it's not cpu overheat (now > running healthd without complaints) it's not based on any given network > traffic... however it does appear to accompany heavy cpu/disk > activity. It usually dies when indexing my websites at night (but not > always) and it sometimes dies when compiling programs. Just heavy disk > isn't enough to do the job, as backups proceed without problems. Heavy > cpu by itself isn't enough to do it either. But if I start compiling > things and keep going a while, it will eventually hang. > > My best guess is that geom is having a problem and locking up. There's > no log entry before failure to back this idea up, but I think this > because during boot I see the following: > > ad0: 286168MB at ata0-master UDMA100 > GEOM_MIRROR: Device gm0 created (id=575427344). > GEOM_MIRROR: Device gm0: provider ad0 detected. > ad1: 286168MB at ata0-slave UDMA100 > GEOM_MIRROR: Device gm0: provider ad1 detected. > GEOM_MIRROR: Device gm0: provider ad1 activated. > GEOM_MIRROR: Device gm0: provider mirror/gm0 launched. > GEOM_MIRROR: Device gm0: rebuilding provider ad0. > > Every time it is rebuilding ad0. Every single boot in the last two > weeks. > > Is this any way to get more logging from geom, to confirm or deny this > theory? > > Is there anything else I should be looking at? > > FWIW, this never happened before the p11 patch to 6.2. I don't know if > that is related or not. > > Obviously, I can't upgrade to 6.3 if heavy cpu/disk activity kills the > system. > > No, I don't have any other insights. I'm not prone to posting "duh help > me please!" posts, so I'm quite a bit frustrated by this one. You can try going into the kernel debugger to see where it is hanging. Debugging via a serial cable is also very easy. I don't know the details, but there is a lot of info in the Freebsd handbook. Put this in google 'freebsd handbook kernel debug'. Ronald. From brooks at freebsd.org Fri Jul 11 15:17:20 2008 From: brooks at freebsd.org (Brooks Davis) Date: Fri Jul 11 15:17:31 2008 Subject: dhclient and resolv.conf.sav In-Reply-To: <20080711063249.GB4382@wiz.vpn.offrom.nl> References: <20080710085234.GD38495@hugo10.ka.punkt.de> <20080710165741.GA12966@lor.one-eyed-alien.net> <20080711063249.GB4382@wiz.vpn.offrom.nl> Message-ID: <20080711145550.GB12966@lor.one-eyed-alien.net> On Fri, Jul 11, 2008 at 08:32:49AM +0200, Willy Offermans wrote: > Dear FreeBSD friends, > > Is this behavior, related to dhclient and /etc/resolv.conf.sav, FreeBSD > specific or is it a general feature of dhclient? I might have a use for > it on my debian linux laptop. We picked it up from openbsd when we took their client (which is derived from an early ISC client). If it's not in the stock isc dhclient-script adding it would be trivial. -- Brooks > On Thu, Jul 10, 2008 at 11:57:41AM -0500, Brooks Davis wrote: > > On Thu, Jul 10, 2008 at 10:52:35AM +0200, Patrick M. Hausen wrote: > > > Hello, > > > > > > we have been bitten by something that obvoiusly > > > is a feature, not a bug, but I do not quite understand > > > the intentions and reasoning behind it. > > > > > > I have a host with manual interface and resolver configuration > > > and an additional interface that should get it's IP address > > > via DHCP. But only it's IP address and netmask, nothing else. > > > > > > The DHCP server used hands out only IP addresses/netmasks, > > > no domain-name-servers, domain-name, etc. configured. > > > > > > Yet, if there happens to exist a /etc/resolv.conf.sav file, > > > every renewal of the lease by dhclient overwrites the contents > > > of /etc/resolv.conf with those of resolv.conf.sav. > > > > > > In my particular case the .sav file contained an internal > > > nameserver that was used when I initially set up the host > > > in the lab. This entry was of no use to the server after > > > it had been deployed in our datacenter. > > > > > > Can anyone shed some light on the intended mechanism? > > > Studying the dhclient-script was not too helpful, either. > > > > I suspect the theory is that you can have a static resolv.conf around > > that gets installed when there isn't anything else to use. In practice, > > I think it mostly causes problems. I'm somewhat tempted to remove the > > creation of the file and add something like a resolv.conf.default in > > it's place. > > > > -- Brooks > > > > -- > Met vriendelijke groeten, > With kind regards, > Mit freundlichen Gruessen, > De jrus wah, > > Willy > > ************************************* > Dr. W.K. Offermans > CAT Postdoctoral Fellow > CAT Catalytic Center > Institut f?r Technische und Makromolekulare Chemie > RWTH Aachen > Worringerweg 1, Raum 38C-150 > D-52074 Aachen, Germany > Phone: +49 241 80 28592 > Home: +31 45 544 49 44 > Mobile: +31 653 27 16 23 > e-mail: Willy@Offermans.Rompen.nl > e-mail: Willy.Offermans@CatalyticCenter.RWTH-Aachen.de > > Powered by .... > > (__) > \\\'',) > \/ \ ^ > .\._/_) > > www.FreeBSD.org > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080711/6c6f04b5/attachment.pgp From rsmith at xs4all.nl Fri Jul 11 16:17:45 2008 From: rsmith at xs4all.nl (Roland Smith) Date: Fri Jul 11 16:17:52 2008 Subject: how to get more logging from GEOM? In-Reply-To: References: Message-ID: <20080711155831.GA72963@slackbox.xs4all.nl> On Fri, Jul 11, 2008 at 12:59:33AM -0700, Jo Rhett wrote: > About 10 days ago one of my personal machines started hanging at > random. This is the first bit of instability I've ever experienced on > this machine (2+ years running) > > FreeBSD triceratops.netconsonance.com 6.2-RELEASE-p11 FreeBSD 6.2- > RELEASE-p11 #0: Wed Feb 13 06:44:57 UTC 2008 root@i386-builder.daemonology.net > :/usr/obj/usr/src/sys/GENERIC i386 > > After about 2 weeks of watching it carefully I've learned almost > nothing. It's not a disk failure (AFAIK) it's not cpu overheat (now > running healthd without complaints) it's not based on any given > network traffic... however it does appear to accompany heavy cpu/disk > activity. It usually dies when indexing my websites at night (but not > always) and it sometimes dies when compiling programs. Just heavy > disk isn't enough to do the job, as backups proceed without > problems. Heavy cpu by itself isn't enough to do it either. But if > I start compiling things and keep going a while, it will eventually > hang. > Is there anything else I should be looking at? Power supply or motherboard would be my first guess. 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) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080711/be841f48/attachment.pgp From cliftonr at lava.net Fri Jul 11 16:49:42 2008 From: cliftonr at lava.net (Clifton Royston) Date: Fri Jul 11 16:49:48 2008 Subject: how to get more logging from GEOM? In-Reply-To: References: Message-ID: <20080711164939.GA10238@lava.net> On Fri, Jul 11, 2008 at 12:59:33AM -0700, Jo Rhett wrote: > My best guess is that geom is having a problem and locking up. > There's no log entry before failure to back this idea up, but I think > this because during boot I see the following: > > ad0: 286168MB at ata0-master UDMA100 > GEOM_MIRROR: Device gm0 created (id=575427344). > GEOM_MIRROR: Device gm0: provider ad0 detected. > ad1: 286168MB at ata0-slave UDMA100 > GEOM_MIRROR: Device gm0: provider ad1 detected. > GEOM_MIRROR: Device gm0: provider ad1 activated. > GEOM_MIRROR: Device gm0: provider mirror/gm0 launched. > GEOM_MIRROR: Device gm0: rebuilding provider ad0. > > Every time it is rebuilding ad0. Every single boot in the last two > weeks. That just means that it halted without a proper shutdown. If it crashes, the mirror isn't stopped properly, so it's marked dirty, so it must rebuild it. It is the precise analogy of finding all the file systems dirty on boot and fscking them, following a crash. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From nakal at web.de Fri Jul 11 18:39:14 2008 From: nakal at web.de (Martin) Date: Fri Jul 11 18:39:43 2008 Subject: panic: clist reservation botch Message-ID: <20080711203910.4951d81b@web.de> Hi, I just had a panic (again, but this time a completely new one) with -STABLE system: FreeBSD 7.0-STABLE #0: Thu Jun 19 10:44:38 CEST 2008 I could not get much information, because the debugger did not work at all. Every time I pressed a key, I got a screen full of backtrace output. It was impossible to type a command. This is what information I could get: Panic was called "clist reservation botch". Occured on shutdown after installing a new kernel. The notebook was running quite long (about 1 day). Here is the part of trace dump, I could read: free_cblocks clist_free_cblocks tty_close scclose giant_close devfs_close VOP_CLOSE_APV vn_close vn_closefile devfs_close_f fdrop closef fdfree exit1 postsig postsig ast doreti_ast There also were some parameters in hex, of course, but I did not have the patience to write them down, sorry. -- Martin Sugioarto From oberman at es.net Fri Jul 11 21:47:03 2008 From: oberman at es.net (Kevin Oberman) Date: Fri Jul 11 21:47:50 2008 Subject: [freebsd-stable] Re: BIND update? In-Reply-To: Your message of "Thu, 10 Jul 2008 10:03:24 EDT." <200807101403.m6AE3OIl095039@himinbjorg.tucs-beachin-obx-house.com> Message-ID: <20080711214701.72FEA4500E@ptavv.es.net> > From: "Tuc at T-B-O-H.NET" > Date: Thu, 10 Jul 2008 10:03:24 -0400 (EDT) > Sender: owner-freebsd-stable@freebsd.org > > > > > On Thu, Jul 10, 2008 at 12:25:33PM +0200, Oliver Brandmueller wrote: > > > OK, thanx for clarification. I totally overlooked the updated bind port; > > > anyhow, I use base system bind and didn't plan to change that (although > > > it might me a good idea, as this situation clearly shows). > > > > You can always use the WITH_REPLACE_BASE option in the port to > > overwrite the base system named, or use the differences in the > > extracted tarball of 9.5.0 vs 9.5.0-P1 to update the source of the > > base one yourself. > > > Shouldn't you also add : > > NO_BIND= true # do not build BIND > > into /etc/make.conf if you do, so it doesn't get clobbered? Or, for V7, add : WITHOUT_BIND=1 to /etc/src.conf. And this assumes that you will be re-building the system before the base system is patched. Note that this will also cause mergemaster to ask about deleting /etc/rc.d/named. Just say 'no'! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080711/614acaf5/attachment.pgp From alex.kovalenko at verizon.net Sat Jul 12 02:08:19 2008 From: alex.kovalenko at verizon.net (Alexandre "Sunny" Kovalenko) Date: Sat Jul 12 02:08:26 2008 Subject: Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7 In-Reply-To: <482DB4FE.3010300@freebsd.org> References: <1210640542.1008.33.camel@RabbitsDen> <4828FDE5.8090409@freebsd.org> <1210696676.985.18.camel@RabbitsDen> <482DB4FE.3010300@freebsd.org> Message-ID: <1215824846.1074.23.camel@RabbitsDen> On Fri, 2008-05-16 at 12:23 -0400, Sam Leffler wrote: > Alexandre "Sunny" Kovalenko wrote: > > On Mon, 2008-05-12 at 19:33 -0700, Sam Leffler wrote: > >> Alexandre "Sunny" Kovalenko wrote: > >>> I seem to be able to lock my machine by going into wpa_cli and asking it > >>> to 'reassoc'. The reason for question mark after "hard" is that debug > >>> information (caused by wlandebug and athdebug) is being printed on the > >>> console. The only way to get machine's attention is to hold power button > >>> for 8 seconds. > >> So this is just livelock due to console debug msgs. > > I am not sure, I have parsed this well enough, so I will try to clarify: > > machine becomes unresponsive *without* any debugging turned on, to an > > extent that pressing the power button twice *does not* generate ACPI > > console message (something to the tune of "going into S5 already -- > > gimme a break"). If I turn ath debugging on, I do see those messages, > > and only them, scrolling on the console. > > Guess I misunderstood you. I have finally got enough time and equipment to investigate this further. Here are some conclusions: -- at this point (RELENG_7 as of July 9th around 15:30 EST) it is indeed a livelock. -- all system does, is executing ath_intr (if_ath.c) in the tight loop with the same status -- 0x1000 AKA HAL_INT_MIB. In order to eliminate possibility that I have caused livelock with the debug messages, I have put conditional panic() into ath_intr, as soon as sc->sc_stats.ast_mib reaches 10,000. Without any kind of the debug messages, it will be triggered within 40-60 seconds after starting of wpa_supplicant. -- I suspect that comment below, might not hold true on my equipment if (status & HAL_INT_MIB) { sc->sc_stats.ast_mib++; /* * Disable interrupts until we service the MIB * interrupt; otherwise it will continue to fire. */ ath_hal_intrset(ah, 0); /* * Let the hal handle the event. We assume it will <============ * clear whatever condition caused the interrupt. <============ */ ath_hal_mibevent(ah, &sc->sc_halstats); ath_hal_intrset(ah, sc->sc_imask); } My hardware is: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: mem 0xedf00000-0xedf0ffff irq 17 at device 0.0 on pci3 ath0: [ITHREAD] ath0: using obsoleted if_watchdog interface ath0: Ethernet address: 00:16:cf:26:2f:3f ath0: mac 10.3 phy 6.1 radio 10.2 My wpa_supplicant.conf is: ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel eapol_version=2 network={ ssid="XXXXXXXXXXX" scan_ssid=1 priority=1 proto=WPA pairwise=TKIP group=TKIP key_mgmt=WPA-PSK psk="xxxxxxxxxxxxxxxxxxxxxx" } Access point is Netgear WNDR3300-1B with 11N and 11G SSID set up to different values. Only 11G SSID is configured in wpa_supplicant.conf. In the test setup, AP is with 10' (3m) from the laptop. AP is successfully used by handful of Windows clients (including this same laptop) and iBook G4. Neither wpa_supplicant with '-d -d' nor wlandebug 0xFFFFFFFF show anything but normal scan. athdebug 0xFFFFFFFF loops with ath_intr: status 0x1000 until I power down my laptop. I would appreciate any suggestion on what I can investigate further -- at this point I have comfortable console setup and should be able to field requests for further information much better. -- Alexandre "Sunny" Kovalenko (????????? ?????????) From sam at freebsd.org Sat Jul 12 03:42:09 2008 From: sam at freebsd.org (Sam Leffler) Date: Sat Jul 12 03:42:16 2008 Subject: Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7 In-Reply-To: <1215824846.1074.23.camel@RabbitsDen> References: <1210640542.1008.33.camel@RabbitsDen> <4828FDE5.8090409@freebsd.org> <1210696676.985.18.camel@RabbitsDen> <482DB4FE.3010300@freebsd.org> <1215824846.1074.23.camel@RabbitsDen> Message-ID: <4878250E.8040205@freebsd.org> Alexandre "Sunny" Kovalenko wrote: > On Fri, 2008-05-16 at 12:23 -0400, Sam Leffler wrote: >> Alexandre "Sunny" Kovalenko wrote: >>> On Mon, 2008-05-12 at 19:33 -0700, Sam Leffler wrote: >>>> Alexandre "Sunny" Kovalenko wrote: >>>>> I seem to be able to lock my machine by going into wpa_cli and asking it >>>>> to 'reassoc'. The reason for question mark after "hard" is that debug >>>>> information (caused by wlandebug and athdebug) is being printed on the >>>>> console. The only way to get machine's attention is to hold power button >>>>> for 8 seconds. >>>> So this is just livelock due to console debug msgs. >>> I am not sure, I have parsed this well enough, so I will try to clarify: >>> machine becomes unresponsive *without* any debugging turned on, to an >>> extent that pressing the power button twice *does not* generate ACPI >>> console message (something to the tune of "going into S5 already -- >>> gimme a break"). If I turn ath debugging on, I do see those messages, >>> and only them, scrolling on the console. >> Guess I misunderstood you. > > I have finally got enough time and equipment to investigate this > further. Here are some conclusions: > > -- at this point (RELENG_7 as of July 9th around 15:30 EST) it is indeed > a livelock. > > -- all system does, is executing ath_intr (if_ath.c) in the tight loop > with the same status -- 0x1000 AKA HAL_INT_MIB. In order to eliminate > possibility that I have caused livelock with the debug messages, I have > put conditional panic() into ath_intr, as soon as sc->sc_stats.ast_mib > reaches 10,000. Without any kind of the debug messages, it will be > triggered within 40-60 seconds after starting of wpa_supplicant. > > -- I suspect that comment below, might not hold true on my equipment > if (status & HAL_INT_MIB) { > sc->sc_stats.ast_mib++; > /* > * Disable interrupts until we service the MIB > * interrupt; otherwise it will continue to fire. > */ > ath_hal_intrset(ah, 0); > /* > * Let the hal handle the event. We assume it will <============ > * clear whatever condition caused the interrupt. <============ > */ > ath_hal_mibevent(ah, &sc->sc_halstats); > ath_hal_intrset(ah, sc->sc_imask); > } > > My hardware is: > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, > RF5413) > ath0: mem 0xedf00000-0xedf0ffff irq 17 at device 0.0 on > pci3 > ath0: [ITHREAD] > ath0: using obsoleted if_watchdog interface > ath0: Ethernet address: 00:16:cf:26:2f:3f > ath0: mac 10.3 phy 6.1 radio 10.2 > > My wpa_supplicant.conf is: > ctrl_interface=/var/run/wpa_supplicant > ctrl_interface_group=wheel > eapol_version=2 > > network={ > ssid="XXXXXXXXXXX" > scan_ssid=1 > priority=1 > proto=WPA > pairwise=TKIP > group=TKIP > key_mgmt=WPA-PSK > psk="xxxxxxxxxxxxxxxxxxxxxx" > } > > Access point is Netgear WNDR3300-1B with 11N and 11G SSID set up to > different values. Only 11G SSID is configured in wpa_supplicant.conf. In > the test setup, AP is with 10' (3m) from the laptop. > > AP is successfully used by handful of Windows clients (including this > same laptop) and iBook G4. > > Neither wpa_supplicant with '-d -d' nor wlandebug 0xFFFFFFFF show > anything but normal scan. > > athdebug 0xFFFFFFFF loops with ath_intr: status 0x1000 until I power > down my laptop. > > I would appreciate any suggestion on what I can investigate further -- > at this point I have comfortable console setup and should be able to > field requests for further information much better. > Are you running powerd? Sam From roar.pettersen at uib.no Sat Jul 12 09:08:41 2008 From: roar.pettersen at uib.no (Roar Pettersen) Date: Sat Jul 12 09:08:49 2008 Subject: FreeBSD-6.3 (amd64) mergemaster problem Message-ID: Hello ! Trying to upgrade my FreeBSD-6.3-Stable (amd64) to FreeBSD-7.0-stable (amd64), and after I have csup'ed the source and execute a "mergemaster -i" then this error message occur : # mergemaster -i *** The directory specified for the temporary root environment, /var/tmp/temproot, exists. This can be a security risk if untrusted users have access to the system. Use 'd' to delete the old /var/tmp/temproot and continue Use 't' to select a new temporary root directory Use 'e' to exit mergemaster Default is to use /var/tmp/temproot as is How should I deal with this? [Use the existing /var/tmp/temproot] d *** Deleting the old /var/tmp/temproot *** Creating the temporary root environment in /var/tmp/temproot *** /var/tmp/temproot ready for use *** Creating and populating directory structure in /var/tmp/temproot "Makefile", line 6: Malformed conditional (${MK_SENDMAIL} != "no") "Makefile", line 8: if-less endif "Makefile", line 35: Malformed conditional (${MK_LPR} != "no") "Makefile", line 37: if-less endif "Makefile", line 39: Malformed conditional (${MK_NS_CACHING} != "no") "Makefile", line 41: if-less endif "Makefile", line 43: Malformed conditional (${MK_OPENSSH} != "no") "Makefile", line 47: if-less endif "Makefile", line 48: Malformed conditional (${MK_OPENSSL} != "no") "Makefile", line 50: if-less endif "Makefile", line 57: Malformed conditional (${MK_SENDMAIL} != "no") "Makefile", line 59: if-less endif "Makefile", line 60: Malformed conditional (${MK_BIND} != "no") "Makefile", line 62: Malformed conditional (${MK_BIND_LIBS} != "no") "Makefile", line 64: if-less endif "Makefile", line 65: if-less endif "Makefile", line 69: Malformed conditional (${MK_SENDMAIL} == "no") "Makefile", line 71: if-less else "Makefile", line 74: if-less endif "Makefile", line 80: Malformed conditional (${MK_MAN} != "no") "Makefile", line 82: if-less endif "Makefile", line 130: Malformed conditional (${MK_I4B} != "no") "Makefile", line 132: if-less endif "Makefile", line 133: Malformed conditional (${MK_BIND_MTREE} != "no") "Makefile", line 138: if-less endif "Makefile", line 139: Malformed conditional (${MK_BIND_ETC} != "no") "Makefile", line 141: if-less endif "Makefile", line 142: Malformed conditional (${MK_SENDMAIL} != "no") "Makefile", line 144: if-less endif "Makefile", line 145: Malformed conditional (${MK_OPENSSH} != "no") "Makefile", line 148: if-less endif "Makefile", line 149: Malformed conditional (${MK_OPENSSL} != "no") "Makefile", line 152: if-less endif "Makefile", line 153: Malformed conditional (${MK_KERBEROS} != "no") "Makefile", line 157: if-less endif "Makefile", line 199: Malformed conditional (${MK_BIND_LIBS} != "no") "Makefile", line 202: if-less endif "Makefile", line 203: Malformed conditional (${MK_BIND_MTREE} != "no") "Makefile", line 206: if-less endif "Makefile", line 207: Malformed conditional (${MK_SENDMAIL} != "no") "Makefile", line 209: if-less endif make: fatal errors encountered -- cannot continue *** FATAL ERROR: Cannot 'cd' to /usr/src/etc and install files to the temproot environment # uname -a FreeBSD XXXXX.uib.no 6.3-STABLE FreeBSD 6.3-STABLE #3: Tue Jul 1 11:28:06 CEST 2008 root@uib.no:/usr/obj/usr/src/sys/XXXXXX amd64 I have also deleted the /usr/src and used csup to get all the source again without any luck. -- Med vennlig hilsen / Regards; Roar Pettersen Universitetet i Bergen - The University of Bergen Nygardsgt. 5 - N-5020 BERGEN - Norway Tlf: +47 55 58 40 55 fax: +47 55 58 40 70 roar.pettersen@it.uib.no - IT-Avd, UiB - http://www.uib.no From peterjeremy at optushome.com.au Sat Jul 12 09:51:32 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Sat Jul 12 09:51:39 2008 Subject: FreeBSD-6.3 (amd64) mergemaster problem In-Reply-To: References: Message-ID: <20080712095127.GT62764@server.vk2pj.dyndns.org> On 2008-Jul-12 10:58:00 +0200, Roar Pettersen wrote: >Trying to upgrade my FreeBSD-6.3-Stable (amd64) to FreeBSD-7.0-stable >(amd64), and after I have csup'ed the source and execute a >"mergemaster -i" then this error message occur : Maybe you left out a few steps but you need to do an installworld before you run 'mergemaster -i' - refer to /usr/src/UPDATING -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080712/acea1913/attachment.pgp From roar.pettersen at uib.no Sat Jul 12 09:56:46 2008 From: roar.pettersen at uib.no (Roar Pettersen) Date: Sat Jul 12 09:56:54 2008 Subject: FreeBSD-6.3 (amd64) mergemaster problem In-Reply-To: <20080712095127.GT62764@server.vk2pj.dyndns.org> References: <20080712095127.GT62764@server.vk2pj.dyndns.org> Message-ID: Hello ! > Maybe you left out a few steps but you need to do an installworld > before you run 'mergemaster -i' - refer to /usr/src/UPDATING Hmmm.. I guess that you are right, I will test. :-) Thank you ! -- Med vennlig hilsen / Regards; Roar Pettersen Universitetet i Bergen - The University of Bergen Nygardsgt. 5 - N-5020 BERGEN - Norway Tlf: +47 55 58 40 55 fax: +47 55 58 40 70 roar.pettersen@it.uib.no - IT-Avd, UiB - http://www.uib.no From roar.pettersen at uib.no Sat Jul 12 12:17:17 2008 From: roar.pettersen at uib.no (Roar Pettersen) Date: Sat Jul 12 12:17:25 2008 Subject: FreeBSD-6.3 (amd64) mergemaster problem In-Reply-To: <20080712095127.GT62764@server.vk2pj.dyndns.org> References: <20080712095127.GT62764@server.vk2pj.dyndns.org> Message-ID: Hi ! > Maybe you left out a few steps but you need to do an installworld > before you run 'mergemaster -i' - refer to /usr/src/UPDATING installworld solved the problem. :-) -- Med vennlig hilsen / Regards; Roar Pettersen Universitetet i Bergen - The University of Bergen Nygardsgt. 5 - N-5020 BERGEN - Norway Tlf: +47 55 58 40 55 fax: +47 55 58 40 70 roar.pettersen@it.uib.no - IT-Avd, UiB - http://www.uib.no From alex.kovalenko at verizon.net Sat Jul 12 13:01:19 2008 From: alex.kovalenko at verizon.net (Alexandre "Sunny" Kovalenko) Date: Sat Jul 12 13:01:27 2008 Subject: Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7 In-Reply-To: <4878250E.8040205@freebsd.org> References: <1210640542.1008.33.camel@RabbitsDen> <4828FDE5.8090409@freebsd.org> <1210696676.985.18.camel@RabbitsDen> <482DB4FE.3010300@freebsd.org> <1215824846.1074.23.camel@RabbitsDen> <4878250E.8040205@freebsd.org> Message-ID: <1215867198.1551.4.camel@RabbitsDen> On Fri, 2008-07-11 at 20:29 -0700, Sam Leffler wrote: > Alexandre "Sunny" Kovalenko wrote: > > On Fri, 2008-05-16 at 12:23 -0400, Sam Leffler wrote: > >> Alexandre "Sunny" Kovalenko wrote: > >>> On Mon, 2008-05-12 at 19:33 -0700, Sam Leffler wrote: > >>>> Alexandre "Sunny" Kovalenko wrote: > >>>>> I seem to be able to lock my machine by going into wpa_cli and asking it > >>>>> to 'reassoc'. The reason for question mark after "hard" is that debug > >>>>> information (caused by wlandebug and athdebug) is being printed on the > >>>>> console. The only way to get machine's attention is to hold power button > >>>>> for 8 seconds. > >>>> So this is just livelock due to console debug msgs. > >>> I am not sure, I have parsed this well enough, so I will try to clarify: > >>> machine becomes unresponsive *without* any debugging turned on, to an > >>> extent that pressing the power button twice *does not* generate ACPI > >>> console message (something to the tune of "going into S5 already -- > >>> gimme a break"). If I turn ath debugging on, I do see those messages, > >>> and only them, scrolling on the console. > >> Guess I misunderstood you. > > > > I have finally got enough time and equipment to investigate this > > further. Here are some conclusions: > > > > -- at this point (RELENG_7 as of July 9th around 15:30 EST) it is indeed > > a livelock. > > > > -- all system does, is executing ath_intr (if_ath.c) in the tight loop > > with the same status -- 0x1000 AKA HAL_INT_MIB. In order to eliminate > > possibility that I have caused livelock with the debug messages, I have > > put conditional panic() into ath_intr, as soon as sc->sc_stats.ast_mib > > reaches 10,000. Without any kind of the debug messages, it will be > > triggered within 40-60 seconds after starting of wpa_supplicant. > > > > -- I suspect that comment below, might not hold true on my equipment > > if (status & HAL_INT_MIB) { > > sc->sc_stats.ast_mib++; > > /* > > * Disable interrupts until we service the MIB > > * interrupt; otherwise it will continue to fire. > > */ > > ath_hal_intrset(ah, 0); > > /* > > * Let the hal handle the event. We assume it will <============ > > * clear whatever condition caused the interrupt. <============ > > */ > > ath_hal_mibevent(ah, &sc->sc_halstats); > > ath_hal_intrset(ah, sc->sc_imask); > > } > > > > My hardware is: > > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, > > RF5413) > > ath0: mem 0xedf00000-0xedf0ffff irq 17 at device 0.0 on > > pci3 > > ath0: [ITHREAD] > > ath0: using obsoleted if_watchdog interface > > ath0: Ethernet address: 00:16:cf:26:2f:3f > > ath0: mac 10.3 phy 6.1 radio 10.2 > > > > My wpa_supplicant.conf is: > > ctrl_interface=/var/run/wpa_supplicant > > ctrl_interface_group=wheel > > eapol_version=2 > > > > network={ > > ssid="XXXXXXXXXXX" > > scan_ssid=1 > > priority=1 > > proto=WPA > > pairwise=TKIP > > group=TKIP > > key_mgmt=WPA-PSK > > psk="xxxxxxxxxxxxxxxxxxxxxx" > > } > > > > Access point is Netgear WNDR3300-1B with 11N and 11G SSID set up to > > different values. Only 11G SSID is configured in wpa_supplicant.conf. In > > the test setup, AP is with 10' (3m) from the laptop. > > > > AP is successfully used by handful of Windows clients (including this > > same laptop) and iBook G4. > > > > Neither wpa_supplicant with '-d -d' nor wlandebug 0xFFFFFFFF show > > anything but normal scan. > > > > athdebug 0xFFFFFFFF loops with ath_intr: status 0x1000 until I power > > down my laptop. > > > > I would appreciate any suggestion on what I can investigate further -- > > at this point I have comfortable console setup and should be able to > > field requests for further information much better. > > > > Are you running powerd? I do. And I just tried disabling it, and I could not reproduce the problem any more. Is there any way to reconcile if_ath with powerd? Thank you, -- Alexandre "Sunny" Kovalenko (????????? ?????????) From koitsu at FreeBSD.org Sat Jul 12 16:40:33 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sat Jul 12 16:40:39 2008 Subject: Recent sys/boot/i386/boot2/boot2.c commit Message-ID: <20080712164032.GA25769@eos.sc1.parodius.com> Can someone shed some light on the below commit, particularly if it's responsible for fixing what some users have reported with boot2/loader: http://lists.freebsd.org/pipermail/freebsd-stable/2008-June/043363.html http://lists.freebsd.org/pipermail/freebsd-hackers/2008-June/024856.html The commit/diff is here: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/boot/i386/boot2/boot2.c.diff?r1=1.83.2.3;r2=1.83.2.4;f=h Revision 1.83.2.4: download - view: text, markup, annotated - select for diffs Fri Jul 11 15:43:07 2008 UTC (24 hours, 49 minutes ago) by nyan Branches: RELENG_7 Diff to: previous 1.83.2.3: preferred, colored; branchpoint 1.83: preferred, colored; next MAIN 1.84: preferred, colored Changes since revision 1.83.2.3: +1 -1 lines SVN rev 180449 on 2008-07-11 15:43:07Z by nyan MFC: r180145 Fix off-by-one error. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From sam at freebsd.org Sat Jul 12 16:57:03 2008 From: sam at freebsd.org (Sam Leffler) Date: Sat Jul 12 16:57:10 2008 Subject: Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7 In-Reply-To: <1215867198.1551.4.camel@RabbitsDen> References: <1210640542.1008.33.camel@RabbitsDen> <4828FDE5.8090409@freebsd.org> <1210696676.985.18.camel@RabbitsDen> <482DB4FE.3010300@freebsd.org> <1215824846.1074.23.camel@RabbitsDen> <4878250E.8040205@freebsd.org> <1215867198.1551.4.camel@RabbitsDen> Message-ID: <4878E25E.3000000@freebsd.org> Alexandre "Sunny" Kovalenko wrote: > On Fri, 2008-07-11 at 20:29 -0700, Sam Leffler wrote: > >> Alexandre "Sunny" Kovalenko wrote: >> >>> On Fri, 2008-05-16 at 12:23 -0400, Sam Leffler wrote: >>> >>>> Alexandre "Sunny" Kovalenko wrote: >>>> >>>>> On Mon, 2008-05-12 at 19:33 -0700, Sam Leffler wrote: >>>>> >>>>>> Alexandre "Sunny" Kovalenko wrote: >>>>>> >>>>>>> I seem to be able to lock my machine by going into wpa_cli and asking it >>>>>>> to 'reassoc'. The reason for question mark after "hard" is that debug >>>>>>> information (caused by wlandebug and athdebug) is being printed on the >>>>>>> console. The only way to get machine's attention is to hold power button >>>>>>> for 8 seconds. >>>>>>> >>>>>> So this is just livelock due to console debug msgs. >>>>>> >>>>> I am not sure, I have parsed this well enough, so I will try to clarify: >>>>> machine becomes unresponsive *without* any debugging turned on, to an >>>>> extent that pressing the power button twice *does not* generate ACPI >>>>> console message (something to the tune of "going into S5 already -- >>>>> gimme a break"). If I turn ath debugging on, I do see those messages, >>>>> and only them, scrolling on the console. >>>>> >>>> Guess I misunderstood you. >>>> >>> I have finally got enough time and equipment to investigate this >>> further. Here are some conclusions: >>> >>> -- at this point (RELENG_7 as of July 9th around 15:30 EST) it is indeed >>> a livelock. >>> >>> -- all system does, is executing ath_intr (if_ath.c) in the tight loop >>> with the same status -- 0x1000 AKA HAL_INT_MIB. In order to eliminate >>> possibility that I have caused livelock with the debug messages, I have >>> put conditional panic() into ath_intr, as soon as sc->sc_stats.ast_mib >>> reaches 10,000. Without any kind of the debug messages, it will be >>> triggered within 40-60 seconds after starting of wpa_supplicant. >>> >>> -- I suspect that comment below, might not hold true on my equipment >>> if (status & HAL_INT_MIB) { >>> sc->sc_stats.ast_mib++; >>> /* >>> * Disable interrupts until we service the MIB >>> * interrupt; otherwise it will continue to fire. >>> */ >>> ath_hal_intrset(ah, 0); >>> /* >>> * Let the hal handle the event. We assume it will <============ >>> * clear whatever condition caused the interrupt. <============ >>> */ >>> ath_hal_mibevent(ah, &sc->sc_halstats); >>> ath_hal_intrset(ah, sc->sc_imask); >>> } >>> >>> My hardware is: >>> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, >>> RF5413) >>> ath0: mem 0xedf00000-0xedf0ffff irq 17 at device 0.0 on >>> pci3 >>> ath0: [ITHREAD] >>> ath0: using obsoleted if_watchdog interface >>> ath0: Ethernet address: 00:16:cf:26:2f:3f >>> ath0: mac 10.3 phy 6.1 radio 10.2 >>> >>> My wpa_supplicant.conf is: >>> ctrl_interface=/var/run/wpa_supplicant >>> ctrl_interface_group=wheel >>> eapol_version=2 >>> >>> network={ >>> ssid="XXXXXXXXXXX" >>> scan_ssid=1 >>> priority=1 >>> proto=WPA >>> pairwise=TKIP >>> group=TKIP >>> key_mgmt=WPA-PSK >>> psk="xxxxxxxxxxxxxxxxxxxxxx" >>> } >>> >>> Access point is Netgear WNDR3300-1B with 11N and 11G SSID set up to >>> different values. Only 11G SSID is configured in wpa_supplicant.conf. In >>> the test setup, AP is with 10' (3m) from the laptop. >>> >>> AP is successfully used by handful of Windows clients (including this >>> same laptop) and iBook G4. >>> >>> Neither wpa_supplicant with '-d -d' nor wlandebug 0xFFFFFFFF show >>> anything but normal scan. >>> >>> athdebug 0xFFFFFFFF loops with ath_intr: status 0x1000 until I power >>> down my laptop. >>> >>> I would appreciate any suggestion on what I can investigate further -- >>> at this point I have comfortable console setup and should be able to >>> field requests for further information much better. >>> >>> >> Are you running powerd? >> > I do. And I just tried disabling it, and I could not reproduce the > problem any more. Is there any way to reconcile if_ath with powerd? > > Don't know. There appear to be two issues. When the MIB interrupts arrive the kernel may service them w/ the cpu at a reduced clock frequency. Since powered is currently the only mechanism for increasing the frequency and it runs in user space it can take a while to bump the clock rate leading to livelock (because the logic to reduce the _cause_ of the MIB interrupt takes a long time to run). John Baldwin suggested raising the clock frequency when handling interrupts in the kernel but nothing has been done to make that happen. Separately there is a question as to why the MIB interrupts are happening at all. This is possibly due to misprogramming of the baseband h/w in the ath card. Unfortunately I've been trying to get Atheros to help understand/resolve this question for a very long time (as their code also exhibits this behaviour) but they've been unresponsive. I have some experimental code to address this in new hal versions (such as 0.10.5.6 available in http://www.freebsd.org/~sam) but apparently it does not entirely fix the problem. Sam From alex.kovalenko at verizon.net Sat Jul 12 18:36:17 2008 From: alex.kovalenko at verizon.net (Alexandre "Sunny" Kovalenko) Date: Sat Jul 12 18:36:26 2008 Subject: Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7 In-Reply-To: <4878E25E.3000000@freebsd.org> References: <1210640542.1008.33.camel@RabbitsDen> <4828FDE5.8090409@freebsd.org> <1210696676.985.18.camel@RabbitsDen> <482DB4FE.3010300@freebsd.org> <1215824846.1074.23.camel@RabbitsDen> <4878250E.8040205@freebsd.org> <1215867198.1551.4.camel@RabbitsDen> <4878E25E.3000000@freebsd.org> Message-ID: <1215887769.1551.6.camel@RabbitsDen> On Sat, 2008-07-12 at 09:57 -0700, Sam Leffler wrote: > Alexandre "Sunny" Kovalenko wrote: > > On Fri, 2008-07-11 at 20:29 -0700, Sam Leffler wrote: > > > >> Alexandre "Sunny" Kovalenko wrote: > >> > >>> On Fri, 2008-05-16 at 12:23 -0400, Sam Leffler wrote: > >>> > >>>> Alexandre "Sunny" Kovalenko wrote: > >>>> > >>>>> On Mon, 2008-05-12 at 19:33 -0700, Sam Leffler wrote: > >>>>> > >>>>>> Alexandre "Sunny" Kovalenko wrote: > >>>>>> > >>>>>>> I seem to be able to lock my machine by going into wpa_cli and asking it > >>>>>>> to 'reassoc'. The reason for question mark after "hard" is that debug > >>>>>>> information (caused by wlandebug and athdebug) is being printed on the > >>>>>>> console. The only way to get machine's attention is to hold power button > >>>>>>> for 8 seconds. > >>>>>>> > >>>>>> So this is just livelock due to console debug msgs. > >>>>>> > >>>>> I am not sure, I have parsed this well enough, so I will try to clarify: > >>>>> machine becomes unresponsive *without* any debugging turned on, to an > >>>>> extent that pressing the power button twice *does not* generate ACPI > >>>>> console message (something to the tune of "going into S5 already -- > >>>>> gimme a break"). If I turn ath debugging on, I do see those messages, > >>>>> and only them, scrolling on the console. > >>>>> > >>>> Guess I misunderstood you. > >>>> > >>> I have finally got enough time and equipment to investigate this > >>> further. Here are some conclusions: > >>> > >>> -- at this point (RELENG_7 as of July 9th around 15:30 EST) it is indeed > >>> a livelock. > >>> > >>> -- all system does, is executing ath_intr (if_ath.c) in the tight loop > >>> with the same status -- 0x1000 AKA HAL_INT_MIB. In order to eliminate > >>> possibility that I have caused livelock with the debug messages, I have > >>> put conditional panic() into ath_intr, as soon as sc->sc_stats.ast_mib > >>> reaches 10,000. Without any kind of the debug messages, it will be > >>> triggered within 40-60 seconds after starting of wpa_supplicant. > >>> > >>> -- I suspect that comment below, might not hold true on my equipment > >>> if (status & HAL_INT_MIB) { > >>> sc->sc_stats.ast_mib++; > >>> /* > >>> * Disable interrupts until we service the MIB > >>> * interrupt; otherwise it will continue to fire. > >>> */ > >>> ath_hal_intrset(ah, 0); > >>> /* > >>> * Let the hal handle the event. We assume it will <============ > >>> * clear whatever condition caused the interrupt. <============ > >>> */ > >>> ath_hal_mibevent(ah, &sc->sc_halstats); > >>> ath_hal_intrset(ah, sc->sc_imask); > >>> } > >>> > >>> My hardware is: > >>> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, > >>> RF5413) > >>> ath0: mem 0xedf00000-0xedf0ffff irq 17 at device 0.0 on > >>> pci3 > >>> ath0: [ITHREAD] > >>> ath0: using obsoleted if_watchdog interface > >>> ath0: Ethernet address: 00:16:cf:26:2f:3f > >>> ath0: mac 10.3 phy 6.1 radio 10.2 > >>> > >>> My wpa_supplicant.conf is: > >>> ctrl_interface=/var/run/wpa_supplicant > >>> ctrl_interface_group=wheel > >>> eapol_version=2 > >>> > >>> network={ > >>> ssid="XXXXXXXXXXX" > >>> scan_ssid=1 > >>> priority=1 > >>> proto=WPA > >>> pairwise=TKIP > >>> group=TKIP > >>> key_mgmt=WPA-PSK > >>> psk="xxxxxxxxxxxxxxxxxxxxxx" > >>> } > >>> > >>> Access point is Netgear WNDR3300-1B with 11N and 11G SSID set up to > >>> different values. Only 11G SSID is configured in wpa_supplicant.conf. In > >>> the test setup, AP is with 10' (3m) from the laptop. > >>> > >>> AP is successfully used by handful of Windows clients (including this > >>> same laptop) and iBook G4. > >>> > >>> Neither wpa_supplicant with '-d -d' nor wlandebug 0xFFFFFFFF show > >>> anything but normal scan. > >>> > >>> athdebug 0xFFFFFFFF loops with ath_intr: status 0x1000 until I power > >>> down my laptop. > >>> > >>> I would appreciate any suggestion on what I can investigate further -- > >>> at this point I have comfortable console setup and should be able to > >>> field requests for further information much better. > >>> > >>> > >> Are you running powerd? > >> > > I do. And I just tried disabling it, and I could not reproduce the > > problem any more. Is there any way to reconcile if_ath with powerd? > > > > > > Don't know. There appear to be two issues. When the MIB interrupts > arrive the kernel may service them w/ the cpu at a reduced clock > frequency. Since powered is currently the only mechanism for increasing > the frequency and it runs in user space it can take a while to bump the > clock rate leading to livelock (because the logic to reduce the _cause_ > of the MIB interrupt takes a long time to run). John Baldwin suggested > raising the clock frequency when handling interrupts in the kernel but > nothing has been done to make that happen. > > Separately there is a question as to why the MIB interrupts are > happening at all. This is possibly due to misprogramming of the > baseband h/w in the ath card. Unfortunately I've been trying to get > Atheros to help understand/resolve this question for a very long time > (as their code also exhibits this behaviour) but they've been > unresponsive. I have some experimental code to address this in new hal > versions (such as 0.10.5.6 available in http://www.freebsd.org/~sam) but > apparently it does not entirely fix the problem. Would it be of any value to you, if I build the new hal and see what happen? I can live without powerd as the workaround, but I'd rather help if I can. > > Sam > -- Alexandre "Sunny" Kovalenko (????????? ?????????) From gavin.atkinson at ury.york.ac.uk Sat Jul 12 18:44:35 2008 From: gavin.atkinson at ury.york.ac.uk (Gavin Atkinson) Date: Sat Jul 12 18:44:42 2008 Subject: Recent sys/boot/i386/boot2/boot2.c commit In-Reply-To: <20080712164032.GA25769@eos.sc1.parodius.com> References: <20080712164032.GA25769@eos.sc1.parodius.com> Message-ID: <20080712193720.V2347@ury.york.ac.uk> On Sat, 12 Jul 2008, Jeremy Chadwick wrote: > Can someone shed some light on the below commit, particularly if it's > responsible for fixing what some users have reported with boot2/loader: > > http://lists.freebsd.org/pipermail/freebsd-stable/2008-June/043363.html > http://lists.freebsd.org/pipermail/freebsd-hackers/2008-June/024856.html >From the look of it, this is a change to the code that parses the "0(ad0,a)/boot/loader" strings, from a glance at the code I suspect that before this change, it was not possible to boot off the last possible partition (which I think is 4, but I could be wrong). So installs on ad3 would not be bootable. In short, I don't think many people will have been seeing this issue. Gavin From imb at protected-networks.net Sat Jul 12 20:19:50 2008 From: imb at protected-networks.net (Michael Butler) Date: Sat Jul 12 20:19:57 2008 Subject: RELENG_7 bind commit Message-ID: <487911DE.1070007@protected-networks.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is there an equivalent commit for RELENG_7 pending? Current (bind-9.4.2-p1) and RELENG_6 (bind-9.3.5-p1) now have the relevant patch per .. dougb 2008-07-12 09:38:35 UTC ~ FreeBSD src repository ~ Modified files: ~ contrib/bind9 CHANGES version ~ contrib/bind9/bin/named client.c server.c ~ contrib/bind9/doc/arm Bv9ARM-book.xml Bv9ARM.ch06.html ~ Bv9ARM.pdf ~ contrib/bind9/lib/bind9 check.c ~ contrib/bind9/lib/dns api dispatch.c resolver.c ~ contrib/bind9/lib/dns/include/dns dispatch.h ~ Removed files: ~ contrib/bind9/lib/bind aclocal.m4 config.h.in configure ~ Log: ~ SVN rev 180477 on 2008-07-12 09:38:35Z by dougb ~ Merge from vendor/bind9/dist as of the 9.4.2-P1 import, including ~ the patch from ISC for lib/bind9/check.c and deletion of unused ~ files in lib/bind. ~ This version will by default randomize the UDP query source port ~ (and sequence number of course) for every query. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkh5Ed4ACgkQQv9rrgRC1JKwHACdFVxatpgatHo1uMWbG47xSzrT Y8YAniazdsR8y225XY4hP/QyaEXHszPI =jlwZ -----END PGP SIGNATURE----- From dougb at FreeBSD.org Sat Jul 12 21:10:56 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Sat Jul 12 21:11:08 2008 Subject: RELENG_7 bind commit In-Reply-To: <487911DE.1070007@protected-networks.net> References: <487911DE.1070007@protected-networks.net> Message-ID: <48791DDD.6090601@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Michael Butler wrote: | Is there an equivalent commit for RELENG_7 pending? Yes. The security officer made the request to handle MF*s to RELENG_7 and the security branches. My understanding is that these updates are imminent. If your need for this update is urgent I encourage you to use the ports. This might be a very good time to give 9.5.0-P1 a try. FYI, one of the reasons for the delay was the need to coordinate two vendor imports into our subversion tree, and branch the bind9 vendor area to boot. This (to my knowledge) is the first time we've done anything on this scale with the new tree and it was important that it be done right, especially since we have two different versions of BIND in -stable branches right now (and it's likely that I'll have 3 versions in src/ pretty shortly). That said, I'd like to emphasize that this delay is not really that big of an issue since as I said above, the ports are available for those that can't wait. hth, Doug - -- ~ This .signature sanitized for your protection -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEAREDAAYFAkh5Hd0ACgkQyIakK9Wy8PvomgCg6lyOsDDM+syQy0kUI7BRLInE EcgAoKwH4Dh9QpX3f63AzKb+G7y/KiwE =xnNw -----END PGP SIGNATURE----- From bc979 at lafn.org Sat Jul 12 21:56:53 2008 From: bc979 at lafn.org (Doug Hardie) Date: Sat Jul 12 21:57:00 2008 Subject: System update Message-ID: <61CB96EF-CBEC-4F91-9566-EC90E0A33A17@lafn.org> I installed 7.0 release when it first came out. However, because of the TCP problems with users on cable modems I had to switch to Stable to get the fix. I haven't updated the source since then and now there are some updates on the verge of being released that need to be included. However, I can't tell if the fixes for the networking issue have been included in the security releases or not. Since these are production servers I don't want to just grab some random version of stable unless thats the only way to get all the required fixes. How do I find out which version I should upgrade to? If I can go back to a security release I suspect I will need to delete all of /usr/src, / usr/obj, and then reinstall the original source from the 7.0 release cd and then upgrade vi csup. From koitsu at FreeBSD.org Sat Jul 12 22:33:55 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sat Jul 12 22:36:02 2008 Subject: System update In-Reply-To: <61CB96EF-CBEC-4F91-9566-EC90E0A33A17@lafn.org> References: <61CB96EF-CBEC-4F91-9566-EC90E0A33A17@lafn.org> Message-ID: <20080712223355.GA43857@eos.sc1.parodius.com> On Sat, Jul 12, 2008 at 02:37:21PM -0700, Doug Hardie wrote: > I installed 7.0 release when it first came out. However, because of the > TCP problems with users on cable modems I had to switch to Stable to get > the fix. I haven't updated the source since then and now there are some > updates on the verge of being released that need to be included. > However, I can't tell if the fixes for the networking issue have been > included in the security releases or not. Since these are production > servers I don't want to just grab some random version of stable unless > thats the only way to get all the required fixes. How do I find out > which version I should upgrade to? If I can go back to a security > release I suspect I will need to delete all of /usr/src, /usr/obj, and > then reinstall the original source from the 7.0 release cd and then > upgrade vi csup. You're covering a multitude of topics in the above. It's hard to make out exactly what it is you're trying to say. First off, I'd like more information on this "TCP problems with users on cable modems" issue. I believe you may be referring to TCP extensions, a.k.a. RFC1323 extensions, but I'm not sure. If so, you can disable that feature in real-time via a sysctl. Can you shed some light on what the issue you're referring to is? Secondly, 7.0-RELEASE is simply named that way to announce "this OS is now out and available". Think of it as "FreeBSD 7.0 released to the world for the first time". Most of the 7.0 changes that are made *after* 7.0-RELEASE are committed to a CVS branch called RELENG_7. Shortly after (usually a few days) 7.0-RELEASE is made available to the public, the suffix changes from RELEASE to STABLE. There is no real "difference" between the two, other than STABLE being an even more up-to-date version of RELEASE, and is regularly updated/maintained. Thirdly, I don't know what you mean by "security releases", and what security issue you're referring to. Any time there is a security hole, mail is sent to a couple FreeBSD lists, articulating what the hole is, and what CVS branches the fix has been committed to. In the case of 7.0, it's going to be committed to RELENG_7, and possibly to RELENG_7_0 and other branches. The "main branch" people focus on is RELENG_7, aside from CURRENT which is called HEAD (or "." in cvs/supfiles). Fourthly, what is not made very clear to FreeBSD users is that if they install src and ports off the CD, that they are missing necessary files in /var/db/sup (or /usr/sup if they choose to use cvsup (not needed since csup exists in the base system)). To create the proper information so the version information matches, you have to do what's called ""adopting"" your existing src-all and ports-all tree: http://www.cvsup.org/faq.html#adopt This is one reason why I do not advocate installing src and ports off the installation media. Instead, I just leave src and ports unchecked and install everything else as normal -- then once the OS is installed, use csup to populate /usr/src and /usr/ports, which will also populate /var/db/sup. I've never had any versioning mismatches or "wild stuff" happen since doing that. In your case, the simple solution is (assuming you use csup): rm -fr /usr/src /usr/ports /var/db/sup csup -h -L2 /usr/share/examples/cvsup/stable-supfile csup -h -L2 /usr/share/examples/cvsup/ports-supfile /usr/share/examples/cvsup/stable-supfile uses the CVS tag RELENG_7, and ports-supfile uses the CVS tag . (which means HEAD); there is no RELENG_xxx for ports. And do not forget to rm -fr /usr/obj before doing a buildworld and buildkernel, too. Fifthly, and possibly the ultimate question: what CVS branch are you following in your supfiles? Are you following RELENG_7, RELENG_7_0, or what? Yes, it matters. IMHO, you should really be following RELENG_7. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From bc979 at lafn.org Sun Jul 13 03:38:55 2008 From: bc979 at lafn.org (Doug Hardie) Date: Sun Jul 13 03:39:03 2008 Subject: System update In-Reply-To: <20080712223355.GA43857@eos.sc1.parodius.com> References: <61CB96EF-CBEC-4F91-9566-EC90E0A33A17@lafn.org> <20080712223355.GA43857@eos.sc1.parodius.com> Message-ID: On Jul 12, 2008, at 15:33, Jeremy Chadwick wrote: > On Sat, Jul 12, 2008 at 02:37:21PM -0700, Doug Hardie wrote: >> I installed 7.0 release when it first came out. However, because >> of the >> TCP problems with users on cable modems I had to switch to Stable >> to get >> the fix. I haven't updated the source since then and now there are >> some >> updates on the verge of being released that need to be included. >> However, I can't tell if the fixes for the networking issue have been >> included in the security releases or not. Since these are production >> servers I don't want to just grab some random version of stable >> unless >> thats the only way to get all the required fixes. How do I find out >> which version I should upgrade to? If I can go back to a security >> release I suspect I will need to delete all of /usr/src, /usr/obj, >> and >> then reinstall the original source from the 7.0 release cd and then >> upgrade vi csup. > > You're covering a multitude of topics in the above. It's hard to make > out exactly what it is you're trying to say. > > First off, I'd like more information on this "TCP problems with > users on > cable modems" issue. I believe you may be referring to TCP > extensions, > a.k.a. RFC1323 extensions, but I'm not sure. If so, you can disable > that feature in real-time via a sysctl. Can you shed some light on > what > the issue you're referring to is? From Bjoern A. Zeeb: You want to update to 7-STABLE which has the TCP fixes or you want to apply the following changes: 1.141.2.4 +10 -2 src/sys/netinet/tcp_output.c 1.157.2.2 +5 -2 src/sys/netinet/tcp_var.h In case you are not using MD5 that should be enough. Else see freebsd-net from the last 3 days for another patch. There is no sysctl for that. As I recall it had to do with the order that options appeared in a IP SYN packet. There was a bunch of discussion on that in this forum around 3 Apr. > > > Secondly, 7.0-RELEASE is simply named that way to announce "this OS is > now out and available". Think of it as "FreeBSD 7.0 released to the > world for the first time". Most of the 7.0 changes that are made > *after* 7.0-RELEASE are committed to a CVS branch called RELENG_7. > Shortly after (usually a few days) 7.0-RELEASE is made available to > the > public, the suffix changes from RELEASE to STABLE. There is no real > "difference" between the two, other than STABLE being an even more > up-to-date version of RELEASE, and is regularly updated/maintained. Unfortunately Stable is not always "stable". It is to some extent still being tested. There used to be a tag to which security and stability patches were applied but no major system changes. My recollection is it was RELENG_7.0 but I am not sure about that anymore. > > > Thirdly, I don't know what you mean by "security releases", and what > security issue you're referring to. Any time there is a security > hole, > mail is sent to a couple FreeBSD lists, articulating what the hole is, > and what CVS branches the fix has been committed to. In the case of > 7.0, it's going to be committed to RELENG_7, and possibly to > RELENG_7_0 > and other branches. The "main branch" people focus on is RELENG_7, > aside from CURRENT which is called HEAD (or "." in cvs/supfiles). Well, there are the security patches for bind 9 that come immediately to mind. I seem to recall reading about others but didn't really keep track of them. > > > Fourthly, what is not made very clear to FreeBSD users is that if they > install src and ports off the CD, that they are missing necessary > files > in /var/db/sup (or /usr/sup if they choose to use cvsup (not needed > since csup exists in the base system)). To create the proper > information so the version information matches, you have to do what's > called ""adopting"" your existing src-all and ports-all tree: > > http://www.cvsup.org/faq.html#adopt > > This is one reason why I do not advocate installing src and ports off > the installation media. Instead, I just leave src and ports unchecked > and install everything else as normal -- then once the OS is > installed, > use csup to populate /usr/src and /usr/ports, which will also populate > /var/db/sup. I've never had any versioning mismatches or "wild stuff" > happen since doing that. Thats really neat if you have bandwidth to spare. These are heavily used production systems and we don't obtain any extra bandwidth to just sit around idle. Downloading all the source would be a killer for our users. Updates are bad enough. > > > In your case, the simple solution is (assuming you use csup): > > rm -fr /usr/src /usr/ports /var/db/sup > csup -h -L2 /usr/share/examples/cvsup/stable-supfile > csup -h -L2 /usr/share/examples/cvsup/ports-supfile > > /usr/share/examples/cvsup/stable-supfile uses the CVS tag RELENG_7, > and ports-supfile uses the CVS tag . (which means HEAD); there is no > RELENG_xxx for ports. > > And do not forget to rm -fr /usr/obj before doing a buildworld and > buildkernel, too. > > Fifthly, and possibly the ultimate question: what CVS branch are > you following in your supfiles? Are you following RELENG_7, > RELENG_7_0, or what? Yes, it matters. IMHO, you should really > be following RELENG_7. I am not updating because I cannot afford to lose users who are on cable. I have stable as of the date of the message above (around 3 Apr). > > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > From sam at freebsd.org Sun Jul 13 04:26:37 2008 From: sam at freebsd.org (Sam Leffler) Date: Sun Jul 13 04:26:44 2008 Subject: Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7 In-Reply-To: <1215887769.1551.6.camel@RabbitsDen> References: <1210640542.1008.33.camel@RabbitsDen> <4828FDE5.8090409@freebsd.org> <1210696676.985.18.camel@RabbitsDen> <482DB4FE.3010300@freebsd.org> <1215824846.1074.23.camel@RabbitsDen> <4878250E.8040205@freebsd.org> <1215867198.1551.4.camel@RabbitsDen> <4878E25E.3000000@freebsd.org> <1215887769.1551.6.camel@RabbitsDen> Message-ID: <487983FA.5090807@freebsd.org> Alexandre "Sunny" Kovalenko wrote: > On Sat, 2008-07-12 at 09:57 -0700, Sam Leffler wrote: > >> Alexandre "Sunny" Kovalenko wrote: >> >>> On Fri, 2008-07-11 at 20:29 -0700, Sam Leffler wrote: >>> >>> >>>> Alexandre "Sunny" Kovalenko wrote: >>>> >>>> >>>>> On Fri, 2008-05-16 at 12:23 -0400, Sam Leffler wrote: >>>>> >>>>> >>>>>> Alexandre "Sunny" Kovalenko wrote: >>>>>> >>>>>> >>>>>>> On Mon, 2008-05-12 at 19:33 -0700, Sam Leffler wrote: >>>>>>> >>>>>>> >>>>>>>> Alexandre "Sunny" Kovalenko wrote: >>>>>>>> >>>>>>>> >>>>>>>>> I seem to be able to lock my machine by going into wpa_cli and asking it >>>>>>>>> to 'reassoc'. The reason for question mark after "hard" is that debug >>>>>>>>> information (caused by wlandebug and athdebug) is being printed on the >>>>>>>>> console. The only way to get machine's attention is to hold power button >>>>>>>>> for 8 seconds. >>>>>>>>> >>>>>>>>> >>>>>>>> So this is just livelock due to console debug msgs. >>>>>>>> >>>>>>>> >>>>>>> I am not sure, I have parsed this well enough, so I will try to clarify: >>>>>>> machine becomes unresponsive *without* any debugging turned on, to an >>>>>>> extent that pressing the power button twice *does not* generate ACPI >>>>>>> console message (something to the tune of "going into S5 already -- >>>>>>> gimme a break"). If I turn ath debugging on, I do see those messages, >>>>>>> and only them, scrolling on the console. >>>>>>> >>>>>>> >>>>>> Guess I misunderstood you. >>>>>> >>>>>> >>>>> I have finally got enough time and equipment to investigate this >>>>> further. Here are some conclusions: >>>>> >>>>> -- at this point (RELENG_7 as of July 9th around 15:30 EST) it is indeed >>>>> a livelock. >>>>> >>>>> -- all system does, is executing ath_intr (if_ath.c) in the tight loop >>>>> with the same status -- 0x1000 AKA HAL_INT_MIB. In order to eliminate >>>>> possibility that I have caused livelock with the debug messages, I have >>>>> put conditional panic() into ath_intr, as soon as sc->sc_stats.ast_mib >>>>> reaches 10,000. Without any kind of the debug messages, it will be >>>>> triggered within 40-60 seconds after starting of wpa_supplicant. >>>>> >>>>> -- I suspect that comment below, might not hold true on my equipment >>>>> if (status & HAL_INT_MIB) { >>>>> sc->sc_stats.ast_mib++; >>>>> /* >>>>> * Disable interrupts until we service the MIB >>>>> * interrupt; otherwise it will continue to fire. >>>>> */ >>>>> ath_hal_intrset(ah, 0); >>>>> /* >>>>> * Let the hal handle the event. We assume it will <============ >>>>> * clear whatever condition caused the interrupt. <============ >>>>> */ >>>>> ath_hal_mibevent(ah, &sc->sc_halstats); >>>>> ath_hal_intrset(ah, sc->sc_imask); >>>>> } >>>>> >>>>> My hardware is: >>>>> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, >>>>> RF5413) >>>>> ath0: mem 0xedf00000-0xedf0ffff irq 17 at device 0.0 on >>>>> pci3 >>>>> ath0: [ITHREAD] >>>>> ath0: using obsoleted if_watchdog interface >>>>> ath0: Ethernet address: 00:16:cf:26:2f:3f >>>>> ath0: mac 10.3 phy 6.1 radio 10.2 >>>>> >>>>> My wpa_supplicant.conf is: >>>>> ctrl_interface=/var/run/wpa_supplicant >>>>> ctrl_interface_group=wheel >>>>> eapol_version=2 >>>>> >>>>> network={ >>>>> ssid="XXXXXXXXXXX" >>>>> scan_ssid=1 >>>>> priority=1 >>>>> proto=WPA >>>>> pairwise=TKIP >>>>> group=TKIP >>>>> key_mgmt=WPA-PSK >>>>> psk="xxxxxxxxxxxxxxxxxxxxxx" >>>>> } >>>>> >>>>> Access point is Netgear WNDR3300-1B with 11N and 11G SSID set up to >>>>> different values. Only 11G SSID is configured in wpa_supplicant.conf. In >>>>> the test setup, AP is with 10' (3m) from the laptop. >>>>> >>>>> AP is successfully used by handful of Windows clients (including this >>>>> same laptop) and iBook G4. >>>>> >>>>> Neither wpa_supplicant with '-d -d' nor wlandebug 0xFFFFFFFF show >>>>> anything but normal scan. >>>>> >>>>> athdebug 0xFFFFFFFF loops with ath_intr: status 0x1000 until I power >>>>> down my laptop. >>>>> >>>>> I would appreciate any suggestion on what I can investigate further -- >>>>> at this point I have comfortable console setup and should be able to >>>>> field requests for further information much better. >>>>> >>>>> >>>>> >>>> Are you running powerd? >>>> >>>> >>> I do. And I just tried disabling it, and I could not reproduce the >>> problem any more. Is there any way to reconcile if_ath with powerd? >>> >>> >>> >> Don't know. There appear to be two issues. When the MIB interrupts >> arrive the kernel may service them w/ the cpu at a reduced clock >> frequency. Since powered is currently the only mechanism for increasing >> the frequency and it runs in user space it can take a while to bump the >> clock rate leading to livelock (because the logic to reduce the _cause_ >> of the MIB interrupt takes a long time to run). John Baldwin suggested >> raising the clock frequency when handling interrupts in the kernel but >> nothing has been done to make that happen. >> >> Separately there is a question as to why the MIB interrupts are >> happening at all. This is possibly due to misprogramming of the >> baseband h/w in the ath card. Unfortunately I've been trying to get >> Atheros to help understand/resolve this question for a very long time >> (as their code also exhibits this behaviour) but they've been >> unresponsive. I have some experimental code to address this in new hal >> versions (such as 0.10.5.6 available in http://www.freebsd.org/~sam) but >> apparently it does not entirely fix the problem. >> > Would it be of any value to you, if I build the new hal and see what > happen? I can live without powerd as the workaround, but I'd rather help > if I can. > > Testing the latest hal is always useful but I've not MFC'd many ath changes to RELENG_7 and some people have reported problems on RELENG_7 w/ the new hal that do not occur on HEAD. Sam From nakal at web.de Sun Jul 13 09:50:43 2008 From: nakal at web.de (Martin) Date: Sun Jul 13 09:50:52 2008 Subject: Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7 Message-ID: <20080713112117.7d3ff6c6@web.de> Hi Sam, do you know if there is anything done about cbb(4)? I have many wireless adapters with ath(4), but only the one based on PCMCIA is making problems on FreeBSD. I cannot boot my notebook with the device inserted into the port, or it will render the system unusable (100% load on cbb(4)). And all I can see is the following: Jul 12 14:58:39 link kernel: ath0: ath_chan_set: unable to reset channel 1 (2412 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:58:40 link kernel: ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 Jul 12 14:58:41 link kernel: ath0: ath_chan_set: unable to reset channel 7 (2442 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 Jul 12 14:58:42 link kernel: ath0: ath_chan_set: unable to reset channel 2 (2417 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:58:43 link kernel: ath0: ath_chan_set: unable to reset channel 3 (2422 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:58:44 link kernel: ath0: ath_chan_set: unable to reset channel 4 (2427 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 Jul 12 14:58:45 link kernel: ath0: ath_chan_set: unable to reset channel 5 (2432 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:58:45 link kernel: ath0: ath_chan_set: unable to reset channel 8 (2447 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:58:46 link kernel: ath0: ath_chan_set: unable to reset channel 9 (2452 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:58:47 link kernel: ath0: ath_chan_set: unable to reset channel 10 (2457 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:58:52 link kernel: ath0: device timeout Jul 12 14:58:52 link kernel: ath0: ath_reset: unable to reset hardware; hal status 3231908395 Jul 12 14:58:58 link kernel: ath0: ath_chan_set: unable to reset channel 1 (2412 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 Jul 12 14:58:59 link kernel: ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:00 link kernel: ath0: ath_chan_set: unable to reset channel 7 (2442 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:01 link kernel: ath0: ath_chan_set: unable to reset channel 2 (2417 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:01 link kernel: ath0: ath_chan_set: unable to reset channel 3 (2422 Mhz, flags 0x480 hal flags 0xc0), hal status 3289233408 Jul 12 14:59:02 link kernel: ath0: ath_chan_set: unable to reset channel 4 (2427 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:03 link kernel: ath0: ath_chan_set: unable to reset channel 5 (2432 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:04 link kernel: ath0: ath_chan_set: unable to reset channel 8 (2447 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:05 link kernel: ath0: ath_chan_set: unable to reset channel 9 (2452 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:06 link kernel: ath0: ath_chan_set: unable to reset channel 10 (2457 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:10 link kernel: ath0: device timeout Jul 12 14:59:10 link kernel: ath0: ath_reset: unable to reset hardware; hal status 3231908395 Jul 12 14:59:11 link kernel: ath0: ath_chan_set: unable to reset channel 1 (2412 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 Jul 12 14:59:12 link kernel: ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:13 link kernel: ath0: ath_chan_set: unable to reset channel 7 (2442 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 Jul 12 14:59:14 link kernel: ath0: ath_chan_set: unable to reset channel 2 (2417 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:15 link kernel: ath0: ath_chan_set: unable to reset channel 3 (2422 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:16 link kernel: ath0: unable to reset hardware; hal status 3868687084 Jul 12 14:59:16 link kernel: ath0: ath_chan_set: unable to reset channel 4 (2427 Mhz, flags 0x480 hal flags 0xc0), hal status 0 Jul 12 14:59:17 link kernel: ath0: ath_chan_set: unable to reset channel 11 (2462 Mhz, flags 0x480 hal flags 0xc0), hal status 3828804624 Jul 12 14:59:22 link kernel: ath0: unable to reset hardware; hal status 3868539700 Jul 12 14:59:32 link kernel: ath0: unable to reset hardware; hal status 3868539700 Jul 12 14:59:42 link kernel: ath0: unable to reset hardware; hal status 3868539700 Jul 12 15:00:22 link last message repeated 4 times Jul 12 15:00:32 link kernel: ath0: unable to reset hardware; hal status 3868539700 Jul 12 15:00:42 link kernel: ath0: unable to reset hardware; hal status 3868539700 Jul 12 15:00:52 link kernel: ath0: unable to reset hardware; hal status 3868539700 wpa_supplicant is trying to access the card and switching channels, I suppose. A workaround that I'm using all the time is: 1) boot the notebook without the PCMCIA card 2) after gdm appears, insert the card Also see: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/120376 In this PR I also described that you can panic the system, while trying to fix the situation by reinserting the card. But I found out, that you can always panic the system when ejecting the card and wpa_supplicant is running. -- Gru?, Martin Sugioarto | Lehrstuhl Informatik 14 | | TU-Do //// TU Dortmund | | //// Otto-Hahn-Stra?e 14 | | \.\\/// D-44227 Dortmund | | \\\\/ Tel. (0231) 755 7733 | From gaijin.k at gmail.com Sun Jul 13 12:37:24 2008 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Sun Jul 13 12:37:31 2008 Subject: Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7 In-Reply-To: <20080713112117.7d3ff6c6@web.de> References: <20080713112117.7d3ff6c6@web.de> Message-ID: <1215952634.1731.3.camel@RabbitsDen> On Sun, 2008-07-13 at 11:21 +0200, Martin wrote: > Hi Sam, > > do you know if there is anything done about cbb(4)? I have many > wireless adapters with ath(4), but only the one based on PCMCIA is > making problems on FreeBSD. > > I cannot boot my notebook with the device inserted into the port, or it > will render the system unusable (100% load on cbb(4)). > > And all I can see is the following: > Jul 12 14:58:39 link kernel: ath0: ath_chan_set: unable to reset channel 1 (2412 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:58:40 link kernel: ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 > Jul 12 14:58:41 link kernel: ath0: ath_chan_set: unable to reset channel 7 (2442 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 > Jul 12 14:58:42 link kernel: ath0: ath_chan_set: unable to reset channel 2 (2417 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:58:43 link kernel: ath0: ath_chan_set: unable to reset channel 3 (2422 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:58:44 link kernel: ath0: ath_chan_set: unable to reset channel 4 (2427 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 > Jul 12 14:58:45 link kernel: ath0: ath_chan_set: unable to reset channel 5 (2432 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:58:45 link kernel: ath0: ath_chan_set: unable to reset channel 8 (2447 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:58:46 link kernel: ath0: ath_chan_set: unable to reset channel 9 (2452 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:58:47 link kernel: ath0: ath_chan_set: unable to reset channel 10 (2457 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:58:52 link kernel: ath0: device timeout > Jul 12 14:58:52 link kernel: ath0: ath_reset: unable to reset hardware; hal status 3231908395 > Jul 12 14:58:58 link kernel: ath0: ath_chan_set: unable to reset channel 1 (2412 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 > Jul 12 14:58:59 link kernel: ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:59:00 link kernel: ath0: ath_chan_set: unable to reset channel 7 (2442 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:59:01 link kernel: ath0: ath_chan_set: unable to reset channel 2 (2417 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:59:01 link kernel: ath0: ath_chan_set: unable to reset channel 3 (2422 Mhz, flags 0x480 hal flags 0xc0), hal status 3289233408 > Jul 12 14:59:02 link kernel: ath0: ath_chan_set: unable to reset channel 4 (2427 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:59:03 link kernel: ath0: ath_chan_set: unable to reset channel 5 (2432 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:59:04 link kernel: ath0: ath_chan_set: unable to reset channel 8 (2447 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:59:05 link kernel: ath0: ath_chan_set: unable to reset channel 9 (2452 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:59:06 link kernel: ath0: ath_chan_set: unable to reset channel 10 (2457 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:59:10 link kernel: ath0: device timeout > Jul 12 14:59:10 link kernel: ath0: ath_reset: unable to reset hardware; hal status 3231908395 > Jul 12 14:59:11 link kernel: ath0: ath_chan_set: unable to reset channel 1 (2412 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 > Jul 12 14:59:12 link kernel: ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:59:13 link kernel: ath0: ath_chan_set: unable to reset channel 7 (2442 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 > Jul 12 14:59:14 link kernel: ath0: ath_chan_set: unable to reset channel 2 (2417 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:59:15 link kernel: ath0: ath_chan_set: unable to reset channel 3 (2422 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:59:16 link kernel: ath0: unable to reset hardware; hal status 3868687084 > Jul 12 14:59:16 link kernel: ath0: ath_chan_set: unable to reset channel 4 (2427 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:59:17 link kernel: ath0: ath_chan_set: unable to reset channel 11 (2462 Mhz, flags 0x480 hal flags 0xc0), hal status 3828804624 > Jul 12 14:59:22 link kernel: ath0: unable to reset hardware; hal status 3868539700 > Jul 12 14:59:32 link kernel: ath0: unable to reset hardware; hal status 3868539700 > Jul 12 14:59:42 link kernel: ath0: unable to reset hardware; hal status 3868539700 > Jul 12 15:00:22 link last message repeated 4 times > Jul 12 15:00:32 link kernel: ath0: unable to reset hardware; hal status 3868539700 > Jul 12 15:00:42 link kernel: ath0: unable to reset hardware; hal status 3868539700 > Jul 12 15:00:52 link kernel: ath0: unable to reset hardware; hal status 3868539700 > > > wpa_supplicant is trying to access the card and switching channels, I > suppose. > > A workaround that I'm using all the time is: > 1) boot the notebook without the PCMCIA card > 2) after gdm appears, insert the card > > Also see: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/120376 > > In this PR I also described that you can panic the system, > while trying to fix the situation by reinserting the card. > But I found out, that you can always panic the system when > ejecting the card and wpa_supplicant is running. > You can panic the box by unloading if_ath.ko while wpa_supplicant is running on any form factor, so this one is not specific to the removable devices. -- Alexandre "Sunny" Kovalenko (????????? ?????????) From kamikaze at bsdforen.de Sun Jul 13 15:21:23 2008 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Sun Jul 13 15:21:31 2008 Subject: dvd dma problems Message-ID: <487A18E8.6010809@bsdforen.de> I have a couple of DVD drives (one drive, one burner) that used to play DVDs quite fine from 5.3 to somewhere in the 6.x branch. Nowadays I have to send them to PIO4 to play DVDs, because they'll just throw DMA not aligned errors around in UDMA33 or WDMA2 mode. Should someone be interested in this I'm willing to supply all necessary information, such as the exact drives, firmware versions, kernel traces... whatever comes to your mind. I'm also willing to test patches. From koitsu at FreeBSD.org Sun Jul 13 16:40:33 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Jul 13 16:40:41 2008 Subject: dvd dma problems In-Reply-To: <487A18E8.6010809@bsdforen.de> References: <487A18E8.6010809@bsdforen.de> Message-ID: <20080713164033.GA97147@eos.sc1.parodius.com> On Sun, Jul 13, 2008 at 05:02:00PM +0200, Dominic Fandrey wrote: > I have a couple of DVD drives (one drive, one burner) that used to play DVDs > quite fine from 5.3 to somewhere in the 6.x branch. Nowadays I have to send > them to PIO4 to play DVDs, because they'll just throw DMA not aligned errors > around in UDMA33 or WDMA2 mode. > > Should someone be interested in this I'm willing to supply all necessary > information, such as the exact drives, firmware versions, kernel traces... > whatever comes to your mind. I'm also willing to test patches. Is the problem you're seeing identical to this? http://lists.freebsd.org/pipermail/freebsd-hackers/2008-July/025297.html -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From modelnine at modelnine.org Sun Jul 13 17:11:25 2008 From: modelnine at modelnine.org (Heiko Wundram) Date: Sun Jul 13 17:11:32 2008 Subject: if_ral lockups [was: Re: Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7] In-Reply-To: <1215952634.1731.3.camel@RabbitsDen> References: <20080713112117.7d3ff6c6@web.de> <1215952634.1731.3.camel@RabbitsDen> Message-ID: <200807131858.12147.modelnine@modelnine.org> Am Sonntag, 13. Juli 2008 14:37:14 schrieb Alexandre "Sunny" Kovalenko: > Just to chime into the discussion, I'm seeing something similar for if_ral since my latest update of 7-STABLE from about two weeks ago (which I did not see with a 7-STABLE from some time in march, so something must have changed in between, but I can't narrow it down exactly). I've since updated the kernel several times (the latest update being just last friday), but the problem hasn't disappeared so far. I get an oops, followed by a reboot when wpa_supplicant has associated an if_ral interface (which is a removable PCMCIA Ralink based WLAN card) when powerd is running. As soon as I disable powerd for my laptop (and it runs continuously at 1800 Mhz), the oopses disappear. As I'm getting a kernel oops, if anybody is interested, I'd more than happily reenable powerd to produce a kernel dump and make that available to anybody who is interested in debugging it, along with the kernel images, of course. I'm running a self-compiled GENERIC (with nothing changed except for the self-compiled part). I currently don't have the time to track this down any further myself, though, and the workaround works for me. Device info: ... cbb0: at device 9.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [ITHREAD] cbb1: at device 9.1 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb1: [ITHREAD] ... ral0: mem 0x88000000-0x88007fff irq 17 at device 0.0 on cardbus0 ral0: MAC/BBP RT2561C, RF RT2527 ral0: Ethernet address: 00:80:5a:51:23:53 ral0: [ITHREAD] ... uname: FreeBSD phoenix.modelnine.org 7.0-STABLE FreeBSD 7.0-STABLE #0: Fri Jul 11 12:28:25 CEST 2008 root@phoenix.modelnine.org:/usr/obj/usr/src/sys/GENERIC i386 -- Heiko Wundram From sven at dmv.com Sun Jul 13 18:19:46 2008 From: sven at dmv.com (Sven W) Date: Sun Jul 13 18:19:57 2008 Subject: Using iscsi with multiple targets Message-ID: <487A40FE.7030102@dmv.com> FreeBSD 7.0 I have 2 machines with identical configurations/hardware, let's call them A (master) and B (slave). I have installed iscsi-target from ports and have set up 3 targets representing the 3 drives I wish to be connected to from A. The Targets file: # extents file start length extent0 /dev/da1 0 465GB extent1 /dev/da2 0 465GB extent2 /dev/da3 0 465GB # target flags storage netmask target0 rw extent0 192.168.0.1/24 target1 rw extent1 192.168.0.1/24 target2 rw extent2 192.168.0.1/24 I then start up iscsi_target and all is good. Now on A I have set up my /etc/iscsi.conf file as follows: # cat /etc/iscsi.conf data1 { targetaddress=192.168.0.252 targetname=iqn.1994-04.org.netbsd.iscsi-target:target0 initiatorname=iqn.2005-01.il.ac.huji.cs::BSD-2-1.sven.local } data2 { targetaddress=192.168.0.252 targetname=iqn.1994-04.org.netbsd.iscsi-target:target1 initiatorname=iqn.2005-01.il.ac.huji.cs::BSD-2-1.sven.local } data3 { targetaddress=192.168.0.252 targetname=iqn.1994-04.org.netbsd.iscsi-target:target2 initiatorname=iqn.2005-01.il.ac.huji.cs::BSD-2-1.sven.local } So far so good, now come the issues. First of all, it would appear that with iscontrol one can only start one "named" session at a time; for example /sbin/iscontrol -n data1 /sbin/iscontrol -n data2 /sbin/isconrtol -n data3 I guess that is ok, except that each invocation of iscontrol resets the other sessions. Here is the camcontrol and dmesg output from running the above 3 commands. # camcontrol devlist at scbus0 target 0 lun 0 (pass0,da0) at scbus0 target 1 lun 0 (pass1,da1) at scbus0 target 2 lun 0 (pass2,da2) at scbus0 target 3 lun 0 (pass3,da3) at scbus1 target 0 lun 0 (da5,pass5) at scbus1 target 1 lun 0 (da6,pass6) at scbus1 target 2 lun 0 (da4,pass4) [ /sbin/iscontrol -n data1 ] da4 at iscsi0 bus 0 target 0 lun 0 da4: Fixed Direct Access SCSI-3 device [ /sbin/iscontrol -n data2 ] (da4:iscsi0:0:0:0): lost device (da4:iscsi0:0:0:0): removing device entry da4 at iscsi0 bus 0 target 0 lun 0 da4: Fixed Direct Access SCSI-3 device da5 at iscsi0 bus 0 target 1 lun 0 da5: Fixed Direct Access SCSI-3 device [ /sbin/iscontrol -n data3 ] (da4:iscsi0:0:0:0): lost device (da4:iscsi0:0:0:0): removing device entry (da5:iscsi0:0:1:0): lost device (da5:iscsi0:0:1:0): removing device entry da4 at iscsi0 bus 0 target 2 lun 0 da4: Fixed Direct Access SCSI-3 device da5 at iscsi0 bus 0 target 0 lun 0 da5: Fixed Direct Access SCSI-3 device da6 at iscsi0 bus 0 target 1 lun 0 da6: Fixed Direct Access SCSI-3 device It would appear that rather than appending the new device to the end of the "da" devices, it starts to do some type of naming queue after the second device. If I am to use these devices in any type of automated setup, how can make sure that after these commands, "da6" will always be target 1 (i.e. /dev/da2 on the slave machine). Next, there is no "startup" script for iscontrol - would that simply have to be added the system or is there a way with sysctl that it could be done. The plan here is use gmirror such that /dev/da1 on A is mirrored with the /dev/da1 on B using iscsi. Sven From nakal at web.de Sun Jul 13 18:21:36 2008 From: nakal at web.de (Martin) Date: Sun Jul 13 18:21:43 2008 Subject: Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7 Message-ID: <20080713202133.21f4c5b8@web.de> Hi Alexandre, > You can panic the box by unloading if_ath.ko while wpa_supplicant is > running on any form factor, so this one is not specific to the removable > devices. I am not talking about unloading kernel modules (I wouldn't unload if_ath by force and complain about it). The panic is happening while ejecting the PCMCIA card and wpa_supplicant is running. The cbb(4) problem with the high load is much more annoying for me, because the only solution is to reboot the system to get it stable again. One thing I also noticed is that if I have set a high resolution with vidcontrol (1600x1200) and the text terminal display becomes really slow, ath(4) has difficulties to load the device when it is inserted into the PCMCIA-slot. -- Martin Sugioarto From oberman at es.net Sun Jul 13 21:39:27 2008 From: oberman at es.net (Kevin Oberman) Date: Sun Jul 13 21:39:34 2008 Subject: sshd unable to use RSA keys on 6-Stable Message-ID: <20080713213926.50ABE4500E@ptavv.es.net> I recently removed my DSA keys from my laptop and desktop systems, leaving only the RSA keys. This is working for several systems, but several are logging errors with every access that did not show up when DSA keys were used. Jul 13 14:23:50 star-owamp sshd[1579]: error: buffer_get_ret: trying to get more bytes 129 than in buffer 34 Jul 13 14:23:50 star-owamp sshd[1579]: error: buffer_get_string_ret: buffer_get failed Jul 13 14:23:50 star-owamp sshd[1579]: error: buffer_get_bignum2_ret: invalid bignum Jul 13 14:23:50 star-owamp sshd[1579]: error: key_from_blob: can't read rsa key Jul 13 14:23:50 star-owamp sshd[1579]: error: key_read: key_from_blob AAAAB3NzaC1yc2EAAAABIwAAAIEAuFblncD1qLy2QlnakQQATrrghSQmImjaLPRslTzG3Hn4\n failed Jul 13 14:23:50 star-owamp sshd[1579]: error: buffer_get_ret: trying to get more bytes 129 than in buffer 34 Jul 13 14:23:50 star-owamp sshd[1579]: error: buffer_get_string_ret: buffer_get failed Jul 13 14:23:50 star-owamp sshd[1579]: error: buffer_get_bignum2_ret: invalid bignum Jul 13 14:23:50 star-owamp sshd[1579]: error: key_from_blob: can't read rsa key Jul 13 14:23:50 star-owamp sshd[1579]: error: key_read: key_from_blob AAAAB3NzaC1yc2EAAAABIwAAAIEAuFblncD1qLy2QlnakQQATrrghSQmImjaLPRslTzG3Hn4\n failed Note that the login works, despite this error, but I don't like the error and I have no idea why I get this error only on certain systems. All systems are i386 and all are running v6, from a fairly old 6.1 from August 2006 to a 6.3-stable from yesterday. The one from yesterday is getting errors, but so are 6.1 systems from back in 2006. I've also tried installing OpenSSH-portable, but that did not seem to make a difference. Can anyone shed any light on what is happening? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080713/333a702b/attachment.pgp From sam at freebsd.org Sun Jul 13 22:16:29 2008 From: sam at freebsd.org (Sam Leffler) Date: Sun Jul 13 22:16:36 2008 Subject: Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7 In-Reply-To: <20080713112117.7d3ff6c6@web.de> References: <20080713112117.7d3ff6c6@web.de> Message-ID: <487A7EBB.5040203@freebsd.org> Martin wrote: > Hi Sam, > > do you know if there is anything done about cbb(4)? I have many > wireless adapters with ath(4), but only the one based on PCMCIA is > making problems on FreeBSD. > > I cannot boot my notebook with the device inserted into the port, or it > will render the system unusable (100% load on cbb(4)). > > And all I can see is the following: > Jul 12 14:58:39 link kernel: ath0: ath_chan_set: unable to reset channel 1 (2412 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:58:40 link kernel: ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 > Jul 12 14:58:41 link kernel: ath0: ath_chan_set: unable to reset channel 7 (2442 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 > Jul 12 14:58:42 link kernel: ath0: ath_chan_set: unable to reset channel 2 (2417 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:58:43 link kernel: ath0: ath_chan_set: unable to reset channel 3 (2422 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:58:44 link kernel: ath0: ath_chan_set: unable to reset channel 4 (2427 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 > Jul 12 14:58:45 link kernel: ath0: ath_chan_set: unable to reset channel 5 (2432 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:58:45 link kernel: ath0: ath_chan_set: unable to reset channel 8 (2447 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:58:46 link kernel: ath0: ath_chan_set: unable to reset channel 9 (2452 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:58:47 link kernel: ath0: ath_chan_set: unable to reset channel 10 (2457 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:58:52 link kernel: ath0: device timeout > Jul 12 14:58:52 link kernel: ath0: ath_reset: unable to reset hardware; hal status 3231908395 > Jul 12 14:58:58 link kernel: ath0: ath_chan_set: unable to reset channel 1 (2412 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 > Jul 12 14:58:59 link kernel: ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:59:00 link kernel: ath0: ath_chan_set: unable to reset channel 7 (2442 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:59:01 link kernel: ath0: ath_chan_set: unable to reset channel 2 (2417 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:59:01 link kernel: ath0: ath_chan_set: unable to reset channel 3 (2422 Mhz, flags 0x480 hal flags 0xc0), hal status 3289233408 > Jul 12 14:59:02 link kernel: ath0: ath_chan_set: unable to reset channel 4 (2427 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:59:03 link kernel: ath0: ath_chan_set: unable to reset channel 5 (2432 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:59:04 link kernel: ath0: ath_chan_set: unable to reset channel 8 (2447 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:59:05 link kernel: ath0: ath_chan_set: unable to reset channel 9 (2452 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:59:06 link kernel: ath0: ath_chan_set: unable to reset channel 10 (2457 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:59:10 link kernel: ath0: device timeout > Jul 12 14:59:10 link kernel: ath0: ath_reset: unable to reset hardware; hal status 3231908395 > Jul 12 14:59:11 link kernel: ath0: ath_chan_set: unable to reset channel 1 (2412 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 > Jul 12 14:59:12 link kernel: ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:59:13 link kernel: ath0: ath_chan_set: unable to reset channel 7 (2442 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 > Jul 12 14:59:14 link kernel: ath0: ath_chan_set: unable to reset channel 2 (2417 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:59:15 link kernel: ath0: ath_chan_set: unable to reset channel 3 (2422 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:59:16 link kernel: ath0: unable to reset hardware; hal status 3868687084 > Jul 12 14:59:16 link kernel: ath0: ath_chan_set: unable to reset channel 4 (2427 Mhz, flags 0x480 hal flags 0xc0), hal status 0 > Jul 12 14:59:17 link kernel: ath0: ath_chan_set: unable to reset channel 11 (2462 Mhz, flags 0x480 hal flags 0xc0), hal status 3828804624 > Jul 12 14:59:22 link kernel: ath0: unable to reset hardware; hal status 3868539700 > Jul 12 14:59:32 link kernel: ath0: unable to reset hardware; hal status 3868539700 > Jul 12 14:59:42 link kernel: ath0: unable to reset hardware; hal status 3868539700 > Jul 12 15:00:22 link last message repeated 4 times > Jul 12 15:00:32 link kernel: ath0: unable to reset hardware; hal status 3868539700 > Jul 12 15:00:42 link kernel: ath0: unable to reset hardware; hal status 3868539700 > Jul 12 15:00:52 link kernel: ath0: unable to reset hardware; hal status 3868539700 > > > wpa_supplicant is trying to access the card and switching channels, I > suppose. > > A workaround that I'm using all the time is: > 1) boot the notebook without the PCMCIA card > 2) after gdm appears, insert the card > > Also see: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/120376 > > In this PR I also described that you can panic the system, > while trying to fix the situation by reinserting the card. > But I found out, that you can always panic the system when > ejecting the card and wpa_supplicant is running. > Sorry I am not familiar enough with the cardbus support to comment. The zero status codes from ath_hal_reset are odd though. Inspecting the hal code it appears this can happen if the hal couldn't power up the chip which is consistent with the rest of the PR. Sam From sam at freebsd.org Sun Jul 13 22:19:35 2008 From: sam at freebsd.org (Sam Leffler) Date: Sun Jul 13 22:19:42 2008 Subject: Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7 In-Reply-To: <1215952634.1731.3.camel@RabbitsDen> References: <20080713112117.7d3ff6c6@web.de> <1215952634.1731.3.camel@RabbitsDen> Message-ID: <487A7F76.7000709@freebsd.org> Alexandre "Sunny" Kovalenko wrote: > On Sun, 2008-07-13 at 11:21 +0200, Martin wrote: >> Hi Sam, >> >> do you know if there is anything done about cbb(4)? I have many >> wireless adapters with ath(4), but only the one based on PCMCIA is >> making problems on FreeBSD. >> >> I cannot boot my notebook with the device inserted into the port, or it >> will render the system unusable (100% load on cbb(4)). >> >> And all I can see is the following: >> Jul 12 14:58:39 link kernel: ath0: ath_chan_set: unable to reset channel 1 (2412 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:58:40 link kernel: ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 >> Jul 12 14:58:41 link kernel: ath0: ath_chan_set: unable to reset channel 7 (2442 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 >> Jul 12 14:58:42 link kernel: ath0: ath_chan_set: unable to reset channel 2 (2417 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:58:43 link kernel: ath0: ath_chan_set: unable to reset channel 3 (2422 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:58:44 link kernel: ath0: ath_chan_set: unable to reset channel 4 (2427 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 >> Jul 12 14:58:45 link kernel: ath0: ath_chan_set: unable to reset channel 5 (2432 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:58:45 link kernel: ath0: ath_chan_set: unable to reset channel 8 (2447 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:58:46 link kernel: ath0: ath_chan_set: unable to reset channel 9 (2452 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:58:47 link kernel: ath0: ath_chan_set: unable to reset channel 10 (2457 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:58:52 link kernel: ath0: device timeout >> Jul 12 14:58:52 link kernel: ath0: ath_reset: unable to reset hardware; hal status 3231908395 >> Jul 12 14:58:58 link kernel: ath0: ath_chan_set: unable to reset channel 1 (2412 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 >> Jul 12 14:58:59 link kernel: ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:59:00 link kernel: ath0: ath_chan_set: unable to reset channel 7 (2442 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:59:01 link kernel: ath0: ath_chan_set: unable to reset channel 2 (2417 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:59:01 link kernel: ath0: ath_chan_set: unable to reset channel 3 (2422 Mhz, flags 0x480 hal flags 0xc0), hal status 3289233408 >> Jul 12 14:59:02 link kernel: ath0: ath_chan_set: unable to reset channel 4 (2427 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:59:03 link kernel: ath0: ath_chan_set: unable to reset channel 5 (2432 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:59:04 link kernel: ath0: ath_chan_set: unable to reset channel 8 (2447 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:59:05 link kernel: ath0: ath_chan_set: unable to reset channel 9 (2452 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:59:06 link kernel: ath0: ath_chan_set: unable to reset channel 10 (2457 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:59:10 link kernel: ath0: device timeout >> Jul 12 14:59:10 link kernel: ath0: ath_reset: unable to reset hardware; hal status 3231908395 >> Jul 12 14:59:11 link kernel: ath0: ath_chan_set: unable to reset channel 1 (2412 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 >> Jul 12 14:59:12 link kernel: ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:59:13 link kernel: ath0: ath_chan_set: unable to reset channel 7 (2442 Mhz, flags 0x480 hal flags 0xc0), hal status 3233070656 >> Jul 12 14:59:14 link kernel: ath0: ath_chan_set: unable to reset channel 2 (2417 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:59:15 link kernel: ath0: ath_chan_set: unable to reset channel 3 (2422 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:59:16 link kernel: ath0: unable to reset hardware; hal status 3868687084 >> Jul 12 14:59:16 link kernel: ath0: ath_chan_set: unable to reset channel 4 (2427 Mhz, flags 0x480 hal flags 0xc0), hal status 0 >> Jul 12 14:59:17 link kernel: ath0: ath_chan_set: unable to reset channel 11 (2462 Mhz, flags 0x480 hal flags 0xc0), hal status 3828804624 >> Jul 12 14:59:22 link kernel: ath0: unable to reset hardware; hal status 3868539700 >> Jul 12 14:59:32 link kernel: ath0: unable to reset hardware; hal status 3868539700 >> Jul 12 14:59:42 link kernel: ath0: unable to reset hardware; hal status 3868539700 >> Jul 12 15:00:22 link last message repeated 4 times >> Jul 12 15:00:32 link kernel: ath0: unable to reset hardware; hal status 3868539700 >> Jul 12 15:00:42 link kernel: ath0: unable to reset hardware; hal status 3868539700 >> Jul 12 15:00:52 link kernel: ath0: unable to reset hardware; hal status 3868539700 >> >> >> wpa_supplicant is trying to access the card and switching channels, I >> suppose. >> >> A workaround that I'm using all the time is: >> 1) boot the notebook without the PCMCIA card >> 2) after gdm appears, insert the card >> >> Also see: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/120376 >> >> In this PR I also described that you can panic the system, >> while trying to fix the situation by reinserting the card. >> But I found out, that you can always panic the system when >> ejecting the card and wpa_supplicant is running. >> > You can panic the box by unloading if_ath.ko while wpa_supplicant is > running on any form factor, so this one is not specific to the removable > devices. > The wpa_supplicant issue is due to the ioctl path racing against detach. I have a hack for this. The root cause is the ifnet code not handling ifdetach correctly. It doesn't happen in HEAD because of a slightly more general hack. Sam From ronald-freebsd8 at klop.yi.org Sun Jul 13 22:30:41 2008 From: ronald-freebsd8 at klop.yi.org (Ronald Klop) Date: Sun Jul 13 22:30:53 2008 Subject: trim src/UPDATING in RELENG_7? Message-ID: Hi, The file src/UPDATING in RELENG_7 goes back until 2004 (the RELENG_5 branchpoint) and is now almost 1000 lines long. Is it an idea to trim this file a bit? And to update this sentence: 'To upgrade in-place from 5.x-stable to current'? And footnote [5] seems a bit dated also. 'if you last updated from current before 20020224 or from -stable before 20020408.' Or is upgrading from 5.x to 7 also supported? Cheers, Ronald. From joseph.koshy at gmail.com Mon Jul 14 09:45:52 2008 From: joseph.koshy at gmail.com (Joseph Koshy) Date: Mon Jul 14 09:45:58 2008 Subject: Announcement: PmcTools callchain capture for RELENG_7 Message-ID: <84dead720807122205i33bf6eb0p998d473df9e52304@mail.gmail.com> Hello List(s), I am very pleased to announce a patch, by Fabien Thomas, that brings PmcTools' callchain capture features to 7-STABLE. Thank you, Fabien! The patch is linked to from the PmcTools wiki page: http://wiki.freebsd.org/PmcTools. The current file name is: "patch-callchain-FreeBSD-7-STABLE-2008-07-12.gz". As the file name indicates, it should apply against a 7-STABLE tree of 2008-07-12 vintage. To apply the patch: % cd /home/src-7x # or whereever your RELENG_7 tree resides % patch < PATCH-FILE Then you should follow the full procedure to update userland and kernel from source as spelled out in src/UPDATING. Please note that HWPMC(4) log files that contain callchain information are not binary compatible with prior versions of pmc(3) and pmcstat(8). Please do test on your systems and let Fabien and me know how you fared. Koshy From danny at cs.huji.ac.il Mon Jul 14 10:00:25 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Mon Jul 14 10:00:34 2008 Subject: Using iscsi with multiple targets In-Reply-To: <487A40FE.7030102@dmv.com> References: <487A40FE.7030102@dmv.com> Message-ID: > FreeBSD 7.0 > > I have 2 machines with identical configurations/hardware, let's call them A (master) > and B (slave). I have installed iscsi-target from ports and have set up 3 targets > representing the 3 drives I wish to be connected to from A. > > The Targets file: > # extents file start length > extent0 /dev/da1 0 465GB > extent1 /dev/da2 0 465GB > extent2 /dev/da3 0 465GB > > # target flags storage netmask > target0 rw extent0 192.168.0.1/24 > target1 rw extent1 192.168.0.1/24 > target2 rw extent2 192.168.0.1/24 > > I then start up iscsi_target and all is good. > > Now on A I have set up my /etc/iscsi.conf file as follows: > > # cat /etc/iscsi.conf > data1 { > targetaddress=192.168.0.252 > targetname=iqn.1994-04.org.netbsd.iscsi-target:target0 > initiatorname=iqn.2005-01.il.ac.huji.cs::BSD-2-1.sven.local > } > data2 { > targetaddress=192.168.0.252 > targetname=iqn.1994-04.org.netbsd.iscsi-target:target1 > initiatorname=iqn.2005-01.il.ac.huji.cs::BSD-2-1.sven.local > } > data3 { > targetaddress=192.168.0.252 > targetname=iqn.1994-04.org.netbsd.iscsi-target:target2 > initiatorname=iqn.2005-01.il.ac.huji.cs::BSD-2-1.sven.local > } > > So far so good, now come the issues. First of all, it would appear that with > iscontrol one can only start one "named" session at a time; for example > /sbin/iscontrol -n data1 > /sbin/iscontrol -n data2 > /sbin/isconrtol -n data3 > > I guess that is ok, except that each invocation of iscontrol resets the other > sessions. Here is the camcontrol and dmesg output from running the above 3 commands. > > # camcontrol devlist > at scbus0 target 0 lun 0 (pass0,da0) > at scbus0 target 1 lun 0 (pass1,da1) > at scbus0 target 2 lun 0 (pass2,da2) > at scbus0 target 3 lun 0 (pass3,da3) > at scbus1 target 0 lun 0 (da5,pass5) > at scbus1 target 1 lun 0 (da6,pass6) > at scbus1 target 2 lun 0 (da4,pass4) > > > [ /sbin/iscontrol -n data1 ] > da4 at iscsi0 bus 0 target 0 lun 0 > da4: Fixed Direct Access SCSI-3 device > > [ /sbin/iscontrol -n data2 ] > (da4:iscsi0:0:0:0): lost device > (da4:iscsi0:0:0:0): removing device entry > da4 at iscsi0 bus 0 target 0 lun 0 > da4: Fixed Direct Access SCSI-3 device > da5 at iscsi0 bus 0 target 1 lun 0 > da5: Fixed Direct Access SCSI-3 device > > [ /sbin/iscontrol -n data3 ] > (da4:iscsi0:0:0:0): lost device > (da4:iscsi0:0:0:0): removing device entry > (da5:iscsi0:0:1:0): lost device > (da5:iscsi0:0:1:0): removing device entry > da4 at iscsi0 bus 0 target 2 lun 0 > da4: Fixed Direct Access SCSI-3 device > da5 at iscsi0 bus 0 target 0 lun 0 > da5: Fixed Direct Access SCSI-3 device > da6 at iscsi0 bus 0 target 1 lun 0 > da6: Fixed Direct Access SCSI-3 device > > > It would appear that rather than appending the new device to the end of the "da" > devices, it starts to do some type of naming queue after the second device. If I am > to use these devices in any type of automated setup, how can make sure that after > these commands, "da6" will always be target 1 (i.e. /dev/da2 on the slave machine). > > Next, there is no "startup" script for iscontrol - would that simply have to be > added the system or is there a way with sysctl that it could be done. The plan here > is use gmirror such that /dev/da1 on A is mirrored with the /dev/da1 on B using iscsi. Hi Sven, I just tried it here, and it seems that at the end all is ok :-) I think the lost/removing/found has something to do to iscontrol calling camcontrol rescan - I will check this later, but the end result is that you should have all /dev/da's. I don't see any reasonable safe way to tie a scsi# (/dev/dan), except to label (see glabel) the disk. The startup script is, at the moment, not trivial, but I'm attaching it, so someone can suggest improvements :-) #!/bin/sh # PROVIDE: iscsi # REQUIRE: NETWORKING # BEFORE: DAEMON # KEYWORD: nojail shutdown # # Add the following lines to /etc/rc.conf to enable iscsi: # # iscsi_enable="YES" # iscsi_fstab="/etc/fstab.iscsi" . /etc/rc.subr . /cs/share/etc/rc.subr name=iscsi rcvar=`set_rcvar` command=/sbin/iscontrol iscsi_enable=${iscsi_enable:-"NO"} iscsi_fstab=${iscsi_fstab:-"/etc/fstab.iscsi"} iscsi_exports=${iscsi_exports:-"/etc/exports.iscsi"} iscsi_debug=${iscsi_debug:-0} start_cmd="iscsi_start" faststop_cmp="iscsi_stop" stop_cmd="iscsi_stop" start_precmd="iscontrol_precmd" iscontrol_prog=${iscontrol_prog:-"iscontrol"} iscontrol_log=${iscontrol_log:-"/var/log/$iscontrol_prog"} iscontrol_syslog=${iscontrol_syslog:-"644 3 100 * JC"} iscontrol_precmd() { setup_syslog "$iscontrol_prog" "$iscontrol_log" "$iscontrol_syslog" } iscsi_wait() { dev=$1 trap "echo 'wait loop cancelled'; exit 1" 2 count=0 while true; do if [ -c $dev ]; then break; fi if [ $count -eq 0 ]; then echo -n Waiting for ${dev}': ' fi count=$((${count} + 1)) if [ $count -eq 6 ]; then echo " Failed for dev=$dev" return 0 break fi echo -n '.' sleep 5; done echo "$dev ok." return 1 } iscsi_start() { # # load needed modules for m in iscsi_initiator geom_label; do kldstat -qm $m || kldload $m done sysctl debug.iscsi_initiator=$iscsi_debug # # start iscontrol for each target if [ -n "${iscsi_targets}" ]; then for target in ${iscsi_targets}; do ${command} ${rc_flags} -n ${target} done fi if [ -f "${iscsi_fstab}" ]; then while read spec file type opt t1 t2 do case ${spec} in \#*|'') ;; *) if iscsi_wait ${spec}; then break; fi echo type=$type spec=$spec file=$file fsck -p ${spec} && mkdir -p ${file} && mount ${spec} ${file} chmod 755 ${file} ;; esac done < ${iscsi_fstab} fi if [ -f "${iscsi_exports}" ]; then cat ${iscsi_exports} >> /etc/exports #/etc/rc.d/mountd reload kill -1 `cat /var/run/mountd.pid` fi } iscsi_stop() { echo 'iscsi stopping' while read spec file type opt t1 t2 do case ${spec} in \#*|'') ;; *) echo iscsi: umount $spec umount -fv $spec ;; esac done < ${iscsi_fstab} } load_rc_config $name run_rc_command "$1" From kris at FreeBSD.org Mon Jul 14 10:40:38 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Mon Jul 14 10:40:44 2008 Subject: trim src/UPDATING in RELENG_7? In-Reply-To: References: Message-ID: <487B2D25.9080502@FreeBSD.org> Ronald Klop wrote: > Hi, > > The file src/UPDATING in RELENG_7 goes back until 2004 (the RELENG_5 > branchpoint) and is now almost 1000 lines long. Is it an idea to trim > this file a bit? > > And to update this sentence: 'To upgrade in-place from 5.x-stable to > current'? > And footnote [5] seems a bit dated also. 'if you last updated from > current before 20020224 or from -stable before 20020408.' > > Or is upgrading from 5.x to 7 also supported? I think so, yes. Kris From andrewd at webzone.net.au Mon Jul 14 11:32:06 2008 From: andrewd at webzone.net.au (Andrew D) Date: Mon Jul 14 11:32:13 2008 Subject: trim src/UPDATING in RELENG_7? In-Reply-To: <487B2D25.9080502@FreeBSD.org> References: <487B2D25.9080502@FreeBSD.org> Message-ID: <487B36CA.2050102@webzone.net.au> Kris Kennaway wrote: > Ronald Klop wrote: >> Hi, >> >> The file src/UPDATING in RELENG_7 goes back until 2004 (the RELENG_5 >> branchpoint) and is now almost 1000 lines long. Is it an idea to trim >> this file a bit? >> >> And to update this sentence: 'To upgrade in-place from 5.x-stable to >> current'? >> And footnote [5] seems a bit dated also. 'if you last updated from >> current before 20020224 or from -stable before 20020408.' >> >> Or is upgrading from 5.x to 7 also supported? > > I think so, yes. > I've tried it on several test boxes and VMs and I couldn't get it too jump from 5.5 to 7.0. I had to go 5.5->6.3->7.0, not that it was much of a hassle. It came up with the same error every time. Though I don't have the logs of the error any more. Cheers Andrew > Kris > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From stefan.lambrev at moneybookers.com Mon Jul 14 11:57:48 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Mon Jul 14 11:58:05 2008 Subject: Announcement: PmcTools callchain capture for RELENG_7 In-Reply-To: <84dead720807122205i33bf6eb0p998d473df9e52304@mail.gmail.com> References: <84dead720807122205i33bf6eb0p998d473df9e52304@mail.gmail.com> Message-ID: <487B3F37.7000300@moneybookers.com> Hi, Does it mean that hwpmc from now will work "out of the box" with new Intel core2 duo/quad processors (like T7500) ? Joseph Koshy wrote: > Hello List(s), > > I am very pleased to announce a patch, by Fabien Thomas, that brings > PmcTools' callchain capture features to 7-STABLE. Thank you, Fabien! > > The patch is linked to from the PmcTools wiki page: > http://wiki.freebsd.org/PmcTools. > > The current file name is: "patch-callchain-FreeBSD-7-STABLE-2008-07-12.gz". > As the file name indicates, it should apply against a 7-STABLE tree of > 2008-07-12 > vintage. > > To apply the patch: > % cd /home/src-7x # or whereever your RELENG_7 tree resides > % patch < PATCH-FILE > > Then you should follow the full procedure to update userland > and kernel from source as spelled out in src/UPDATING. > > Please note that HWPMC(4) log files that contain callchain information are > not binary compatible with prior versions of pmc(3) and pmcstat(8). > > Please do test on your systems and let Fabien and me know > how you fared. > > Koshy > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Best Wishes, Stefan Lambrev ICQ# 24134177 From yraffah at sadeem.net Mon Jul 14 14:27:25 2008 From: yraffah at sadeem.net (Yousef Raffah) Date: Mon Jul 14 14:27:32 2008 Subject: Syncing or maybe update issue In-Reply-To: <790a9fff0807012003j1b187d3dr75496cd239696137@mail.gmail.com> References: <20080630110349.GA80339@eos.sc1.parodius.com> <790a9fff0807012003j1b187d3dr75496cd239696137@mail.gmail.com> Message-ID: <3C6EF275-B0F3-46D7-9A4A-31A6710C0629@sadeem.net> On Jul 2, 2008, at 6:03 AM, Scot Hetzel wrote: > On Tue, Jul 1, 2008 at 6:13 AM, Yousef Raffah > wrote: >> I guess I couldn't figure out how to checkout RELENG_7_0_0_RELEASE >> from the mirror >> freebsdanoncvs@anoncvs.FreeBSD.org:/home/ncvs >> I typed this: >> # cvs checkout -r RELENG_7_0_0_RELEASE src >> >> Can someone help with it, I can't spot an issue with the syntax but >> it >> is complaining saying: >> cvs [checkout aborted]: cannot write /home/ncvs/CVSROOT/val-tags: >> Permission denied > > Have a look at the handbook section: > > A.3 Using Anonymous CVS > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/anoncvs.html > Thanks, I just changed the mirror and everything worked fine :) From sorin.panca at psrk.com Mon Jul 14 15:30:15 2008 From: sorin.panca at psrk.com (=?UTF-8?B?U29yaW4gUMOibmNh?=) Date: Mon Jul 14 15:30:22 2008 Subject: Failure building apache22 and mysql51 In-Reply-To: References: Message-ID: <487B70A3.8020203@psrk.com> I'm sorry for my late response, I was on vacation. I think this was the case (although I thought we have only amd64 machines). Is there a way to recover from this situation by ssh access only? Thank you! Sorin. Chris Rees wrote: >> Date: Mon, 23 Jun 2008 18:43:04 +0300 >> From: Sorin P?nca > > >> Hello people! >> I recently upgraded a amd64 machine from FreeBSD-6.2-RELEASE-p11 to >> FreeBSD-7.0-RELEASE-p2 using the tutorial found at >> http://www.daemonology.net/blog/2007-11-11-freebsd-major-version-upgrade.html >> All went well with the base system. > > I don't want to patronise, but are you sure you were running > FreeBSD/amd64-6.2 before? Looks kinda like you've tried to upgrade > from 6.2/i386 to 7.0/amd64. In case you have, you can't do that. > > Check you haven't disabled and processor-specific extensions in your > BIOS, like SSE, that would also create problems if you have optimised > your ports. > > Chris > > > > > >> I thought devel/linuxthreads was using some old library so I tried to >> rebuild it: >> >> # cd ../../devel/linuxthreads && make install clean # portupgrade -f >> wouldn't do anything >> ===> linuxthreads-2.2.3_23 is only for i386, while you are running amd64. >> *** Error code 1 >> >> Stop in /usr/ports/devel/linuxthreads. >> >> >> Any ideas what to do next? >> Thank you! >> >> Sorin. >> From joseph.koshy at gmail.com Mon Jul 14 15:51:19 2008 From: joseph.koshy at gmail.com (Joseph Koshy) Date: Mon Jul 14 15:51:26 2008 Subject: Announcement: PmcTools callchain capture for RELENG_7 In-Reply-To: <487B3F37.7000300@moneybookers.com> References: <84dead720807122205i33bf6eb0p998d473df9e52304@mail.gmail.com> <487B3F37.7000300@moneybookers.com> Message-ID: <84dead720807140755s300e0158p16415ee3b9185840@mail.gmail.com> > Does it mean that hwpmc from now will work "out of the box" with new Intel > core2 duo/quad processors (like T7500) ? No, someone needs to write the appropriate CPU-dependent module for that. For those who are interested in doing so, there is a HowTo document at: http://wiki.freebsd.org/PmcTools/PmcHardwareHowTo Koshy From jfvogel at gmail.com Mon Jul 14 22:18:41 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Mon Jul 14 22:18:49 2008 Subject: igb doesn't compile in STABLE? In-Reply-To: References: Message-ID: <2a41acea0807141453s7235d894i31a744a0f673fcc0@mail.gmail.com> Just guessing, did someone change conf/files maybe?? Jack On Mon, Jul 14, 2008 at 2:44 PM, wrote: > Howdy, > > As of today, this afternoon, I see the following: > > linking kernel.debug > e1000_api.o(.text+0xad9): In function `e1000_setup_init_funcs': > ../../../dev/em/e1000_api.c:343: undefined reference to `e1000_init_function_pointers_80003es2lan' > e1000_api.o(.text+0xae8):../../../dev/em/e1000_api.c:340: undefined reference to `e1000_init_function_pointers_82571' > e1000_api.o(.text+0xafa):../../../dev/em/e1000_api.c:334: undefined reference to `e1000_init_function_pointers_82541' > e1000_api.o(.text+0xb0c):../../../dev/em/e1000_api.c:328: undefined reference to `e1000_init_function_pointers_82540' > e1000_api.o(.text+0xb1e):../../../dev/em/e1000_api.c:321: undefined reference to `e1000_init_function_pointers_82543' > e1000_api.o(.text+0xb30):../../../dev/em/e1000_api.c:316: undefined reference to `e1000_init_function_pointers_82542' > e1000_ich8lan.o(.text+0x98c): In function `e1000_valid_nvm_bank_detect_ich8lan': > ../../../dev/em/e1000_ich8lan.c:1032: undefined reference to `e1000_translate_register_82542' > e1000_ich8lan.o(.text+0xc32): In function `e1000_acquire_swflag_ich8lan': > ../../../dev/em/e1000_ich8lan.c:424: undefined reference to `e1000_translate_register_82542' > e1000_ich8lan.o(.text+0xc6e):../../../dev/em/e1000_ich8lan.c:426: undefined reference to `e1000_translate_register_82542' > e1000_ich8lan.o(.text+0xc9d):../../../dev/em/e1000_ich8lan.c:422: undefined reference to `e1000_translate_register_82542' > e1000_ich8lan.o(.text+0xced):../../../dev/em/e1000_ich8lan.c:436: undefined reference to `e1000_translate_register_82542' > e1000_ich8lan.o(.text+0x16bf):../../../dev/em/e1000_ich8lan.c:2700: more undefined references to `e1000_translate_register_82542' follow > *** Error code 1 > > > Thoughts? > > Later, > George > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From gnn at freebsd.org Mon Jul 14 22:25:56 2008 From: gnn at freebsd.org (gnn@freebsd.org) Date: Mon Jul 14 22:26:04 2008 Subject: igb doesn't compile in STABLE? Message-ID: Howdy, As of today, this afternoon, I see the following: linking kernel.debug e1000_api.o(.text+0xad9): In function `e1000_setup_init_funcs': ../../../dev/em/e1000_api.c:343: undefined reference to `e1000_init_function_pointers_80003es2lan' e1000_api.o(.text+0xae8):../../../dev/em/e1000_api.c:340: undefined reference to `e1000_init_function_pointers_82571' e1000_api.o(.text+0xafa):../../../dev/em/e1000_api.c:334: undefined reference to `e1000_init_function_pointers_82541' e1000_api.o(.text+0xb0c):../../../dev/em/e1000_api.c:328: undefined reference to `e1000_init_function_pointers_82540' e1000_api.o(.text+0xb1e):../../../dev/em/e1000_api.c:321: undefined reference to `e1000_init_function_pointers_82543' e1000_api.o(.text+0xb30):../../../dev/em/e1000_api.c:316: undefined reference to `e1000_init_function_pointers_82542' e1000_ich8lan.o(.text+0x98c): In function `e1000_valid_nvm_bank_detect_ich8lan': ../../../dev/em/e1000_ich8lan.c:1032: undefined reference to `e1000_translate_register_82542' e1000_ich8lan.o(.text+0xc32): In function `e1000_acquire_swflag_ich8lan': ../../../dev/em/e1000_ich8lan.c:424: undefined reference to `e1000_translate_register_82542' e1000_ich8lan.o(.text+0xc6e):../../../dev/em/e1000_ich8lan.c:426: undefined reference to `e1000_translate_register_82542' e1000_ich8lan.o(.text+0xc9d):../../../dev/em/e1000_ich8lan.c:422: undefined reference to `e1000_translate_register_82542' e1000_ich8lan.o(.text+0xced):../../../dev/em/e1000_ich8lan.c:436: undefined reference to `e1000_translate_register_82542' e1000_ich8lan.o(.text+0x16bf):../../../dev/em/e1000_ich8lan.c:2700: more undefined references to `e1000_translate_register_82542' follow *** Error code 1 Thoughts? Later, George From dillon at apollo.backplane.com Tue Jul 15 00:17:39 2008 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Tue Jul 15 00:17:47 2008 Subject: dvd dma problems References: <487A18E8.6010809@bsdforen.de> <20080713164033.GA97147@eos.sc1.parodius.com> Message-ID: <200807150017.m6F0HD7m000582@apollo.backplane.com> :> quite fine from 5.3 to somewhere in the 6.x branch. Nowadays I have to send :> them to PIO4 to play DVDs, because they'll just throw DMA not aligned errors :> around in UDMA33 or WDMA2 mode. :> :> Should someone be interested in this I'm willing to supply all necessary :> information, such as the exact drives, firmware versions, kernel traces... :> whatever comes to your mind. I'm also willing to test patches. : :Is the problem you're seeing identical to this? : :http://lists.freebsd.org/pipermail/freebsd-hackers/2008-July/025297.html : :-- :| Jeremy Chadwick jdc at parodius.com | One of our guys (in DragonFly-land) tracked this down two two issues, fixing either one will fix the problem. I'd include a patch but he has not finished it yet. Still, anyone with moderate kernel programming skills can probably fix it in an hour or less. physio() - uses vmapbuf(). vmapbuf() does NOT realign the user address, it simply maps it into the buffer and adjusts b_data. So if the user supplies a badly aligned buffer, physio() will happily pass that bad alignment to the driver. physio() could be modified to allocate kernel memory to back the pbuf and copy instead of calling vmapbuf(), for those cases where the user supplied buffer is not well aligned (e.g. not at least 512-byte aligned). The pbuf already reserve KVA so all one would need to do is allocate pages to back the KVA space. I think a couple of other subsystems in the kernel do this with pbufs so there is plenty of example material. -- The ATA driver has an explicit alignment check and also uses BUS_DMA_NOWAIT in its call to bus_dmamap_load() in ata_dmaload(). The ATA driver could be adjusted to remove the alignment check, remove the BUS_DMA_NOWAIT flag, and also not free the bounce buffer when DMA ends (so you don't get allocator deadlocks). You might have other issues related to lock ordering, and this solution would eat a considerable amount of memory (upwards of a megabyte, more if you have more ATA channels), but that's the jist of it. It should be noted that only physio() can supply unaligned BIOs to the driver layer. All other BIO sources (that I know of) will always be at least 512-byte aligned. -- My recommendation is to fix physio(). User programs that do not supply aligned buffers clearly don't care about performance, so the kernel can just back the pbuf with memory and copyin/out the user data. -Matt Matthew Dillon From delphij at delphij.net Tue Jul 15 02:40:58 2008 From: delphij at delphij.net (Xin LI) Date: Tue Jul 15 02:41:06 2008 Subject: snd_hda(freebsd 7.0 rc1) doesn't work on dell latitude D630 In-Reply-To: <477DF250.8020407@gmx.net> References: <576dcbc20801040037n511b343cgd4447de57a24089@mail.gmail.com> <477DF250.8020407@gmx.net> Message-ID: <487C0E2F.9040207@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Frank Staals wrote: [...] | I have a similar problem (also with a D630 ) ; I only get sound when | plugging in a headset or similar. Sound won't work over the internal | speakers. I also tried the oss drivers, without | success though: at the time ( about a month ago ) it even locked up my | system. | | frank@Rena# uname -a | FreeBSD Rena.FStaals.net 7.0-BETA4 FreeBSD 7.0-BETA4 #0: Fri Dec 21 | 11:48:15 CET 2007 | frank@Rena.FStaals.net:/usr/obj/usr/src/sys/RENAKERNEL i386 I have just committed a changeset as 180532 which are essentially quirks that recognize and sets some parameters for D630. With Ariff's latest work on -CURRENT, it should make D630's audio work. If you use -STABLE, please do the following: 1. Checkout /sys/dev/sound from -HEAD, either svn or cvs should work; 2. Do a s,kproc_,kthread_,g replace over the code; 3. Recompile /sys/modules/sound. My plan is to MFC all these changes next week. Please let me know if you have any problems. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkh8Di8ACgkQi+vbBBjt66BqnwCguuLtg7mT5Nxn80T2Ci8eNrkw HW0An3m3qhcIZCImGsTQY/FS4/vsH2NX =hrAP -----END PGP SIGNATURE----- From mike.derouen at gmail.com Tue Jul 15 03:02:51 2008 From: mike.derouen at gmail.com (Mike Derouen) Date: Tue Jul 15 03:02:58 2008 Subject: Nexuiz-2.4.2 Server Browser and sockets "sendto" error Message-ID: Hello, I have recently installed the nexuiz-2.4.2 port and the single player game works great. The multiplayer mode, however, is not working properly. When i look at the server browser, there aren't any games listed, and I don't see a way to add servers or refresh the list. I also keep getting this sockets error in the console: "LHNET_Write: sendto returned error: Address family not supported by protocol family" Here's my uname output: % uname -a FreeBSD alpha 7.0-STABLE FreeBSD 7.0-STABLE #4: Mon Jul 14 19:09:46 PDT 2008 root@alpha:/usr/obj/usr/src/sys/GENERIC i386 Does anybody have an idea of how to fix this? I have tried to do a "connect" from the console of a single player game, but that gave the same result. I have successfully connected to multiplayer quake3 games on a few different servers, so I'm taking a stab in the dark and guessing that the problem may be with the nexuiz port. Please let me know what extra useful info I can provide as well. Thanks, Mike From john at basicnets.co.uk Tue Jul 15 10:15:03 2008 From: john at basicnets.co.uk (John Sullivan) Date: Tue Jul 15 10:15:10 2008 Subject: Fresh 7.0 Install: Fatal Trap 12 panic when put under load Message-ID: <854CADB9D95147CAB10BC35887A8E5DC@emea.hubersuhner.net> I am experiencing 'random' reboots interspersed with panics whenever I put a newly installed system under load (make index in /usr/ports is enough). A sample panic is at the end of this email. I have updated to 7.0-RELEASE-p2 using the GENERIC amd64 kernel and it is still the same. The system is a Gigabyte GA-M56S-S3 motherboard with 4GB of RAM, an Athlon X2 6400+ and 3 x Maxtor SATA 750GB HDD's (only the first is currently in use). The first disk is all allocated to FreeBSD using UFS. There is also a Linksys 802.11a/b/g card installed. I have flashed the BIOS to the latest revision (F4e). The onboard RAID is disabled. At the moment there is no exotic software installed. Although I have been using FreeBSD for a number of years this is the first time I have experienced regular panics and am at a complete loss trying to work out what is wrong. I would be grateful for any advice anyone is willing to give to help me troubleshoot this issue. Thanks in advance John Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x800000b0 fault code - supervisor write data, page not present instruction pointer = 0x8:0xffffffff804db18c stack pointer = 0x10:ffffffffb1e92450 frame pointer = 0x10:ffffffec code segment = base 0x0, limit 0xfffff, type 0x16, DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interupt enabled, resume, IOPL = 0 current processkernel trap 12 with interrupts disabled #nm -n /boot/kernel/kernel | grep ffffffff804db ffffffff804dbac0 t flushbufqueues From koitsu at FreeBSD.org Tue Jul 15 10:21:35 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Jul 15 10:21:42 2008 Subject: Fresh 7.0 Install: Fatal Trap 12 panic when put under load In-Reply-To: <854CADB9D95147CAB10BC35887A8E5DC@emea.hubersuhner.net> References: <854CADB9D95147CAB10BC35887A8E5DC@emea.hubersuhner.net> Message-ID: <20080715102135.GA18082@eos.sc1.parodius.com> On Tue, Jul 15, 2008 at 10:58:19AM +0100, John Sullivan wrote: > I am experiencing 'random' reboots interspersed with panics whenever I put a newly installed system under load (make index in > /usr/ports is enough). A sample panic is at the end of this email. > > I have updated to 7.0-RELEASE-p2 using the GENERIC amd64 kernel and it is still the same. The system is a Gigabyte GA-M56S-S3 > motherboard with 4GB of RAM, an Athlon X2 6400+ and 3 x Maxtor SATA 750GB HDD's (only the first is currently in use). The first > disk is all allocated to FreeBSD using UFS. There is also a Linksys 802.11a/b/g card installed. I have flashed the BIOS to the > latest revision (F4e). The onboard RAID is disabled. > > At the moment there is no exotic software installed. > > Although I have been using FreeBSD for a number of years this is the first time I have experienced regular panics and am at a > complete loss trying to work out what is wrong. I would be grateful for any advice anyone is willing to give to help me > troubleshoot this issue. Can the system in question run memtest86+ successfully (no errors) for an hour? It would help diminish (but not entirely rule out) hardware (memory or chipset) issues. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From john at basicnets.co.uk Tue Jul 15 10:28:29 2008 From: john at basicnets.co.uk (John Sullivan) Date: Tue Jul 15 10:28:36 2008 Subject: Fresh 7.0 Install: Fatal Trap 12 panic when put under load In-Reply-To: <20080715102135.GA18082@eos.sc1.parodius.com> References: <854CADB9D95147CAB10BC35887A8E5DC@emea.hubersuhner.net> <20080715102135.GA18082@eos.sc1.parodius.com> Message-ID: > Can the system in question run memtest86+ successfully (no > errors) for an hour? It would help diminish (but not > entirely rule out) hardware (memory or chipset) issues. Sorry, forgot to mention, I ran memtest over night without any problem reported. I ran Fedora 9 for a month without any issue - FreeBSD 7.0 crashes within an hour. John From kris at FreeBSD.org Tue Jul 15 11:05:43 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Tue Jul 15 11:05:50 2008 Subject: Fresh 7.0 Install: Fatal Trap 12 panic when put under load In-Reply-To: References: <854CADB9D95147CAB10BC35887A8E5DC@emea.hubersuhner.net> <20080715102135.GA18082@eos.sc1.parodius.com> Message-ID: <487C8486.1040904@FreeBSD.org> John Sullivan wrote: > >> Can the system in question run memtest86+ successfully (no >> errors) for an hour? It would help diminish (but not >> entirely rule out) hardware (memory or chipset) issues. > > Sorry, forgot to mention, I ran memtest over night without any problem reported. I ran Fedora 9 for a month without any issue - > FreeBSD 7.0 crashes within an hour. Well, that doesn't rule out hardware failure. Different OSes may use different capabilities of the hardware, or just use it in a different way, and that can provoke failures from marginal hardware. Please collect kgdb/ddb backtraces. Kris From sven at dmv.com Tue Jul 15 13:45:33 2008 From: sven at dmv.com (Sven Willenberger) Date: Tue Jul 15 13:45:41 2008 Subject: Using iscsi with multiple targets In-Reply-To: References: <487A40FE.7030102@dmv.com> Message-ID: <1216129506.27608.8.camel@lanshark.dmv.com> On Mon, 2008-07-14 at 11:29 +0300, Danny Braniss wrote: > > FreeBSD 7.0 > > > > I have 2 machines with identical configurations/hardware, let's call them A (master) > > and B (slave). I have installed iscsi-target from ports and have set up 3 targets > > representing the 3 drives I wish to be connected to from A. > > > > The Targets file: > > # extents file start length > > extent0 /dev/da1 0 465GB > > extent1 /dev/da2 0 465GB > > extent2 /dev/da3 0 465GB > > > > # target flags storage netmask > > target0 rw extent0 192.168.0.1/24 > > target1 rw extent1 192.168.0.1/24 > > target2 rw extent2 192.168.0.1/24 > > > > I then start up iscsi_target and all is good. > > > > Now on A I have set up my /etc/iscsi.conf file as follows: > > > > # cat /etc/iscsi.conf > > data1 { > > targetaddress=192.168.0.252 > > targetname=iqn.1994-04.org.netbsd.iscsi-target:target0 > > initiatorname=iqn.2005-01.il.ac.huji.cs::BSD-2-1.sven.local > > } > > data2 { > > targetaddress=192.168.0.252 > > targetname=iqn.1994-04.org.netbsd.iscsi-target:target1 > > initiatorname=iqn.2005-01.il.ac.huji.cs::BSD-2-1.sven.local > > } > > data3 { > > targetaddress=192.168.0.252 > > targetname=iqn.1994-04.org.netbsd.iscsi-target:target2 > > initiatorname=iqn.2005-01.il.ac.huji.cs::BSD-2-1.sven.local > > } > > > > So far so good, now come the issues. First of all, it would appear that with > > iscontrol one can only start one "named" session at a time; for example > > /sbin/iscontrol -n data1 > > /sbin/iscontrol -n data2 > > /sbin/isconrtol -n data3 > > > > I guess that is ok, except that each invocation of iscontrol resets the other > > sessions. Here is the camcontrol and dmesg output from running the above 3 commands. > > > > # camcontrol devlist > > at scbus0 target 0 lun 0 (pass0,da0) > > at scbus0 target 1 lun 0 (pass1,da1) > > at scbus0 target 2 lun 0 (pass2,da2) > > at scbus0 target 3 lun 0 (pass3,da3) > > at scbus1 target 0 lun 0 (da5,pass5) > > at scbus1 target 1 lun 0 (da6,pass6) > > at scbus1 target 2 lun 0 (da4,pass4) > > > > > > [ /sbin/iscontrol -n data1 ] > > da4 at iscsi0 bus 0 target 0 lun 0 > > da4: Fixed Direct Access SCSI-3 device > > > > [ /sbin/iscontrol -n data2 ] > > (da4:iscsi0:0:0:0): lost device > > (da4:iscsi0:0:0:0): removing device entry > > da4 at iscsi0 bus 0 target 0 lun 0 > > da4: Fixed Direct Access SCSI-3 device > > da5 at iscsi0 bus 0 target 1 lun 0 > > da5: Fixed Direct Access SCSI-3 device > > > > [ /sbin/iscontrol -n data3 ] > > (da4:iscsi0:0:0:0): lost device > > (da4:iscsi0:0:0:0): removing device entry > > (da5:iscsi0:0:1:0): lost device > > (da5:iscsi0:0:1:0): removing device entry > > da4 at iscsi0 bus 0 target 2 lun 0 > > da4: Fixed Direct Access SCSI-3 device > > da5 at iscsi0 bus 0 target 0 lun 0 > > da5: Fixed Direct Access SCSI-3 device > > da6 at iscsi0 bus 0 target 1 lun 0 > > da6: Fixed Direct Access SCSI-3 device > > > > > > It would appear that rather than appending the new device to the end of the "da" > > devices, it starts to do some type of naming queue after the second device. If I am > > to use these devices in any type of automated setup, how can make sure that after > > these commands, "da6" will always be target 1 (i.e. /dev/da2 on the slave machine). > > > > Next, there is no "startup" script for iscontrol - would that simply have to be > > added the system or is there a way with sysctl that it could be done. The plan here > > is use gmirror such that /dev/da1 on A is mirrored with the /dev/da1 on B using iscsi. > > Hi Sven, > I just tried it here, and it seems that at the end all is ok :-) > I think the lost/removing/found has something to do to iscontrol calling > camcontrol rescan - I will check this later, but the end result is that > you should have all /dev/da's. > I don't see any reasonable safe way to tie a scsi# (/dev/dan), > except to label (see glabel) the disk. > The startup script is, at the moment, not trivial, but I'm attaching > it, so someone can suggest improvements :-) > #!/bin/sh > > # PROVIDE: iscsi > # REQUIRE: NETWORKING > # BEFORE: DAEMON > # KEYWORD: nojail shutdown > > # > # Add the following lines to /etc/rc.conf to enable iscsi: > # > # iscsi_enable="YES" > # iscsi_fstab="/etc/fstab.iscsi" > > . /etc/rc.subr > . /cs/share/etc/rc.subr > > name=iscsi > rcvar=`set_rcvar` > > command=/sbin/iscontrol > > iscsi_enable=${iscsi_enable:-"NO"} > iscsi_fstab=${iscsi_fstab:-"/etc/fstab.iscsi"} > iscsi_exports=${iscsi_exports:-"/etc/exports.iscsi"} > iscsi_debug=${iscsi_debug:-0} > start_cmd="iscsi_start" > faststop_cmp="iscsi_stop" > stop_cmd="iscsi_stop" > > start_precmd="iscontrol_precmd" > iscontrol_prog=${iscontrol_prog:-"iscontrol"} > iscontrol_log=${iscontrol_log:-"/var/log/$iscontrol_prog"} > iscontrol_syslog=${iscontrol_syslog:-"644 3 100 * JC"} > > iscontrol_precmd() > { > setup_syslog "$iscontrol_prog" "$iscontrol_log" "$iscontrol_syslog" > } > > iscsi_wait() > { > dev=$1 > trap "echo 'wait loop cancelled'; exit 1" 2 > count=0 > while true; do > if [ -c $dev ]; then > break; > fi > if [ $count -eq 0 ]; then > echo -n Waiting for ${dev}': ' > fi > count=$((${count} + 1)) > if [ $count -eq 6 ]; then > echo " Failed for dev=$dev" > return 0 > break > fi > echo -n '.' > sleep 5; > done > echo "$dev ok." > return 1 > } > > iscsi_start() > { > # > # load needed modules > for m in iscsi_initiator geom_label; do > kldstat -qm $m || kldload $m > done > > sysctl debug.iscsi_initiator=$iscsi_debug > # > # start iscontrol for each target > if [ -n "${iscsi_targets}" ]; then > for target in ${iscsi_targets}; do > ${command} ${rc_flags} -n ${target} > done > fi > > if [ -f "${iscsi_fstab}" ]; then > while read spec file type opt t1 t2 > do > case ${spec} in > \#*|'') > ;; > *) > if iscsi_wait ${spec}; then > break; > fi > echo type=$type spec=$spec file=$file > fsck -p ${spec} && mkdir -p ${file} && mount ${spec} ${file} > chmod 755 ${file} > ;; > esac > done < ${iscsi_fstab} > fi > > if [ -f "${iscsi_exports}" ]; then > cat ${iscsi_exports} >> /etc/exports > #/etc/rc.d/mountd reload > kill -1 `cat /var/run/mountd.pid` > fi > } > > iscsi_stop() > { > echo 'iscsi stopping' > while read spec file type opt t1 t2 > do > case ${spec} in > \#*|'') > ;; > *) > echo iscsi: umount $spec > umount -fv $spec > ;; > esac > done < ${iscsi_fstab} > } > > load_rc_config $name > run_rc_command "$1" Thanks for the script and information. I have found that so long as I add the targets in the same order each time (i.e. iscontrol -n data1, then data2, then data3) the actual scsi target will be the same even though the device number will change. So if I do something like: camcontrol devlist | grep "scbus1 target 0" | sed 's/^.*da\(.\).*/da\1/' I can parse out the device number it was assigned. After some other reports it would appear as though iscsi will not work for my needs (which basically involves creating a mirrored pool/filesystem spanning 2 machines) as iscsi will lock when the target machine goes down. I will continue this in a new thread as it strays from the question originally asked here. Sven -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080715/f647aae6/attachment.pgp From support at corp.scour.com Tue Jul 15 14:01:51 2008 From: support at corp.scour.com (S. M. Ibrahim lavlu) Date: Tue Jul 15 14:02:05 2008 Subject: Scour.com invite from S. M. Ibrahim lavlu Message-ID: <20080715134135.93F0093894@www1.scour.com> Hey, Did you hear about Scour? It is the next gen search engine with Google/Yahoo/MSN results and user comments all on one page. Best of all we get paid for using it by earning points with every search, comment and vote. The points are redeemable for Visa gift cards! It's like earning credit card or airline points just for searching! Hit the link below to join for free and we will both get points! U http://scour.com/invite/lavluda/ I know you'll like it! - S. M. Ibrahim lavlu From support at corp.scour.com Tue Jul 15 14:02:37 2008 From: support at corp.scour.com (S. M. Ibrahim lavlu) Date: Tue Jul 15 14:02:43 2008 Subject: Scour.com invite from S. M. Ibrahim lavlu Message-ID: <20080715134351.02BF593D13@www1.scour.com> Hey, Did you hear about Scour? It is the next gen search engine with Google/Yahoo/MSN results and user comments all on one page. Best of all we get paid for using it by earning points with every search, comment and vote. The points are redeemable for Visa gift cards! It's like earning credit card or airline points just for searching! Hit the link below to join for free and we will both get points! U http://scour.com/invite/lavluda/ I know you'll like it! - S. M. Ibrahim lavlu From sven at dmv.com Tue Jul 15 14:07:16 2008 From: sven at dmv.com (Sven Willenberger) Date: Tue Jul 15 14:07:23 2008 Subject: Multi-machine mirroring choices Message-ID: <1216130834.27608.27.camel@lanshark.dmv.com> With the introduction of zfs to FreeBSD 7.0, a door has opened for more mirroring options so I would like to get some opinions on what direction I should take for the following scenario. Basically I have 2 machines that are "clones" of each other (master and slave) wherein one will be serving up samba shares. Each server has one disk to hold the OS (not mirrored) and then 3 disks, each of which will be its own mountpoint and samba share. The idea is to create a mirror of each of these disks on the slave machine so that in the event the master goes down, the slave can pick up serving the samba shares (I am using CARP as the samba server IP address). My initial thought was to have the slave set up as an iscsi target and then have the master connect to each drive, then create a gmirror or zpool mirror using local_data1:iscsi_data1, local_data2:iscsi_data2, and local_data3:iscsi_data3. After some feedback (P.French for example) it would appear as though iscsi may not be the way to go for this as it locks up when the target goes down and even though I may be able to remove the target from the mirror, that process may fail as the "disk" remains in "D" state. So that leaves me with the following options: 1) ggated/ggatec + gmirror 2) ggated/ggatec + zfs (zpool mirror) 3) zfs send/recv incremental snapshots (ssh) 1) I have been using ggated/ggatec on a set of 6.2-REL boxes and find that ggated tends to fail after some time leaving me rebuilding the mirror periodically (and gmirror resilvering takes quite some time). Has ggated/ggatec performance and stability improved in 7.0? This combination does work, but it is high maintenance and automating it is a bit painful (in terms of re-establishing the gmirror and rebuilding and making sure the master machine is the one being read from). 2) Noting the issues with ggated/ggatec in (1), would a zpool be better at rebuilding the mirror? I understand that it can better determine which drive of the mirror is out of sync than can gmirror so a lot of the "insert" "rebuild" manipulations used with gmirror would not be needed here. 3) The send/recv feature of zfs was something I had not even considered until very recently. My understanding is that this would work by a) taking a snapshot of master_data1 b) zfs sending that snapshot to slave_data1 c) via ssh on pipe, receiving that snapshot on slave_data1 and then d) doing incremental snapshots, sending, receiving as in (a)(b)(c). How time/cpu intensive is the snapshot generation and just how granular could this be done? I would imagine for systems with litle traffic/changes this could be practical but what about systems that may see a lot of files added, modified, deleted to the filesystem(s)? I would be interested to hear anyone's experience with any (or all) of these methods and caveats of each. I am leaning towards ggate(dc) + zpool at the moment assuming that zfs can "smartly" rebuild the mirror after the slave's ggated processes bug out. Sven -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080715/a82cdc0a/attachment.pgp From koitsu at FreeBSD.org Tue Jul 15 14:54:27 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Jul 15 14:54:33 2008 Subject: Multi-machine mirroring choices In-Reply-To: <1216130834.27608.27.camel@lanshark.dmv.com> References: <1216130834.27608.27.camel@lanshark.dmv.com> Message-ID: <20080715145426.GA31340@eos.sc1.parodius.com> On Tue, Jul 15, 2008 at 10:07:14AM -0400, Sven Willenberger wrote: > 3) The send/recv feature of zfs was something I had not even considered > until very recently. My understanding is that this would work by a) > taking a snapshot of master_data1 b) zfs sending that snapshot to > slave_data1 c) via ssh on pipe, receiving that snapshot on slave_data1 > and then d) doing incremental snapshots, sending, receiving as in > (a)(b)(c). How time/cpu intensive is the snapshot generation and just > how granular could this be done? I would imagine for systems with litle > traffic/changes this could be practical but what about systems that may > see a lot of files added, modified, deleted to the filesystem(s)? I can speak a bit on ZFS snapshots, because I've used them in the past with good results. Compared to UFS2 snapshots (e.g. dump -L or mksnap_ffs), ZFS snapshots are fantastic. The two main positives for me were: 1) ZFS snapshots take significantly less time to create; I'm talking seconds or minutes vs. 30-45 minutes. I also remember receiving mail from someone (on -hackers? I can't remember -- let me know and I can dig through my mail archives for the specific mail/details) stating something along the lines of "over time, yes, UFS2 snapshots take longer and longer, it's a known design problem". 2) ZFS snapshots, when created, do not cause the system to more or less deadlock until the snapshot is generated; you can continue to use the system during the time the snapshot is being generated. While with UFS2, dump -L and mksnap_ffs will surely disappoint you. We moved all of our production systems off of using dump/restore solely because of these aspects. We didn't move to ZFS though; we went with rsync, which is great, except for the fact that it modifies file atimes (hope you use Maildir and not classic mbox/mail spools...). ZFS's send/recv capability (over a network) is something I didn't have time to experiment with, but it looked *very* promising. The method is documented in the manpage as "Example 12", and is very simple -- as it should be. You don't have to use SSH either, by the way[1]. One of the "annoyances" to ZFS snapshots, however, was that I had to write my own script to do snapshot rotations (think incremental dump(8) but using ZFS snapshots). > I would be interested to hear anyone's experience with any (or all) of > these methods and caveats of each. I am leaning towards ggate(dc) + > zpool at the moment assuming that zfs can "smartly" rebuild the mirror > after the slave's ggated processes bug out. I don't have any experience with GEOM gate, so I can't comment on it. But I would highly recommend you discuss the shortcomings with pjd@, because he definitely listens. However, I must ask you this: why are you doing things the way you are? Why are you using the equivalent of RAID 1 but for entire computers? Is there some reason you aren't using a filer (e.g. NetApp) for your data, thus keeping it centralised? There has been recent discussion of using FreeBSD with ZFS as such, over on freebsd-fs. If you want a link to the thread, I can point you to it. I'd like to know why you're doing things the way you are. By knowing why, possibly myself or others could recommend solving the problem in a different way -- one that doesn't involve realtime duplication of filesystems via network. [1]: If you're transferring huge sums of data over a secure link (read: dedicated gigE LAN or a separate VLAN), you'll be disappointed to find that there is no Cipher=none with stock SSH; the closest you'll get is blowfish-cbc. You might be saddened by the fact that the only way you'll get Cipher=none is via the HPN patches, which means you'll be forced to install ports/security/openssh-portable. (I am not a fan of the "overwrite the base system" concept; it's a hack, and I'd rather get rid of the whole "base system" concept in general -- but that's for another discussion). My point is, your overall network I/O will be limited by SSH, so if you're pushing lots of data across a LAN, consider something without encryption. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From kris at FreeBSD.org Tue Jul 15 15:06:50 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Tue Jul 15 15:06:57 2008 Subject: Multi-machine mirroring choices In-Reply-To: <20080715145426.GA31340@eos.sc1.parodius.com> References: <1216130834.27608.27.camel@lanshark.dmv.com> <20080715145426.GA31340@eos.sc1.parodius.com> Message-ID: <487CBD0A.6050207@FreeBSD.org> Jeremy Chadwick wrote: > Compared to UFS2 snapshots (e.g. dump -L or mksnap_ffs), ZFS snapshots > are fantastic. The two main positives for me were: > > 1) ZFS snapshots take significantly less time to create; I'm talking > seconds or minutes vs. 30-45 minutes. I also remember receiving mail > from someone (on -hackers? I can't remember -- let me know and I can > dig through my mail archives for the specific mail/details) stating > something along the lines of "over time, yes, UFS2 snapshots take > longer and longer, it's a known design problem". > > 2) ZFS snapshots, when created, do not cause the system to more or less > deadlock until the snapshot is generated; you can continue to use the > system during the time the snapshot is being generated. While with > UFS2, dump -L and mksnap_ffs will surely disappoint you. "a known design problem" in the sense of "intentional", yes. They were written to support bg fsck, not as a lightweight filesystem feature for general use. Kris From petefrench at ticketswitch.com Tue Jul 15 15:20:35 2008 From: petefrench at ticketswitch.com (Pete French) Date: Tue Jul 15 15:20:42 2008 Subject: Multi-machine mirroring choices In-Reply-To: <20080715145426.GA31340@eos.sc1.parodius.com> Message-ID: > However, I must ask you this: why are you doing things the way you are? > Why are you using the equivalent of RAID 1 but for entire computers? Is > there some reason you aren't using a filer (e.g. NetApp) for your data, > thus keeping it centralised? I am not the roiginal poster, but I am doing something very similar and can answer that question for you. Some people get paranoid about the whole "single point of failure" thing. I originally suggestted that we buy a filer and have identical servers so if one breaks we connect the other to the filer, but the response I got was "what if the filer breaks?". So in the end I had to show we have duplicate independent machines, with the data kept symetrical on them at all times. It does actually work quite nicely actually - I have an "'active" database machine, and a "passive". The opassive is only used if the active fails, and the drives are run as a gmirror pair with the remote one being mounted using ggated. It also means I can flip from active to passive when I want to do an OS upgrade on the active machine. Switching takes a few seconds, and this is fine for our setup. So the answer is that the descisiuon was taken out of my hands - but this is not uncommon, and as a roll-your-own cluster it works very nicely. -pete. From olli at lurza.secnetix.de Tue Jul 15 15:23:24 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Tue Jul 15 15:23:31 2008 Subject: Multi-machine mirroring choices In-Reply-To: <1216130834.27608.27.camel@lanshark.dmv.com> Message-ID: <200807151523.m6FFNIRJ044047@lurza.secnetix.de> Sven Willenberger wrote: > [...] > 1) I have been using ggated/ggatec on a set of 6.2-REL boxes and find > that ggated tends to fail after some time leaving me rebuilding the > mirror periodically (and gmirror resilvering takes quite some time). Has > ggated/ggatec performance and stability improved in 7.0? This > combination does work, but it is high maintenance and automating it is a > bit painful (in terms of re-establishing the gmirror and rebuilding and > making sure the master machine is the one being read from). First, some problems in ggated/ggatec have been fixed between 6.2 and 6.3. Second, you should tune it a little to improve performance and stability. The following reply in an earlier thread is interesting: http://lists.freebsd.org/pipermail/freebsd-stable/2008-January/039722.html > 2) Noting the issues with ggated/ggatec in (1), would a zpool be better > at rebuilding the mirror? I understand that it can better determine > which drive of the mirror is out of sync than can gmirror so a lot of > the "insert" "rebuild" manipulations used with gmirror would not be > needed here. I don't think there's much of a difference between gmirror and a ZFS mirror if used with ggated/ggatec. Of course, ZFS has more advantages, like checksumming, snapshots etc., but also the disadvantages that it requires considerably more memory. Yet another way would be to use DragoFly's "Hammer" file system which is part of DragonFly BSD 2.0 which will be released in a few days. It supports remote mirroring, i.e. mirror source and mirror target can run on different machines. Of course it is still very new and experimental (however, ZFS is marked experimental, too), so you probably don't want to use it on critical production machines. (YMMV, of course.) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd PI: int f[9814],b,c=9814,g,i;long a=1e4,d,e,h; main(){for(;b=c,c-=14;i=printf("%04d",e+d/a),e=d%a) while(g=--b*2)d=h*b+a*(i?f[b]:a/5),h=d/--g,f[b]=d%g;} From olli at lurza.secnetix.de Tue Jul 15 15:35:20 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Tue Jul 15 15:35:26 2008 Subject: how to get more logging from GEOM? In-Reply-To: Message-ID: <200807151535.m6FFZH4P044840@lurza.secnetix.de> Jo Rhett wrote: > About 10 days ago one of my personal machines started hanging at > random. This is the first bit of instability I've ever experienced on > this machine (2+ years running) > > FreeBSD triceratops.netconsonance.com 6.2-RELEASE-p11 FreeBSD 6.2- > RELEASE-p11 #0: Wed Feb 13 06:44:57 UTC 2008 root@i386-builder.daemonology.net > :/usr/obj/usr/src/sys/GENERIC i386 > > After about 2 weeks of watching it carefully I've learned almost > nothing. It's not a disk failure (AFAIK) it's not cpu overheat (now > running healthd without complaints) it's not based on any given > network traffic... however it does appear to accompany heavy cpu/disk > activity. It usually dies when indexing my websites at night (but not > always) and it sometimes dies when compiling programs. Just heavy > disk isn't enough to do the job, as backups proceed without > problems. Heavy cpu by itself isn't enough to do it either. But if > I start compiling things and keep going a while, it will eventually > hang. I had exactly the same problems on a machine a few months ago. It had also been running for about two years, then started freezing when there was high CPU + disk activity. It turned out that the power supply went weak (either the power supply itself or the voltage regulators on the main- board). Replacing PS + mainboard solved the problem. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C++ is the only current language making COBOL look good." -- Bertrand Meyer From sven at dmv.com Tue Jul 15 15:47:59 2008 From: sven at dmv.com (Sven Willenberger) Date: Tue Jul 15 15:48:07 2008 Subject: Multi-machine mirroring choices In-Reply-To: <20080715145426.GA31340@eos.sc1.parodius.com> References: <1216130834.27608.27.camel@lanshark.dmv.com> <20080715145426.GA31340@eos.sc1.parodius.com> Message-ID: <1216136877.27608.36.camel@lanshark.dmv.com> On Tue, 2008-07-15 at 07:54 -0700, Jeremy Chadwick wrote: > On Tue, Jul 15, 2008 at 10:07:14AM -0400, Sven Willenberger wrote: > > 3) The send/recv feature of zfs was something I had not even considered > > until very recently. My understanding is that this would work by a) > > taking a snapshot of master_data1 b) zfs sending that snapshot to > > slave_data1 c) via ssh on pipe, receiving that snapshot on slave_data1 > > and then d) doing incremental snapshots, sending, receiving as in > > (a)(b)(c). How time/cpu intensive is the snapshot generation and just > > how granular could this be done? I would imagine for systems with litle > > traffic/changes this could be practical but what about systems that may > > see a lot of files added, modified, deleted to the filesystem(s)? > > I can speak a bit on ZFS snapshots, because I've used them in the past > with good results. > > Compared to UFS2 snapshots (e.g. dump -L or mksnap_ffs), ZFS snapshots > are fantastic. The two main positives for me were: > > 1) ZFS snapshots take significantly less time to create; I'm talking > seconds or minutes vs. 30-45 minutes. I also remember receiving mail > from someone (on -hackers? I can't remember -- let me know and I can > dig through my mail archives for the specific mail/details) stating > something along the lines of "over time, yes, UFS2 snapshots take > longer and longer, it's a known design problem". > > 2) ZFS snapshots, when created, do not cause the system to more or less > deadlock until the snapshot is generated; you can continue to use the > system during the time the snapshot is being generated. While with > UFS2, dump -L and mksnap_ffs will surely disappoint you. > > We moved all of our production systems off of using dump/restore solely > because of these aspects. We didn't move to ZFS though; we went with > rsync, which is great, except for the fact that it modifies file atimes > (hope you use Maildir and not classic mbox/mail spools...). > > ZFS's send/recv capability (over a network) is something I didn't have > time to experiment with, but it looked *very* promising. The method is > documented in the manpage as "Example 12", and is very simple -- as it > should be. You don't have to use SSH either, by the way[1]. The examples do list ssh as the way of initiating the receiving end; I am curious as to what the alterative would be (short of installing openssh-portable and using cipher=no). > One of the "annoyances" to ZFS snapshots, however, was that I had to > write my own script to do snapshot rotations (think incremental dump(8) > but using ZFS snapshots). That is what I was afraid of. Using snapshots would seem to involve a bit of housekeeping. Furthermore, it sounds more suited to a system that needs periodic rather than constant backing up (syncing). > > I would be interested to hear anyone's experience with any (or all) of > > these methods and caveats of each. I am leaning towards ggate(dc) + > > zpool at the moment assuming that zfs can "smartly" rebuild the mirror > > after the slave's ggated processes bug out. > > I don't have any experience with GEOM gate, so I can't comment on it. > But I would highly recommend you discuss the shortcomings with pjd@, > because he definitely listens. > > However, I must ask you this: why are you doing things the way you are? > Why are you using the equivalent of RAID 1 but for entire computers? Is > there some reason you aren't using a filer (e.g. NetApp) for your data, > thus keeping it centralised? There has been recent discussion of using > FreeBSD with ZFS as such, over on freebsd-fs. If you want a link to the > thread, I can point you to it. Basically I am trying to eliminate the "single point of failure". The project prior to this had such a failure that even a raid5 setup could not get out of. It was determined at that point that a single-machine storage solution would no longer suffice. What I am trying to achieve is having a slave machine that could take over as the file server in the event the master machine goes down. This could be something as simple as the master's network connection going down (CARP to the rescue on the slave) to a complete failure of the master. While zfs send/recv sounds like a good option for periodic backups, I don't think it will fit my purpose. Zpool or gmirror will be a better fit. I see in posts following my initial post that there is reference to improvements in ggate[cd] and/or tcp since 6.2 (and I have moved to 7.0 now) so that bodes well. The question then becomes a matter of which system would be easier to manage in terms of a) the master rebuilding the mirror in the event the slave goes down or ggate[cd] disconnects and b) have the slave become the master for serving files and mounting the drives that were part of the mirror. Thanks to the other posters, I see others are doing what I am trying to accomplish and there were some additional "tuneables" for ggate[cd] that I had not yet incorporated that were mentioned. Sven -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080715/792b2462/attachment.pgp From olli at lurza.secnetix.de Tue Jul 15 15:56:22 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Tue Jul 15 15:56:29 2008 Subject: Multi-machine mirroring choices In-Reply-To: Message-ID: <200807151556.m6FFuGan045657@lurza.secnetix.de> Pete French wrote: > I am not the roiginal poster, but I am doing something very similar and > can answer that question for you. Some people get paranoid about the > whole "single point of failure" thing. I originally suggestted that we buy > a filer and have identical servers so if one breaks we connect the other > to the filer, but the response I got was "what if the filer breaks?". You install a filer cluster with two nodes. Then there is no single point of failure. I've done exactly that at customers of my company, i.e. set up NetApp filer clusters. Any disk can fail, any shelf can fail, any filer head can fail. A complete filer can fail. A switch can fail. The system will keep running and doing its job. And yes, we've tested all of that. Whether filers solve your problems is a different thing. I just pointed out the answer to the question "what if the filer breaks?". I'm not a NetApp salesman. ;-) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "To this day, many C programmers believe that 'strong typing' just means pounding extra hard on the keyboard." -- Peter van der Linden From kris at FreeBSD.org Tue Jul 15 15:58:16 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Tue Jul 15 15:58:59 2008 Subject: Multi-machine mirroring choices In-Reply-To: <200807151523.m6FFNIRJ044047@lurza.secnetix.de> References: <200807151523.m6FFNIRJ044047@lurza.secnetix.de> Message-ID: <487CC919.2010203@FreeBSD.org> Oliver Fromme wrote: > Yet another way would be to use DragoFly's "Hammer" file > system which is part of DragonFly BSD 2.0 which will be > released in a few days. It supports remote mirroring, > i.e. mirror source and mirror target can run on different > machines. Of course it is still very new and experimental > (however, ZFS is marked experimental, too), so you probably > don't want to use it on critical production machines. Let's not get carried away here :) Kris From olli at lurza.secnetix.de Tue Jul 15 16:09:25 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Tue Jul 15 16:09:32 2008 Subject: installdate of a port/package? In-Reply-To: Message-ID: <200807151609.m6FG9MAk046094@lurza.secnetix.de> Ronald Klop wrote: > I just upgraded a machine from FreeBSD 6 to 7. Very nice. > But my portupgrade -fa failed after a while. > How can I know which ports/packages are still from FreeBSD 6? Is there a > datee recorded somewhere or the FreeBSD-version of the port/package? > The date of the files in /var/db/pkg/* is unreliable, because installing a > package gives these files the date of the files in the package. Sorry for th late reply, I didn't see this thread earlier. You can look at the ctime of the +DESC files. That should be the time when the packages were installed. This command will list all packages in the order they were installed: ls -lcrt /var/db/pkg/*/+DESC Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd (On the statement print "42 monkeys" + "1 snake":) By the way, both perl and Python get this wrong. Perl gives 43 and Python gives "42 monkeys1 snake", when the answer is clearly "41 monkeys and 1 fat snake". -- Jim Fulton From petefrench at ticketswitch.com Tue Jul 15 16:13:24 2008 From: petefrench at ticketswitch.com (Pete French) Date: Tue Jul 15 16:13:31 2008 Subject: Multi-machine mirroring choices In-Reply-To: <200807151556.m6FFuGan045657@lurza.secnetix.de> Message-ID: > You install a filer cluster with two nodes. Then there is > no single point of failure. Yes, that would be my choice too. Unfortunately it didn't get done that way. Mind you, the solution we do have is something I am actually pretty happy with - it's cheap and does the job. We never wanted 100% uuptime after all, just something so I could get stuff back up and running in about 15 minutes with no loss of data if possible. Woiuld have been nice to get to play with the NetApp stuff though. -pete. From steve at ibctech.ca Tue Jul 15 16:15:52 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Tue Jul 15 16:15:59 2008 Subject: taskqueue timeout Message-ID: <487CCD46.8080506@ibctech.ca> Hi everyone, I'm wondering if the problems described in the following link have been resolved: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2008-02/msg00211.html I've got four 500GB SATA disks in a ZFS raidz pool, and all four of them are experiencing the behavior. The problem only happens with extreme disk activity. The box becomes unresponsive (can not SSH etc). Keyboard input is displayed on the console, but the commands are not accepted. Is there anything I can do to either figure this out, or work around it? Steve From wxs at FreeBSD.org Tue Jul 15 16:42:08 2008 From: wxs at FreeBSD.org (Wesley Shields) Date: Tue Jul 15 16:42:15 2008 Subject: Multi-machine mirroring choices In-Reply-To: <20080715145426.GA31340@eos.sc1.parodius.com> References: <1216130834.27608.27.camel@lanshark.dmv.com> <20080715145426.GA31340@eos.sc1.parodius.com> Message-ID: <20080715162912.GI64436@atarininja.org> On Tue, Jul 15, 2008 at 07:54:26AM -0700, Jeremy Chadwick wrote: > One of the "annoyances" to ZFS snapshots, however, was that I had to > write my own script to do snapshot rotations (think incremental dump(8) > but using ZFS snapshots). There is a PR[1] to get something like this in the ports tree. I have no idea how good it is but I hope to get it in the tree soon. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/125340 -- WXS From gnn at freebsd.org Tue Jul 15 17:04:25 2008 From: gnn at freebsd.org (gnn@freebsd.org) Date: Tue Jul 15 17:04:37 2008 Subject: igb doesn't compile in STABLE? In-Reply-To: <2a41acea0807141453s7235d894i31a744a0f673fcc0@mail.gmail.com> References: <2a41acea0807141453s7235d894i31a744a0f673fcc0@mail.gmail.com> Message-ID: At Mon, 14 Jul 2008 14:53:16 -0700, Jack Vogel wrote: > > Just guessing, did someone change conf/files maybe?? > If you build a STABLE kernel with igb AND em then things work and the kernel uses em. I'm not sure which thing needs to be changed in conf/files or otherwise though. Later, George From jfvogel at gmail.com Tue Jul 15 17:07:23 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Tue Jul 15 17:07:30 2008 Subject: igb doesn't compile in STABLE? In-Reply-To: References: <2a41acea0807141453s7235d894i31a744a0f673fcc0@mail.gmail.com> Message-ID: <2a41acea0807151007q29a783c4r2ae63c5a631952ba@mail.gmail.com> Oh, so the problem is if igb alone is defined? On Tue, Jul 15, 2008 at 10:04 AM, wrote: > At Mon, 14 Jul 2008 14:53:16 -0700, > Jack Vogel wrote: >> >> Just guessing, did someone change conf/files maybe?? >> > > If you build a STABLE kernel with igb AND em then things work and the > kernel uses em. > > I'm not sure which thing needs to be changed in conf/files or > otherwise though. > > Later, > George > From kris at FreeBSD.org Tue Jul 15 17:10:05 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Tue Jul 15 17:10:12 2008 Subject: Multi-machine mirroring choices In-Reply-To: <20080715162912.GI64436@atarininja.org> References: <1216130834.27608.27.camel@lanshark.dmv.com> <20080715145426.GA31340@eos.sc1.parodius.com> <20080715162912.GI64436@atarininja.org> Message-ID: <487CD9ED.1090207@FreeBSD.org> Wesley Shields wrote: > On Tue, Jul 15, 2008 at 07:54:26AM -0700, Jeremy Chadwick wrote: >> One of the "annoyances" to ZFS snapshots, however, was that I had to >> write my own script to do snapshot rotations (think incremental dump(8) >> but using ZFS snapshots). > > There is a PR[1] to get something like this in the ports tree. I have > no idea how good it is but I hope to get it in the tree soon. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/125340 There is also sysutils/freebsd-snapshot (pkg-descr is out of date, it supports ZFS too). I found it more convenient to just write my own tiny script. Kris From dillon at apollo.backplane.com Tue Jul 15 17:11:43 2008 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Tue Jul 15 17:11:50 2008 Subject: taskqueue timeout References: <487CCD46.8080506@ibctech.ca> Message-ID: <200807151711.m6FHBgVO007481@apollo.backplane.com> :Hi everyone, : :I'm wondering if the problems described in the following link have been :resolved: : :http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2008-02/msg00211.html : :I've got four 500GB SATA disks in a ZFS raidz pool, and all four of them :are experiencing the behavior. : :The problem only happens with extreme disk activity. The box becomes :unresponsive (can not SSH etc). Keyboard input is displayed on the :console, but the commands are not accepted. : :Is there anything I can do to either figure this out, or work around it? : :Steve If you are getting DMA timeouts, go to this URL: http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting Then I would suggest going into /usr/src/sys/dev/ata (I think, on FreeBSD), locate all instances where request->timeout is set to 5, and change them all to 10. cd /usr/src/sys/dev/ata fgrep 'request->timeout' *.c ... change all assignments of 5 to 10 ... Try that first. If it helps then it is a known issue. Basically a combination of the on-disk write cache and possible ECC corrections, remappings, or excessive remapped sectors can cause the drive to take much longer then normal to complete a request. The default 5-second timeout is insufficient. If it does help, post confirmation to prod the FBsd developers to change the timeouts. -- If you are NOT getting DMA timeouts then the ZFS lockups may be due to buffer/memory deadlocks. ZFS has knobs for adjusting its memory footprint size. Lowering the footprint ought to solve (most of) those issues. It's actually somewhat of a hard issue to solve. Filesystems like UFS aren't complex enough to require the sort of dynamic memory allocations deep in the filesystem that ZFS and HAMMER need to do. -Matt Matthew Dillon From achill at matrix.gatewaynet.com Tue Jul 15 17:21:12 2008 From: achill at matrix.gatewaynet.com (Achilleas Mantzios) Date: Tue Jul 15 17:21:20 2008 Subject: softdepflush bad block error has led to negative blocks in free inode and handle_workitem_freeblocks: block count Message-ID: <200807151958.12955.achill@matrix.gatewaynet.com> Hi, The problem started when i installed a kodicom 4400 card and started to run zoneminder. Prior to that no problems with my machine, which now runs FreeBSD panix.internal.net 7.0-RELEASE-p3 FreeBSD 7.0-RELEASE-p3 #3: Mon Jul 14 16:35:37 EEST 2008 doroot@panix.internal.net:/usr/obj/usr/src/sys/GENERIC i386 This hardware change happened in Sunday Jul 13. The next day (Jul 14) morning "periodic daily" cron job at 03:01 gave: /var/log/messages.1.bz2:Jul 14 03:01:04 panix kernel: pid 48 (softdepflush), uid 0 inumber 2662656 on /usr: bad block /var/log/messages.1.bz2:Jul 14 03:01:04 panix kernel: pid 48 (softdepflush), uid 0 inumber 2662656 on /usr: bad block /var/log/messages.1.bz2:Jul 14 03:01:04 panix kernel: pid 48 (softdepflush), uid 0 inumber 2662656 on /usr: bad block /var/log/messages.1.bz2:Jul 14 03:01:04 panix kernel: pid 48 (softdepflush), uid 0 inumber 2662656 on /usr: bad block ... (15 times) The funny think is that "df -h" showed a huge negative capacity. Yesterday (Mon Jul 14) i had a crash when i tried to run (by hand) pkg_info . Today (Mon Jul 15) the morning "periodic daily" cron job resulted in a crash as well in when running find. I speculated that it was one of those cases that bad memory, or overheated memory could cause such problems and i removed the most suspicious sim. After that i didnt get any crashes when trying to run pkg_info or periodic daily,weekly,monthly, but i get the following whenever i run periodic weekly: panix kernel: free inode /usr/2662656 had -3549356 blocks (negative) and after a while panix kernel: handle_workitem_freeblocks: block count I suspect that even if i have a healthy system as far as memory is concerned (i hope), the problem with the 2662656 inode is still there. Any thoughts are very welcome. -- Achilleas Mantzios From gnn at freebsd.org Tue Jul 15 17:32:07 2008 From: gnn at freebsd.org (gnn@freebsd.org) Date: Tue Jul 15 17:32:20 2008 Subject: igb doesn't compile in STABLE? In-Reply-To: <2a41acea0807151007q29a783c4r2ae63c5a631952ba@mail.gmail.com> References: <2a41acea0807141453s7235d894i31a744a0f673fcc0@mail.gmail.com> <2a41acea0807151007q29a783c4r2ae63c5a631952ba@mail.gmail.com> Message-ID: At Tue, 15 Jul 2008 10:07:22 -0700, Jack Vogel wrote: > > Oh, so the problem is if igb alone is defined? > Yes. Best, George From jfvogel at gmail.com Tue Jul 15 17:35:58 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Tue Jul 15 17:36:05 2008 Subject: igb doesn't compile in STABLE? In-Reply-To: References: <2a41acea0807141453s7235d894i31a744a0f673fcc0@mail.gmail.com> <2a41acea0807151007q29a783c4r2ae63c5a631952ba@mail.gmail.com> Message-ID: <2a41acea0807151035w291269abt4ed99989ae45cc8b@mail.gmail.com> OK, will put on my todo list :) On Tue, Jul 15, 2008 at 10:31 AM, wrote: > At Tue, 15 Jul 2008 10:07:22 -0700, > Jack Vogel wrote: >> >> Oh, so the problem is if igb alone is defined? >> > > Yes. > > Best, > George > From dillon at apollo.backplane.com Tue Jul 15 17:52:44 2008 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Tue Jul 15 17:52:51 2008 Subject: Multi-machine mirroring choices References: <200807151523.m6FFNIRJ044047@lurza.secnetix.de> <487CC919.2010203@FreeBSD.org> Message-ID: <200807151752.m6FHqf7E007803@apollo.backplane.com> :Oliver Fromme wrote: : :> Yet another way would be to use DragoFly's "Hammer" file :> system which is part of DragonFly BSD 2.0 which will be :> released in a few days. It supports remote mirroring, :> i.e. mirror source and mirror target can run on different :> machines. Of course it is still very new and experimental :> (however, ZFS is marked experimental, too), so you probably :> don't want to use it on critical production machines. : :Let's not get carried away here :) : :Kris Heh. I think its safe to say that a *NATIVE* uninterrupted and fully cache coherent fail-over feature is not something any of us in BSDland have yet. It's a damn difficult problem that is frankly best solved above the filesytem layer, but with filesystem support for bulk mirroring operations. HAMMER's native mirroring was the last major feature to go into it before the upcoming release, so it will definitely be more experimental then the rest of HAMMER. This is mainly because it implements a full blown queue-less incremental snapshot and mirroring algorithm, single-master-to-multi-slave. It does it at a very low level, by optimally scanning HAMMER's B-Tree. In other words, the kitchen sink. The B-Tree propagates the highest transaction id up to the root to support incremental mirroring and that's the bit that is highly experimental and not well tested yet. It's fairly complex because even destroyed B-Tree records and collapses must propagate a transaction id up the tree (so the mirroring code knows what it needs to send to the other end to do comparative deletions on the target). (transaction ids are bundled together in larger flushes so the actual B-Tree overhead is minimal). The rest of HAMMER is shaping up very well for the release. It's phenominal when it comes to storing backups. Post-release I'll be moving more of our production systems to HAMMER. The only sticky issue we have is filesystem-full handling, but it is more a matter of fine-tuning then anything else. -- Someone mentioned atime and mtime. For something like ZFS or HAMMER, these fields represent a real problem (atime more then mtime). I'm kinda interested in knowing, does ZFS do block replacement for atime updates? For HAMMER I don't roll new B-Tree records for atime or mtime updates. I update the fields in-place in the current version of the inode and all snapshot accesses will lock them (in getattr) to ctime in order to guarantee a consistent result. That way (tar | md5) can be used to validate snapshot integrity. At the moment, in this first release, the mirroring code does not propagate atime or mtime. I plan to do it, though. Even though I don't roll new B-Tree records for atime/mtime updates I can still propagate a new transaction id up the B-Tree to make the changes visible to the mirroring code. I'll definitely be doing that for mtime and will have the option to do it for atime as well. But atime still represents a big expense in actual mirroring bandwidth. If someone reads a million files on the master then a million inode records (sans file contents) would end up in the mirroring stream just for the atime update. Ick. -Matt From steve at ibctech.ca Tue Jul 15 17:55:54 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Tue Jul 15 17:56:01 2008 Subject: taskqueue timeout In-Reply-To: <200807151711.m6FHBgVO007481@apollo.backplane.com> References: <487CCD46.8080506@ibctech.ca> <200807151711.m6FHBgVO007481@apollo.backplane.com> Message-ID: <487CE4B8.5080900@ibctech.ca> Matthew Dillon wrote: > If you are getting DMA timeouts, go to this URL: Yes, I am. > http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting I fall under the category of "ATA/SATA DMA timeout issues". > Then I would suggest going into /usr/src/sys/dev/ata (I think, on > FreeBSD), locate all instances where request->timeout is set to 5, > and change them all to 10. > > cd /usr/src/sys/dev/ata > fgrep 'request->timeout' *.c > ... change all assignments of 5 to 10 ... > > Try that first. If it helps then it is a known issue. Basically > a combination of the on-disk write cache and possible ECC corrections, > remappings, or excessive remapped sectors can cause the drive to take > much longer then normal to complete a request. The default 5-second > timeout is insufficient. > > If it does help, post confirmation to prod the FBsd developers to > change the timeouts. I've just reproduced the problem, and will try hacking the code now to see if the problem goes away. Since the box won't take input, I can't tell the disk usage at the time it dies. However, it seems to appear while running an Amanda backup, and my network throughput hits about ~90 Mbps @ ~5 kpps. I'll post back with results of the increase of the timeout. Steve From steve at ibctech.ca Tue Jul 15 18:46:01 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Tue Jul 15 18:46:07 2008 Subject: taskqueue timeout In-Reply-To: <200807151711.m6FHBgVO007481@apollo.backplane.com> References: <487CCD46.8080506@ibctech.ca> <200807151711.m6FHBgVO007481@apollo.backplane.com> Message-ID: <487CF077.2040201@ibctech.ca> Matthew Dillon wrote: > If you are getting DMA timeouts, go to this URL: > > http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting > > Then I would suggest going into /usr/src/sys/dev/ata (I think, on > FreeBSD), locate all instances where request->timeout is set to 5, > and change them all to 10. > > cd /usr/src/sys/dev/ata > fgrep 'request->timeout' *.c > ... change all assignments of 5 to 10 ... Changing 5 to 10 in all cases and rebuilding the kernel does not fix the problem. I'm going to install the patch that allows the values to be changed via sysctl and up it to 15. This problem happens across all four disks. Does anyone else have any suggestions on what I can check? Steve From john at basicnets.co.uk Tue Jul 15 19:19:17 2008 From: john at basicnets.co.uk (john@basicnets.co.uk) Date: Tue Jul 15 19:19:32 2008 Subject: Fresh 7.0 Install: Fatal Trap 12 panic when put under load In-Reply-To: <487C8486.1040904@FreeBSD.org> References: <854CADB9D95147CAB10BC35887A8E5DC@emea.hubersuhner.net> <20080715102135.GA18082@eos.sc1.parodius.com> <487C8486.1040904@FreeBSD.org> Message-ID: <20080715201915.8m5j3k1lw00k4gck@mail.basicnets.co.uk> > Please collect kgdb/ddb backtraces. kgdb backtrace: server251# kgdb -c /var/crash/vmcore.0 kgdb: couldn't find a suitable kernel image server251# kgdb /boot/kernel/kernel /var/crash/vmcore.0 kgdb: kvm_read: invalid address (0xffffff00010e5468) [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Unde fined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB.? Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd". Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address?? = 0x6400000000 fault code????????????? = supervisor read instruction, page not present instruction pointer???? = 0x8:0x6400000000 stack pointer?????????? = 0x10:0xffffffffb1d7f590 frame pointer?????????? = 0x10:0xffffff0035d2dcc0 code segment??????????? = base 0x0, limit 0xfffff, type 0x1b ??????????????????????? = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags??????? = interrupt enabled, resume, IOPL = 0 current process???????? = 88622 (make) trap number???????????? = 12 panic: page fault cpuid = 0 Uptime: 5h57m22s Physical memory: 4082 MB Dumping 444 MB: 429 413 397 381 365 349 333 317 301 285 269 253 237 221 205 189 173 157 141 125 109 93 77 61 45 29 13 #0? doadump () at pcpu.h:194 194???? pcpu.h: No such file or directory. ??????? in pcpu.h (kgdb) (kgdb) list *0x6400000000 No source file for address 0x6400000000. (kgdb) backtrace #0? doadump () at pcpu.h:194 #1? 0xffffff0004742440 in ?? () #2? 0xffffffff80477699 in boot (howto=260) ??? at /usr/src/sys/kern/kern_shutdown.c:409 #3? 0xffffffff80477a9d in panic (fmt=0x104
) ??? at /usr/src/sys/kern/kern_shutdown.c:563 #4? 0xffffffff8072ed44 in trap_fatal (frame=0xffffff00048ee000, ??? eva=18446742974275512528) at /usr/src/sys/amd64/amd64/trap.c:724 #5? 0xffffffff8072f115 in trap_pfault (frame=0xffffffffb1d7f4e0, usermode=0) ??? at /usr/src/sys/amd64/amd64/trap.c:641 #6? 0xffffffff8072fa58 in trap (frame=0xffffffffb1d7f4e0) ??? at /usr/src/sys/amd64/amd64/trap.c:410 #7? 0xffffffff807156be in calltrap () ??? at /usr/src/sys/amd64/amd64/exception.S:169 #8? 0x0000006400000000 in ?? () #9? 0xffffffff8067d3ee in uma_zalloc_arg (zone=0xffffff00bfed07e0, udata=0x0, ??? flags=-256) at /usr/src/sys/vm/uma_core.c:1835 #10 0xffffffff80661ecf in ffs_vget (mp=0xffffff00047f4978, ino=47884512, ??? flags=2, vpp=0xffffffffb1d7f728) at uma.h:277 #11 0xffffffff8066d010 in ufs_lookup (ap=0xffffffffb1d7f780) ??? at /usr/src/sys/ufs/ufs/ufs_lookup.c:573 #12 0xffffffff804dfa89 in vfs_cache_lookup (ap=Variable "ap" is not available. ) at vnode_if.h:83 #13 0xffffffff8077235f in VOP_LOOKUP_APV (vop=0xffffffff809e7de0, ??? a=0xffffffffb1d7f840) at vnode_if.c:99 ---Type to continue, or q to quit--- #14 0xffffffff804e6394 in lookup (ndp=0xffffffffb1d7f950) at vnode_if.h:57 #15 0xffffffff804e7228 in namei (ndp=0xffffffffb1d7f950) ??? at /usr/src/sys/kern/vfs_lookup.c:219 #16 0xffffffff804f4717 in kern_stat (td=0xffffff00048ee000, ??? path=0x8006f7040
, pathseg=Variable "path seg" is not available. ) ??? at /usr/src/sys/kern/vfs_syscalls.c:2109 #17 0xffffffff804f4987 in stat (td=Variable "td" is not available. ) at /usr/src/sys/kern/vfs_syscalls.c:2093 #18 0xffffffff8072f397 in syscall (frame=0xffffffffb1d7fc70) ??? at /usr/src/sys/amd64/amd64/trap.c:852 #19 0xffffffff807158cb in Xfast_syscall () ??? at /usr/src/sys/amd64/amd64/exception.S:290 #20 0x000000000043127c in ?? () Previous frame inner to this frame (corrupt stack?) I really don't understand this -any advice you can give would really be appreciated. John ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From steve at ibctech.ca Tue Jul 15 19:27:05 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Tue Jul 15 19:27:13 2008 Subject: taskqueue timeout In-Reply-To: <487CF077.2040201@ibctech.ca> References: <487CCD46.8080506@ibctech.ca> <200807151711.m6FHBgVO007481@apollo.backplane.com> <487CF077.2040201@ibctech.ca> Message-ID: <487CFA08.5000308@ibctech.ca> Steve Bertrand wrote: > Matthew Dillon wrote: > >> If you are getting DMA timeouts, go to this URL: >> >> http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting >> >> Then I would suggest going into /usr/src/sys/dev/ata (I think, on >> FreeBSD), locate all instances where request->timeout is set to 5, >> and change them all to 10. >> >> cd /usr/src/sys/dev/ata >> fgrep 'request->timeout' *.c >> ... change all assignments of 5 to 10 ... > > Changing 5 to 10 in all cases and rebuilding the kernel does not fix the > problem. Went from 10->15, and it took quite a bit longer into the backup before the problem cropped back up. Here is what I was seeing at the time it failed. Where netstat and zpool iostat drop off is where I start seeing the errors occur: # top last pid: 1069; load averages: 0.09, 0.17, 0.10 up 0+00:08:31 19:22:39 53 processes: 1 running, 52 sleeping CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 28M Active, 3644K Inact, 301M Wired, 76K Cache, 1634M Free Swap: # netstat -w 1 -h 4.8K 0 11M 3.5K 0 5.4M 0 4.5K 0 10M 3.3K 0 5.1M 0 4.9K 0 11M 3.6K 0 5.5M 0 4.8K 0 11M 3.5K 0 5.4M 0 4.3K 0 9.5M 3.1K 0 4.8M 0 5.1K 0 11M 3.7K 0 5.7M 0 5.0K 0 11M 3.6K 0 5.6M 0 5.3K 0 12M 3.9K 0 6.0M 0 4.8K 0 11M 3.5K 0 5.4M 0 4.7K 0 10M 3.4K 0 5.2M 0 4.8K 0 11M 3.5K 0 5.4M 0 4.6K 0 10M 3.4K 0 5.2M 0 4.1K 0 9.1M 3.0K 0 4.6M 0 5.3K 0 12M 3.9K 0 6.0M 0 5.2K 0 12M 3.8K 0 5.8M 0 4.3K 0 9.5M 3.1K 0 4.8M 0 4.3K 0 9.6M 3.2K 0 4.9M 0 5.4K 0 12M 4.0K 0 6.1M 0 4.8K 0 11M 3.5K 0 5.4M 0 2.4K 0 5.1M 1.7K 0 2.5M 0 input (Total) output packets errs bytes packets errs bytes colls 2 0 120 2 0 316 0 3 0 180 4 0 1.0K 0 3 0 180 2 0 316 0 3 0 180 3 0 658 0 5 0 1.6K 5 0 942 0 3 0 254 4 0 840 0 3 0 180 2 0 316 0 # zpool iostat 1 storage 6.40G 1.81T 0 296 0 37.0M storage 6.43G 1.81T 0 188 0 14.5M storage 6.43G 1.81T 0 0 0 0 storage 6.43G 1.81T 0 0 0 0 storage 6.43G 1.81T 0 0 0 0 storage 6.43G 1.81T 0 47 0 5.99M storage 6.46G 1.81T 0 218 0 18.0M storage 6.46G 1.81T 0 0 0 0 storage 6.46G 1.81T 0 0 0 0 storage 6.46G 1.81T 9 0 192K 0 storage 6.46G 1.81T 0 59 0 7.39M storage 6.49G 1.81T 1 250 3.42K 14.9M storage 6.49G 1.81T 0 0 0 0 storage 6.49G 1.81T 0 0 0 0 storage 6.49G 1.81T 0 0 0 0 storage 6.49G 1.81T 0 141 0 17.5M storage 6.52G 1.81T 0 74 0 232K storage 6.52G 1.81T 0 0 0 0 storage 6.52G 1.81T 0 0 0 0 storage 6.52G 1.81T 0 0 0 0 storage 6.52G 1.81T 0 151 0 18.8M storage 6.52G 1.81T 0 114 0 8.07M storage 6.52G 1.81T 0 0 0 0 storage 6.52G 1.81T 0 0 0 0 storage 6.52G 1.81T 0 0 0 0 storage 6.52G 1.81T 0 0 0 0 > Don't know if this will help anyone or not. Steve From kris at FreeBSD.org Tue Jul 15 19:42:02 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Tue Jul 15 19:42:10 2008 Subject: Fresh 7.0 Install: Fatal Trap 12 panic when put under load In-Reply-To: <20080715201915.8m5j3k1lw00k4gck@mail.basicnets.co.uk> References: <854CADB9D95147CAB10BC35887A8E5DC@emea.hubersuhner.net> <20080715102135.GA18082@eos.sc1.parodius.com> <487C8486.1040904@FreeBSD.org> <20080715201915.8m5j3k1lw00k4gck@mail.basicnets.co.uk> Message-ID: <487CFD8B.2060905@FreeBSD.org> john@basicnets.co.uk wrote: > (kgdb) backtrace > #0 doadump () at pcpu.h:194 > #1 0xffffff0004742440 in ?? () > #2 0xffffffff80477699 in boot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:409 > #3 0xffffffff80477a9d in panic (fmt=0x104
) > at /usr/src/sys/kern/kern_shutdown.c:563 > #4 0xffffffff8072ed44 in trap_fatal (frame=0xffffff00048ee000, > eva=18446742974275512528) at /usr/src/sys/amd64/amd64/trap.c:724 > #5 0xffffffff8072f115 in trap_pfault (frame=0xffffffffb1d7f4e0, > usermode=0) > at /usr/src/sys/amd64/amd64/trap.c:641 > #6 0xffffffff8072fa58 in trap (frame=0xffffffffb1d7f4e0) > at /usr/src/sys/amd64/amd64/trap.c:410 > #7 0xffffffff807156be in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:169 > #8 0x0000006400000000 in ?? () > #9 0xffffffff8067d3ee in uma_zalloc_arg (zone=0xffffff00bfed07e0, > udata=0x0, > flags=-256) at /usr/src/sys/vm/uma_core.c:1835 OK, that is if (zone->uz_ctor != NULL) { if (zone->uz_ctor(item, zone->uz_keg->uk_size, uz_ctor is indeed not null, but it's got 3 bits set. Not impossible that it's bad RAM still. I didn't spot anything that could cause it otherwise but I don't know this code in detail. Do all of the panics have the same backtrace? Kris > #10 0xffffffff80661ecf in ffs_vget (mp=0xffffff00047f4978, ino=47884512, > flags=2, vpp=0xffffffffb1d7f728) at uma.h:277 > #11 0xffffffff8066d010 in ufs_lookup (ap=0xffffffffb1d7f780) > at /usr/src/sys/ufs/ufs/ufs_lookup.c:573 > #12 0xffffffff804dfa89 in vfs_cache_lookup (ap=Variable "ap" is not > available. > ) at vnode_if.h:83 > #13 0xffffffff8077235f in VOP_LOOKUP_APV (vop=0xffffffff809e7de0, > a=0xffffffffb1d7f840) at vnode_if.c:99 > ---Type to continue, or q to quit--- > #14 0xffffffff804e6394 in lookup (ndp=0xffffffffb1d7f950) at vnode_if.h:57 > #15 0xffffffff804e7228 in namei (ndp=0xffffffffb1d7f950) > at /usr/src/sys/kern/vfs_lookup.c:219 > #16 0xffffffff804f4717 in kern_stat (td=0xffffff00048ee000, > path=0x8006f7040
, > pathseg=Variable "path > seg" is not available. > ) > at /usr/src/sys/kern/vfs_syscalls.c:2109 > #17 0xffffffff804f4987 in stat (td=Variable "td" is not available. > ) at /usr/src/sys/kern/vfs_syscalls.c:2093 > #18 0xffffffff8072f397 in syscall (frame=0xffffffffb1d7fc70) > at /usr/src/sys/amd64/amd64/trap.c:852 > #19 0xffffffff807158cb in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:290 > #20 0x000000000043127c in ?? () > Previous frame inner to this frame (corrupt stack?) > > I really don't understand this -any advice you can give would really > be appreciated. > > John > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > From john at basicnets.co.uk Tue Jul 15 19:47:05 2008 From: john at basicnets.co.uk (john@basicnets.co.uk) Date: Tue Jul 15 19:47:16 2008 Subject: Fresh 7.0 Install: Fatal Trap 12 panic when put under load In-Reply-To: <20080715193321.GX17123@deviant.kiev.zoral.com.ua> References: <854CADB9D95147CAB10BC35887A8E5DC@emea.hubersuhner.net> <20080715102135.GA18082@eos.sc1.parodius.com> <487C8486.1040904@FreeBSD.org> <20080715201915.8m5j3k1lw00k4gck@mail.basicnets.co.uk> <20080715193321.GX17123@deviant.kiev.zoral.com.ua> Message-ID: <20080715204703.1xshles8aogwksw4@mail.basicnets.co.uk> >> #9? 0xffffffff8067d3ee in uma_zalloc_arg (zone=0xffffff00bfed07e0, >> udata=0x0, >> flags=-256) at /usr/src/sys/vm/uma_core.c:1835 > From the frame #9, please do > p *zone > I am esp. interested in the value of the uz_ctor member. > > It seems that it becomes corrupted, it value should be 0, as this seems > to be ffs inode zone.? I suspect that gdb would show 0x6400000000 instead. I am afraid that you may need to spell out each step for me :-( (kgdb) p *zone No symbol "zone" in current context. (kgdb) list *0xffffffff8067d3ee 0xffffffff8067d3ee is in uma_zalloc_arg (/usr/src/sys/vm/uma_core.c:1835). 1830??????????????????????????????? ("uma_zalloc: Bucket pointer mangled.")); 1831??????????????????????????? cache->uc_allocs++; 1832??????????????????????????? critical_exit(); 1833??? #ifdef INVARIANTS 1834??????????????????????????? ZONE_LOCK(zone); 1835??????????????????????????? uma_dbg_alloc(zone, NULL, item); 1836??????????????????????????? ZONE_UNLOCK(zone); 1837??? #endif 1838??????????????????????????? if (zone->uz_ctor != NULL) { 1839??????????????????????????????????? if (zone->uz_ctor(item, zone->uz_keg->uk_size, Is this that you were looking for? John ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From kostikbel at gmail.com Tue Jul 15 19:49:50 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Tue Jul 15 19:49:58 2008 Subject: Fresh 7.0 Install: Fatal Trap 12 panic when put under load In-Reply-To: <20080715201915.8m5j3k1lw00k4gck@mail.basicnets.co.uk> References: <854CADB9D95147CAB10BC35887A8E5DC@emea.hubersuhner.net> <20080715102135.GA18082@eos.sc1.parodius.com> <487C8486.1040904@FreeBSD.org> <20080715201915.8m5j3k1lw00k4gck@mail.basicnets.co.uk> Message-ID: <20080715193321.GX17123@deviant.kiev.zoral.com.ua> On Tue, Jul 15, 2008 at 08:19:15PM +0100, john@basicnets.co.uk wrote: > > > > Please collect kgdb/ddb backtraces. > > kgdb backtrace: > > server251# kgdb -c /var/crash/vmcore.0 > kgdb: couldn't find a suitable kernel image > server251# kgdb /boot/kernel/kernel /var/crash/vmcore.0 > kgdb: kvm_read: invalid address (0xffffff00010e5468) > [GDB will not be able to debug user-mode threads: > /usr/lib/libthread_db.so: Unde > fined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB.? Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd". > > Unread portion of the kernel message buffer: > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address?? = 0x6400000000 > fault code????????????? = supervisor read instruction, page not present > instruction pointer???? = 0x8:0x6400000000 > stack pointer?????????? = 0x10:0xffffffffb1d7f590 > frame pointer?????????? = 0x10:0xffffff0035d2dcc0 > code segment??????????? = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags??????? = interrupt enabled, resume, IOPL = 0 > current process???????? = 88622 (make) > trap number???????????? = 12 > panic: page fault > cpuid = 0 > Uptime: 5h57m22s > Physical memory: 4082 MB > Dumping 444 MB: 429 413 397 381 365 349 333 317 301 285 269 253 237 > 221 205 189 > 173 157 141 125 109 93 77 61 45 29 13 > > #0? doadump () at pcpu.h:194 > 194???? pcpu.h: No such file or directory. > in pcpu.h > (kgdb) > (kgdb) list *0x6400000000 > No source file for address 0x6400000000. > (kgdb) backtrace > #0? doadump () at pcpu.h:194 > #1? 0xffffff0004742440 in ?? () > #2? 0xffffffff80477699 in boot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:409 > #3? 0xffffffff80477a9d in panic (fmt=0x104
) > at /usr/src/sys/kern/kern_shutdown.c:563 > #4? 0xffffffff8072ed44 in trap_fatal (frame=0xffffff00048ee000, > eva=18446742974275512528) at /usr/src/sys/amd64/amd64/trap.c:724 > #5? 0xffffffff8072f115 in trap_pfault (frame=0xffffffffb1d7f4e0, usermode=0) > at /usr/src/sys/amd64/amd64/trap.c:641 > #6? 0xffffffff8072fa58 in trap (frame=0xffffffffb1d7f4e0) > at /usr/src/sys/amd64/amd64/trap.c:410 > #7? 0xffffffff807156be in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:169 > #8? 0x0000006400000000 in ?? () > #9? 0xffffffff8067d3ee in uma_zalloc_arg (zone=0xffffff00bfed07e0, > udata=0x0, > flags=-256) at /usr/src/sys/vm/uma_core.c:1835 From the frame #9, please do p *zone I am esp. interested in the value of the uz_ctor member. It seems that it becomes corrupted, it value should be 0, as this seems to be ffs inode zone. I suspect that gdb would show 0x6400000000 instead. That may be kernel memory corruption, but might be a bad memory as well (double bit inversion ?). > #10 0xffffffff80661ecf in ffs_vget (mp=0xffffff00047f4978, ino=47884512, > flags=2, vpp=0xffffffffb1d7f728) at uma.h:277 > #11 0xffffffff8066d010 in ufs_lookup (ap=0xffffffffb1d7f780) > at /usr/src/sys/ufs/ufs/ufs_lookup.c:573 > #12 0xffffffff804dfa89 in vfs_cache_lookup (ap=Variable "ap" is not > available. > ) at vnode_if.h:83 > #13 0xffffffff8077235f in VOP_LOOKUP_APV (vop=0xffffffff809e7de0, > a=0xffffffffb1d7f840) at vnode_if.c:99 > ---Type to continue, or q to quit--- > #14 0xffffffff804e6394 in lookup (ndp=0xffffffffb1d7f950) at vnode_if.h:57 > #15 0xffffffff804e7228 in namei (ndp=0xffffffffb1d7f950) > at /usr/src/sys/kern/vfs_lookup.c:219 > #16 0xffffffff804f4717 in kern_stat (td=0xffffff00048ee000, > path=0x8006f7040
, > pathseg=Variable "path > seg" is not available. > ) > at /usr/src/sys/kern/vfs_syscalls.c:2109 > #17 0xffffffff804f4987 in stat (td=Variable "td" is not available. > ) at /usr/src/sys/kern/vfs_syscalls.c:2093 > #18 0xffffffff8072f397 in syscall (frame=0xffffffffb1d7fc70) > at /usr/src/sys/amd64/amd64/trap.c:852 > #19 0xffffffff807158cb in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:290 > #20 0x000000000043127c in ?? () > Previous frame inner to this frame (corrupt stack?) > > I really don't understand this -any advice you can give would > really be appreciated. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080715/4fe7c4ac/attachment.pgp From kostikbel at gmail.com Tue Jul 15 19:51:40 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Tue Jul 15 19:51:46 2008 Subject: Fresh 7.0 Install: Fatal Trap 12 panic when put under load In-Reply-To: <20080715204703.1xshles8aogwksw4@mail.basicnets.co.uk> References: <854CADB9D95147CAB10BC35887A8E5DC@emea.hubersuhner.net> <20080715102135.GA18082@eos.sc1.parodius.com> <487C8486.1040904@FreeBSD.org> <20080715201915.8m5j3k1lw00k4gck@mail.basicnets.co.uk> <20080715193321.GX17123@deviant.kiev.zoral.com.ua> <20080715204703.1xshles8aogwksw4@mail.basicnets.co.uk> Message-ID: <20080715195129.GZ17123@deviant.kiev.zoral.com.ua> On Tue, Jul 15, 2008 at 08:47:03PM +0100, john@basicnets.co.uk wrote: > > > >> #9? 0xffffffff8067d3ee in uma_zalloc_arg (zone=0xffffff00bfed07e0, > >>udata=0x0, > >>flags=-256) at /usr/src/sys/vm/uma_core.c:1835 > >From the frame #9, please do > >p *zone > >I am esp. interested in the value of the uz_ctor member. > > > >It seems that it becomes corrupted, it value should be 0, as this seems > >to be ffs inode zone.? I suspect that gdb would show 0x6400000000 instead. > > I am afraid that you may need to spell out each step for me :-( > > (kgdb) p *zone > No symbol "zone" in current context. Do the "frame 9" before "p *zone". > (kgdb) list *0xffffffff8067d3ee > 0xffffffff8067d3ee is in uma_zalloc_arg (/usr/src/sys/vm/uma_core.c:1835). > 1830??????????????????????????????? ("uma_zalloc: Bucket pointer > mangled.")); > 1831??????????????????????????? cache->uc_allocs++; > 1832??????????????????????????? critical_exit(); > 1833??? #ifdef INVARIANTS > 1834??????????????????????????? ZONE_LOCK(zone); > 1835??????????????????????????? uma_dbg_alloc(zone, NULL, item); > 1836??????????????????????????? ZONE_UNLOCK(zone); > 1837??? #endif > 1838??????????????????????????? if (zone->uz_ctor != NULL) { > 1839??????????????????????????????????? if (zone->uz_ctor(item, > zone->uz_keg->uk_size, > > Is this that you were looking for? No, see above. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080715/37c7f07d/attachment.pgp From dillon at apollo.backplane.com Tue Jul 15 19:55:42 2008 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Tue Jul 15 19:55:50 2008 Subject: taskqueue timeout References: <487CCD46.8080506@ibctech.ca> <200807151711.m6FHBgVO007481@apollo.backplane.com> <487CF077.2040201@ibctech.ca> <487CFA08.5000308@ibctech.ca> Message-ID: <200807151955.m6FJtf77008969@apollo.backplane.com> :Went from 10->15, and it took quite a bit longer into the backup before :the problem cropped back up. Try 30 or longer. See if you can make the problem go away entirely. then fall back to 5 and see if the problem resumes at its earlier pace. -- It could be temperature related. The drives are being exercised a lot, they could very well be overheating. To find out add more airflow (a big house fan would do the trick). -- It could be that errors are accumulating on the drives, but it seems unlikely that four drives would exhibit the same problem. -- Also make sure the power supply can handle four drives. Most power supplies that come with consumer boxes can't under full load if you also have a mid or high-end graphics card installed. Power supplies that come with OEM slap-together enclosures are not usually much better. Specifically, look at the +5V and +12V amperage maximums on the power supply, then check the disk labels to see what they draw, then multiply by 2. e.g. if your power supply can do 30A@12V and you have four drives each taking 2A@12V (and typically ~half that at 5V), thats 4x2x2 = 16A@12V and you would probably be ok. To test, remove two of the four drives, reformat the ZFS to use just 2, and see if the problem reoccurs with just two drives. -Matt From john at basicnets.co.uk Tue Jul 15 20:06:42 2008 From: john at basicnets.co.uk (john@basicnets.co.uk) Date: Tue Jul 15 20:06:49 2008 Subject: Fresh 7.0 Install: Fatal Trap 12 panic when put under load In-Reply-To: <20080715195129.GZ17123@deviant.kiev.zoral.com.ua> References: <854CADB9D95147CAB10BC35887A8E5DC@emea.hubersuhner.net> <20080715102135.GA18082@eos.sc1.parodius.com> <487C8486.1040904@FreeBSD.org> <20080715201915.8m5j3k1lw00k4gck@mail.basicnets.co.uk> <20080715193321.GX17123@deviant.kiev.zoral.com.ua> <20080715204703.1xshles8aogwksw4@mail.basicnets.co.uk> <20080715195129.GZ17123@deviant.kiev.zoral.com.ua> Message-ID: <20080715210640.moiz4pnf6s8gkok8@mail.basicnets.co.uk> > Do the "frame 9" before "p *zone". It's obvious now you say it ;-) You are indeed right: (kgdb) frame 9 #9? 0xffffffff8067d3ee in uma_zalloc_arg (zone=0xffffff00bfed07e0, udata=0x0, ??? flags=-256) at /usr/src/sys/vm/uma_core.c:1835 1835??????????????????????????? uma_dbg_alloc(zone, NULL, item); (kgdb) p *zone $1 = {uz_name = 0xffffffff808084cd "FFS inode", uz_lock = 0xffffff00bfecf7f0, ? uz_keg = 0xffffff00bfecf7e0, uz_link = {le_next = 0x0, ??? le_prev = 0xffffff00bfecf830}, uz_full_bucket = { ??? lh_first = 0xffffffe01a74c830}, uz_free_bucket = { ??? lh_first = 0xffffff00469bf830}, uz_ctor = 0x6400000000, uz_dtor = 0, ? uz_init = 0x9a00000000, uz_fini = 0, uz_allocs = 17180460407, ? uz_frees = 504673, uz_fails = 0, uz_fills = 0, uz_count = 128, uz_cpu = {{ ????? uc_freebucket = 0xffffff000e5d6830, uc_allocbucket = 0xffffff003a5f7000, ????? uc_allocs = 97, uc_frees = 0}}} Now what does that mean?? I just experienced another panic, but it failed to writ to disk :-(.? I will force another one and check that the details are the same. John ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From kris at FreeBSD.org Tue Jul 15 20:07:22 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Tue Jul 15 20:07:28 2008 Subject: Fresh 7.0 Install: Fatal Trap 12 panic when put under load In-Reply-To: <20080715204703.1xshles8aogwksw4@mail.basicnets.co.uk> References: <854CADB9D95147CAB10BC35887A8E5DC@emea.hubersuhner.net> <20080715102135.GA18082@eos.sc1.parodius.com> <487C8486.1040904@FreeBSD.org> <20080715201915.8m5j3k1lw00k4gck@mail.basicnets.co.uk> <20080715193321.GX17123@deviant.kiev.zoral.com.ua> <20080715204703.1xshles8aogwksw4@mail.basicnets.co.uk> Message-ID: <487D037A.8060208@FreeBSD.org> john@basicnets.co.uk wrote: > > > >> #9 0xffffffff8067d3ee in uma_zalloc_arg (zone=0xffffff00bfed07e0, >>> udata=0x0, >>> flags=-256) at /usr/src/sys/vm/uma_core.c:1835 >> From the frame #9, please do >> p *zone >> I am esp. interested in the value of the uz_ctor member. >> >> It seems that it becomes corrupted, it value should be 0, as this seems >> to be ffs inode zone. I suspect that gdb would show 0x6400000000 >> instead. > > I am afraid that you may need to spell out each step for me :-( > > (kgdb) p *zone > No symbol "zone" in current context. > (kgdb) list *0xffffffff8067d3ee > 0xffffffff8067d3ee is in uma_zalloc_arg (/usr/src/sys/vm/uma_core.c:1835). > 1830 ("uma_zalloc: Bucket pointer > mangled.")); > 1831 cache->uc_allocs++; > 1832 critical_exit(); > 1833 #ifdef INVARIANTS > 1834 ZONE_LOCK(zone); > 1835 uma_dbg_alloc(zone, NULL, item); > 1836 ZONE_UNLOCK(zone); > 1837 #endif > 1838 if (zone->uz_ctor != NULL) { > 1839 if (zone->uz_ctor(item, > zone->uz_keg->uk_size, > > Is this that you were looking for? Are you sure that is the same source tree you are running? The 7.0-RELEASE source has the zone->uz_ctor on line 1835, which is consistent with your backtrace. Kris From alex at trull.org Tue Jul 15 20:09:19 2008 From: alex at trull.org (Alex Trull) Date: Tue Jul 15 20:09:27 2008 Subject: taskqueue timeout In-Reply-To: <200807151955.m6FJtf77008969@apollo.backplane.com> References: <487CCD46.8080506@ibctech.ca> <200807151711.m6FHBgVO007481@apollo.backplane.com> <487CF077.2040201@ibctech.ca> <487CFA08.5000308@ibctech.ca> <200807151955.m6FJtf77008969@apollo.backplane.com> Message-ID: <1216152552.6517.56.camel@porksoda> Don't want to give conflicting advice, and would suggest you certainly try the 30 sec thing first. I'm already on 10 myself but haven't pushed further. In my own case I've not had any issue with zfs in particular since I applied the ZFS zil/prefetch disable loader.conf tunables 10 hours ago. I am observing this now. For the record .. What ata chipset/motherboard and model of disk have you got ? Have you seen any smart errors (real or otherwise) ? What do your 'zpool status' counters look like ? -- Alex On Tue, 2008-07-15 at 12:55 -0700, Matthew Dillon wrote: > :Went from 10->15, and it took quite a bit longer into the backup before > :the problem cropped back up. > > Try 30 or longer. See if you can make the problem go away entirely. > then fall back to 5 and see if the problem resumes at its earlier > pace. > > -- > > It could be temperature related. The drives are being exercised > a lot, they could very well be overheating. To find out add more > airflow (a big house fan would do the trick). > > -- > > It could be that errors are accumulating on the drives, but it seems > unlikely that four drives would exhibit the same problem. > > -- > > Also make sure the power supply can handle four drives. Most power > supplies that come with consumer boxes can't under full load if you > also have a mid or high-end graphics card installed. Power supplies > that come with OEM slap-together enclosures are not usually much better. > > Specifically, look at the +5V and +12V amperage maximums on the power > supply, then check the disk labels to see what they draw, then > multiply by 2. e.g. if your power supply can do 30A@12V and you have > four drives each taking 2A@12V (and typically ~half that at 5V), thats > 4x2x2 = 16A@12V and you would probably be ok. > > To test, remove two of the four drives, reformat the ZFS to use just 2, > and see if the problem reoccurs with just two drives. > > -Matt > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080715/9342876f/attachment.pgp From horechuk at csolve.net Tue Jul 15 20:24:10 2008 From: horechuk at csolve.net (Paul Horechuk) Date: Tue Jul 15 20:24:18 2008 Subject: Konqueror and the Cookiejar Message-ID: <200807151557.52338.horechuk@csolve.net> Since upgrading to 7.0 Stable, I've noticed an occasional problem with konqueror. I've been recompiling my ports for the past few weeks and have noticed that some sites are complaining about cookies not being enabled. Further investigation has revealed that if I start konqueror from the terminal prompt, I can get an error message: khtml (dom) Can't communicate with the cookiejar! A workaround I've discovered is to run kded first. Konqueror works with cookies after that. Question: What process is NOT running kded during the startx process? Where is there a log to track this? -- Paul Horechuk Think Free Use Open Source Software ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From koitsu at FreeBSD.org Tue Jul 15 20:51:29 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Jul 15 20:51:36 2008 Subject: Multi-machine mirroring choices In-Reply-To: <487CD9ED.1090207@FreeBSD.org> References: <1216130834.27608.27.camel@lanshark.dmv.com> <20080715145426.GA31340@eos.sc1.parodius.com> <20080715162912.GI64436@atarininja.org> <487CD9ED.1090207@FreeBSD.org> Message-ID: <20080715205129.GA56105@eos.sc1.parodius.com> On Tue, Jul 15, 2008 at 07:10:05PM +0200, Kris Kennaway wrote: > Wesley Shields wrote: >> On Tue, Jul 15, 2008 at 07:54:26AM -0700, Jeremy Chadwick wrote: >>> One of the "annoyances" to ZFS snapshots, however, was that I had to >>> write my own script to do snapshot rotations (think incremental dump(8) >>> but using ZFS snapshots). >> >> There is a PR[1] to get something like this in the ports tree. I have >> no idea how good it is but I hope to get it in the tree soon. >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/125340 > > There is also sysutils/freebsd-snapshot (pkg-descr is out of date, it > supports ZFS too). > > I found it more convenient to just write my own tiny script. Thanks for pointing this out -- I had no idea such a port existed! -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Tue Jul 15 21:05:53 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Jul 15 21:05:59 2008 Subject: Multi-machine mirroring choices In-Reply-To: <1216136877.27608.36.camel@lanshark.dmv.com> References: <1216130834.27608.27.camel@lanshark.dmv.com> <20080715145426.GA31340@eos.sc1.parodius.com> <1216136877.27608.36.camel@lanshark.dmv.com> Message-ID: <20080715210553.GA56968@eos.sc1.parodius.com> On Tue, Jul 15, 2008 at 11:47:57AM -0400, Sven Willenberger wrote: > On Tue, 2008-07-15 at 07:54 -0700, Jeremy Chadwick wrote: > > ZFS's send/recv capability (over a network) is something I didn't have > > time to experiment with, but it looked *very* promising. The method is > > documented in the manpage as "Example 12", and is very simple -- as it > > should be. You don't have to use SSH either, by the way[1]. > > The examples do list ssh as the way of initiating the receiving end; I > am curious as to what the alterative would be (short of installing > openssh-portable and using cipher=no). rsh or netcat come to mind. I haven't tried using either though. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From kris at FreeBSD.org Tue Jul 15 21:19:06 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Tue Jul 15 21:19:13 2008 Subject: Multi-machine mirroring choices In-Reply-To: <20080715210553.GA56968@eos.sc1.parodius.com> References: <1216130834.27608.27.camel@lanshark.dmv.com> <20080715145426.GA31340@eos.sc1.parodius.com> <1216136877.27608.36.camel@lanshark.dmv.com> <20080715210553.GA56968@eos.sc1.parodius.com> Message-ID: <487D144A.7060301@FreeBSD.org> Jeremy Chadwick wrote: > On Tue, Jul 15, 2008 at 11:47:57AM -0400, Sven Willenberger wrote: >> On Tue, 2008-07-15 at 07:54 -0700, Jeremy Chadwick wrote: >>> ZFS's send/recv capability (over a network) is something I didn't have >>> time to experiment with, but it looked *very* promising. The method is >>> documented in the manpage as "Example 12", and is very simple -- as it >>> should be. You don't have to use SSH either, by the way[1]. >> The examples do list ssh as the way of initiating the receiving end; I >> am curious as to what the alterative would be (short of installing >> openssh-portable and using cipher=no). > > rsh or netcat come to mind. I haven't tried using either though. > I wouldn't recommend either for the obvious reasons: weak or no authentication and integrity protection. Even if the former is not a concern for some reason then the latter should be (your data stream could be corrupted in transit and you'd never know until you tried to verify or restore the backup). Kris From andrew at modulus.org Wed Jul 16 01:10:26 2008 From: andrew at modulus.org (Andrew Snow) Date: Wed Jul 16 01:10:34 2008 Subject: taskqueue timeout In-Reply-To: <200807151711.m6FHBgVO007481@apollo.backplane.com> References: <487CCD46.8080506@ibctech.ca> <200807151711.m6FHBgVO007481@apollo.backplane.com> Message-ID: <487D4A2A.9010508@modulus.org> Matthew Dillon wrote: > Try that first. If it helps then it is a known issue. Basically > a combination of the on-disk write cache and possible ECC corrections, > remappings, or excessive remapped sectors can cause the drive to take > much longer then normal to complete a request. The default 5-second > timeout is insufficient. From Western Digital's line of "enterprise" drives: "RAID-specific time-limited error recovery (TLER) - Pioneered by WD, this feature prevents drive fallout caused by the extended hard drive error-recovery processes common to desktop drives." Western Digital's information sheet on TLER states that they found most RAID controllers will wait 8 seconds for a disk to respond before dropping it from the RAID set. Consequently they changed their "enterprise" drives to try reading a bad sector for only 7 seconds before returning an error. Therefore I think the FreeBSD timeout should also be set to 8 seconds instead of 5 seconds. Desktop-targetted drives will not respond for over 10 seconds, up to minutes, so its not worth setting the FreeBSD timeout any higher. More info: http://www.wdc.com/en/library/sata/2579-001098.pdf http://en.wikipedia.org/wiki/Time-Limited_Error_Recovery - Andrew From steve at ibctech.ca Wed Jul 16 02:29:29 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Wed Jul 16 02:29:37 2008 Subject: taskqueue timeout In-Reply-To: <200807151955.m6FJtf77008969@apollo.backplane.com> References: <487CCD46.8080506@ibctech.ca> <200807151711.m6FHBgVO007481@apollo.backplane.com> <487CF077.2040201@ibctech.ca> <487CFA08.5000308@ibctech.ca> <200807151955.m6FJtf77008969@apollo.backplane.com> Message-ID: <487D5D08.9070102@ibctech.ca> Matthew Dillon wrote: > :Went from 10->15, and it took quite a bit longer into the backup before > :the problem cropped back up. Jumping right into it, there is another post after this one, but I'm going to try to reply inline: > Try 30 or longer. See if you can make the problem go away entirely. > then fall back to 5 and see if the problem resumes at its earlier > pace. I'm sure 30 will either push the issue longer, or into non-existence, but are there any developers here who can say what this timer does? ie. How does changing this timer affect the performance of the disk subsystem (aside from allowing it to work, of course). After I'm done responding this message, I'll be testing the sysctl to 30. > It could be temperature related. The drives are being exercised > a lot, they could very well be overheating. To find out add more > airflow (a big house fan would do the trick). > Temperature is a good thought, but currently, my physical situation has this: - 2U chassis - multiple fans in the case - in my lab (which is essentially beside my desk) - the case has no lid - it is 64 degrees with A/C and circulating fans in this area - hard drives are separated relatively well inside the case > It could be that errors are accumulating on the drives, but it seems > unlikely that four drives would exhibit the same problem. Thats what I'm thinking. All four drives are exhibiting the same errors... or, for all intents and purposes, the machine is coughing the same errors for all the drives. > Also make sure the power supply can handle four drives. Most power > supplies that come with consumer boxes can't under full load if you > also have a mid or high-end graphics card installed. Power supplies > that come with OEM slap-together enclosures are not usually much better. I currently have a 550W PSU in the 2U chassis, which again, is sitting open. I have more hardware, running in worse conditions with less wattage PSUs that don't exhibit this behavior. I need to determine whether this problem is SATA, ZFS, the motherboard or code. > Specifically, look at the +5V and +12V amperage maximums on the power > supply, then check the disk labels to see what they draw, then > multiply by 2. e.g. if your power supply can do 30A@12V and you have > four drives each taking 2A@12V (and typically ~half that at 5V), thats > 4x2x2 = 16A@12V and you would probably be ok. I'm well within specs. Even after V/A tests with the meter. The power supply is providing ample wattage to each device accordingly. > To test, remove two of the four drives, reformat the ZFS to use just 2, > and see if the problem reoccurs with just two drives. ... I knew that was going to come up... my response is "I worked so hard to get this system with ZFS all configured *exactly* how I wanted it". To test, I'm going to flip to 30 as per Matthews recommendation, and see how far that takes me. At this time, I'm only testing by backing up one machine on the network. If it fails, I'll clock the time, and then 'reformat' with two drives. Is there a technical reason this may work better with only two drives? Is there anyone interested to the point where remote login would be helpful? Steve From koitsu at FreeBSD.org Wed Jul 16 02:39:15 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Jul 16 02:39:22 2008 Subject: taskqueue timeout In-Reply-To: <487D5D08.9070102@ibctech.ca> References: <487CCD46.8080506@ibctech.ca> <200807151711.m6FHBgVO007481@apollo.backplane.com> <487CF077.2040201@ibctech.ca> <487CFA08.5000308@ibctech.ca> <200807151955.m6FJtf77008969@apollo.backplane.com> <487D5D08.9070102@ibctech.ca> Message-ID: <20080716023915.GA77532@eos.sc1.parodius.com> On Tue, Jul 15, 2008 at 10:29:28PM -0400, Steve Bertrand wrote: > Is there anyone interested to the point where remote login would be helpful? I believe my FreeBSD Wiki page documents what to do if your problem is easily reproducable: contact Scott Long, who has offered to help track down the source of these problems. I'll reply to the other part of your mail in a bit. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From steve at ibctech.ca Wed Jul 16 02:44:01 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Wed Jul 16 02:44:07 2008 Subject: taskqueue timeout In-Reply-To: <1216152552.6517.56.camel@porksoda> References: <487CCD46.8080506@ibctech.ca> <200807151711.m6FHBgVO007481@apollo.backplane.com> <487CF077.2040201@ibctech.ca> <487CFA08.5000308@ibctech.ca> <200807151955.m6FJtf77008969@apollo.backplane.com> <1216152552.6517.56.camel@porksoda> Message-ID: <487D6070.6050802@ibctech.ca> Alex Trull wrote: > Don't want to give conflicting advice, and would suggest you certainly > try the 30 sec thing first. I'm already on 10 myself but haven't pushed > further. What were you doing, and what did you notice when the problem started? As much as it seems silly, I'm mostly interested in what your network was doing at the time things went sour. > In my own case I've not had any issue with zfs in particular since I > applied the ZFS zil/prefetch disable loader.conf tunables 10 hours ago. > I am observing this now. For some reason, and with no explanation or science behind it, I don't think this is a ZFS problem, and I'm trying to defend this thought to my peers until I prove otherwise. I have to be a bit careful on how I adjust loader properties, given that I'm loading from USB, and mounting root from a ZFS zpool hard disk. Like my GELI systems, tweaking things can be a bit touchy unless I put a little more planning into it. > For the record .. > > What ata chipset/motherboard and model of disk have you got ? I'm not a hardware person per-se, but I'm advised to post that the motherboard is: - XFS nForce 610i with GeForce 7050 If there is more hardware info I can provide, let me know specifically what I should be looking for. > Have you seen any smart errors (real or otherwise) ? > What do your 'zpool status' counters look like ? zpool status is always clean. There are no errors otherwise, even if the box is up for multiple hours straight. The problem occurs only if I through work at it. Steve From steve at ibctech.ca Wed Jul 16 03:16:12 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Wed Jul 16 03:16:19 2008 Subject: taskqueue timeout In-Reply-To: <20080716023915.GA77532@eos.sc1.parodius.com> References: <487CCD46.8080506@ibctech.ca> <200807151711.m6FHBgVO007481@apollo.backplane.com> <487CF077.2040201@ibctech.ca> <487CFA08.5000308@ibctech.ca> <200807151955.m6FJtf77008969@apollo.backplane.com> <487D5D08.9070102@ibctech.ca> <20080716023915.GA77532@eos.sc1.parodius.com> Message-ID: <487D67FB.6010509@ibctech.ca> Jeremy Chadwick wrote: > On Tue, Jul 15, 2008 at 10:29:28PM -0400, Steve Bertrand wrote: >> Is there anyone interested to the point where remote login would be helpful? > > I believe my FreeBSD Wiki page documents what to do if your problem > is easily reproducable: contact Scott Long, who has offered to help > track down the source of these problems. Changing to 30 second timeout made no difference whatsoever. The problem occurred at about the same time during the single I'm at a standstill. I'm willing to help provide any information necessary to fix this issue, or provide remote access to the box in question. scottl@ has been Cc:'d. Thanks all, Steve From oberman at es.net Wed Jul 16 03:16:42 2008 From: oberman at es.net (Kevin Oberman) Date: Wed Jul 16 03:16:49 2008 Subject: Fresh 7.0 Install: Fatal Trap 12 panic when put under load In-Reply-To: Your message of "Tue, 15 Jul 2008 10:58:19 BST." <854CADB9D95147CAB10BC35887A8E5DC@emea.hubersuhner.net> Message-ID: <20080716031640.7DC744500E@ptavv.es.net> > From: "John Sullivan" > Date: Tue, 15 Jul 2008 10:58:19 +0100 > Sender: owner-freebsd-stable@freebsd.org > > I am experiencing 'random' reboots interspersed with panics whenever I put a newly installed system under load (make index in > /usr/ports is enough). A sample panic is at the end of this email. > > I have updated to 7.0-RELEASE-p2 using the GENERIC amd64 kernel and it is still the same. The system is a Gigabyte GA-M56S-S3 > motherboard with 4GB of RAM, an Athlon X2 6400+ and 3 x Maxtor SATA 750GB HDD's (only the first is currently in use). The first > disk is all allocated to FreeBSD using UFS. There is also a Linksys 802.11a/b/g card installed. I have flashed the BIOS to the > latest revision (F4e). The onboard RAID is disabled. > > At the moment there is no exotic software installed. > > Although I have been using FreeBSD for a number of years this is the first time I have experienced regular panics and am at a > complete loss trying to work out what is wrong. I would be grateful for any advice anyone is willing to give to help me > troubleshoot this issue. > > Thanks in advance > > John > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x800000b0 > fault code - supervisor write data, page not present > instruction pointer = 0x8:0xffffffff804db18c > stack pointer = 0x10:ffffffffb1e92450 > frame pointer = 0x10:ffffffec > code segment = base 0x0, limit 0xfffff, type 0x16, DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interupt enabled, resume, IOPL = 0 > current processkernel trap 12 with interrupts disabled > > #nm -n /boot/kernel/kernel | grep ffffffff804db > ffffffff804dbac0 t flushbufqueues Could be memory, but I'd also suggest looking at temperatures. I've had overheating systems produce lots of such errors. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080716/9fb539f5/attachment.pgp From dillon at apollo.backplane.com Wed Jul 16 03:27:43 2008 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Wed Jul 16 03:27:53 2008 Subject: taskqueue timeout References: <487CCD46.8080506@ibctech.ca> <200807151711.m6FHBgVO007481@apollo.backplane.com> <487CF077.2040201@ibctech.ca> <487CFA08.5000308@ibctech.ca> <200807151955.m6FJtf77008969@apollo.backplane.com> <487D5D08.9070102@ibctech.ca> Message-ID: <200807160327.m6G3Rh57012575@apollo.backplane.com> :... :> and see if the problem reoccurs with just two drives. : :... I knew that was going to come up... my response is "I worked so hard :to get this system with ZFS all configured *exactly* how I wanted it". : :To test, I'm going to flip to 30 as per Matthews recommendation, and see :how far that takes me. At this time, I'm only testing by backing up one :machine on the network. If it fails, I'll clock the time, and then :'reformat' with two drives. : :Is there a technical reason this may work better with only two drives? : :Is there anyone interested to the point where remote login would be helpful? : :Steve This issue is vexing a lot of people. Setting the timeout to 30 will not effect performance, but it will cause a 30 second delay in recovery when (if) the problem occurs. i.e. when the disk stalls it will just sit there doing nothing for 30 seconds, then it will print the timeout message and try to recover. It occurs to me that it might be beneficial to actually measure the disk's response time to each request, and then graph it over a period of time. Maybe seeing the issue visually will give some clue as to the actual cause. -Matt Matthew Dillon From steve at ibctech.ca Wed Jul 16 03:34:13 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Wed Jul 16 03:34:20 2008 Subject: taskqueue timeout In-Reply-To: <487D4A2A.9010508@modulus.org> References: <487CCD46.8080506@ibctech.ca> <200807151711.m6FHBgVO007481@apollo.backplane.com> <487D4A2A.9010508@modulus.org> Message-ID: <487D6C33.2060409@ibctech.ca> Andrew Snow wrote: > From Western Digital's line of "enterprise" drives: > > "RAID-specific time-limited error recovery (TLER) - Pioneered by WD, > this feature prevents drive fallout caused by the extended hard drive > error-recovery processes common to desktop drives." > Therefore I think the FreeBSD timeout should also be set to 8 seconds > instead of 5 seconds. Desktop-targetted drives will not respond for > over 10 seconds, up to minutes, so its not worth setting the FreeBSD > timeout any higher. Interesting you say this. To reiterate, I have /boot on USB thumb drive, and the system is mounted from / on a raidz pool called /storage via loader.conf. The four drives in question (per the packaging) are: - Western Digital Caviar SE16 500GB - 7200, 16MB, SATA-300, OEM Per the packaging on the rest of the hardware: # mobo - XFX 610i, 7050 GeForce (I *never* use graphics on my FreeBSD boxen, I *only* know/have CLI with no 'windows') # memory - 2 GB Corsair XMS2 Twin2X 6400C4 memory # cpu - Intel Pentium DC E2200 2.20GHz OEM - 2.20 GHz, 1MB Cache, 800MHz FSB, Allendale, Dual Core, OEM, Socket 775, Processor # swap - I don't run any, but can/will add in an IDE/ATA 7200 200GB in the event this problem may be related to ZFS/RAM issues. Steve From kkutzko at teksavvy.com Wed Jul 16 03:42:43 2008 From: kkutzko at teksavvy.com (Kevin K) Date: Wed Jul 16 03:42:50 2008 Subject: HP Pavilion dv2000 laptop wont boot off install cd Message-ID: <001301c8e6f5$cc68dee0$653a9ca0$@com> Laptop details : HP Pavilion dv2000 (dv2422ca) Specifications (taken from http://h10025.www1.hp.com/ewfrf/wc/document?cc=au&docname=c01070158&dlc=en&l c=en&jumpid=reg_R1002_AUEN ) : Product Name: dv2422ca Product Number: GM039UA#ABC / GM039UA#ABL Microprocessor: 1.8 GHz AMD Turion T 64 X2 Dual-Core Mobile Technology TL-56 Microprocessor Cache: 512KB+512KB L2 Cache Memory: 2048 MB DDR2 System Memory (2 Dimm) I tried to boot from 7.0-release-AMD64, 7.0-release-i386 and 6.2-release-i386 install disks (about to try 6.3-release-amd64). I could not successfully boot up the computer using the install disks mentioned. Sometimes there would be a memory dump (scrolling infinitely), sometimes I would get the following message(s) : elf_32_lookup_symbol : corrupt symbol table loading required module 'pci' ACPI autoload failed - no such file or directory \ int=00000006 err=00000000 efl=00010002 eip=00000003 eax=00449130 ebx=00000000 ecx=004f010f edx=0003fa40 esi=00000000 edi=00000000 ebp=00000000 esp=000928b0 cs=0008 ds=0010 es=0010 fs=0010 gs=0010 ss=0010 cs:eip= f0 53 ff 00 f0 c3 e2 00-f0 53 ff 00 f0 53 ff 00 f0 54 ff 00 f0 8a a8 00-f0 53 ff 00 f0 a5 fe 00 ss:esp= 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 BTX halted There is no significant BIOS option in this laptop that I can think of to at least begin to trouble shoot this issue. Laptop works fine for other operating systems as far as I can tell. Initial documentation suggests that this laptop should work, however, I'd like to get some more insight from freebsd-stable before continuing. If any additional information is required, please let me know. Cheers, Kevin K. From steve at ibctech.ca Wed Jul 16 03:45:15 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Wed Jul 16 03:45:24 2008 Subject: taskqueue timeout In-Reply-To: <200807160327.m6G3Rh57012575@apollo.backplane.com> References: <487CCD46.8080506@ibctech.ca> <200807151711.m6FHBgVO007481@apollo.backplane.com> <487CF077.2040201@ibctech.ca> <487CFA08.5000308@ibctech.ca> <200807151955.m6FJtf77008969@apollo.backplane.com> <487D5D08.9070102@ibctech.ca> <200807160327.m6G3Rh57012575@apollo.backplane.com> Message-ID: <487D6ECA.9040706@ibctech.ca> Matthew Dillon wrote: > This issue is vexing a lot of people. Heh... I can appreciate this. I would like someone to inform me that this can't be guaranteed to be a ZFS problem... if I can get confirmation that others have this issue aside from ZFS, I would feel content. > Setting the timeout to 30 will not effect performance, but it will > cause a 30 second delay in recovery when (if) the problem occurs. > i.e. when the disk stalls it will just sit there doing nothing for > 30 seconds, then it will print the timeout message and try to recover. If I have the timeout at >= 30 and the issue still occurs, the problem must be elsewhere. > It occurs to me that it might be beneficial to actually measure the > disk's response time to each request, and then graph it over a period > of time. Maybe seeing the issue visually will give some clue as to the > actual cause. I am interested in following through with this, but can't do it on my own. I'm willing to dedicate the box and bandwidth to anyone who can legitimately test this as you state. ie: I need either guidance or assistance. This box is ready for the taking. Beyond this box, I can provide legitimate parties other network resources to produce a consistent flow of data to ensure the ability to easily reproduce the issue locally, on demand. Steve From achill at matrix.gatewaynet.com Wed Jul 16 08:02:15 2008 From: achill at matrix.gatewaynet.com (Achilleas Mantzios) Date: Wed Jul 16 08:02:23 2008 Subject: softdepflush bad block error has led to negative blocks in free inode and handle_workitem_freeblocks: block count In-Reply-To: <200807151958.12955.achill@matrix.gatewaynet.com> References: <200807151958.12955.achill@matrix.gatewaynet.com> Message-ID: <200807161042.49063.achill@matrix.gatewaynet.com> ???? Tuesday 15 July 2008 19:58:12 ?/? Achilleas Mantzios ??????: > Hi, > The problem started when i installed a kodicom 4400 card and started to run zoneminder. > Prior to that no problems with my machine, which now runs > FreeBSD panix.internal.net 7.0-RELEASE-p3 FreeBSD 7.0-RELEASE-p3 #3: Mon Jul 14 16:35:37 EEST 2008 > doroot@panix.internal.net:/usr/obj/usr/src/sys/GENERIC i386 > This hardware change happened in Sunday Jul 13. > The next day (Jul 14) morning "periodic daily" cron job at 03:01 gave: > /var/log/messages.1.bz2:Jul 14 03:01:04 panix kernel: pid 48 (softdepflush), uid 0 inumber 2662656 on /usr: bad block > /var/log/messages.1.bz2:Jul 14 03:01:04 panix kernel: pid 48 (softdepflush), uid 0 inumber 2662656 on /usr: bad block > /var/log/messages.1.bz2:Jul 14 03:01:04 panix kernel: pid 48 (softdepflush), uid 0 inumber 2662656 on /usr: bad block > /var/log/messages.1.bz2:Jul 14 03:01:04 panix kernel: pid 48 (softdepflush), uid 0 inumber 2662656 on /usr: bad block > ... (15 times) > The funny think is that "df -h" showed a huge negative capacity. > Yesterday (Mon Jul 14) i had a crash when i tried to run (by hand) pkg_info . > Today (Mon Jul 15) the morning "periodic daily" cron job resulted in a crash as well in when running find. > > I speculated that it was one of those cases that bad memory, or overheated memory could cause such problems > and i removed the most suspicious sim. After that i didnt get any crashes when trying to run pkg_info or > periodic daily,weekly,monthly, but i get the following whenever i run periodic weekly: > panix kernel: free inode /usr/2662656 had -3549356 blocks (negative) > and after a while > panix kernel: handle_workitem_freeblocks: block count > > I suspect that even if i have a healthy system as far as memory is concerned (i hope), > the problem with the 2662656 inode is still there. > > Any thoughts are very welcome. > I cleared the inode 2662656 with fsdb and clri and rerun fsck, and this seems to have eliminated the problem. -- Achilleas Mantzios From john at basicnets.co.uk Wed Jul 16 08:38:37 2008 From: john at basicnets.co.uk (John Sullivan) Date: Wed Jul 16 08:38:44 2008 Subject: Fresh 7.0 Install: Fatal Trap 12 panic when put under load In-Reply-To: <20080716031640.7DC744500E@ptavv.es.net> References: Your message of "Tue, 15 Jul 2008 10:58:19 BST." <854CADB9D95147CAB10BC35887A8E5DC@emea.hubersuhner.net> <20080716031640.7DC744500E@ptavv.es.net> Message-ID: > Could be memory, but I'd also suggest looking at > temperatures. I've had overheating systems produce lots of > such errors. Temperature is fine - it never get's that hot here in the UK ;-) Seriously, I put my hand in the box, touched a few heat sync's, it is not running hot enough to cause a problem. The BIOS reports that all is well with the temperature inside the box of just over 30 degrees C. John From kkutzko at teksavvy.com Wed Jul 16 09:04:06 2008 From: kkutzko at teksavvy.com (Kevin K) Date: Wed Jul 16 09:04:14 2008 Subject: HP Pavilion dv2000 laptop wont boot off install cd In-Reply-To: <001301c8e6f5$cc68dee0$653a9ca0$@com> References: <001301c8e6f5$cc68dee0$653a9ca0$@com> Message-ID: <001a01c8e722$dcaf27f0$960d77d0$@com> > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > stable@freebsd.org] On Behalf Of Kevin K > Sent: Tuesday, July 15, 2008 11:41 PM > To: 'FreeBSD Stable' > Subject: HP Pavilion dv2000 laptop wont boot off install cd > > Laptop details : > > HP Pavilion dv2000 (dv2422ca) > > Specifications (taken from > http://h10025.www1.hp.com/ewfrf/wc/document?cc=au&docname=c01070158&dlc > =en&l > c=en&jumpid=reg_R1002_AUEN ) : > > Product Name: dv2422ca > Product Number: GM039UA#ABC / GM039UA#ABL > Microprocessor: 1.8 GHz AMD Turion T 64 X2 Dual-Core Mobile > Technology TL-56 > Microprocessor Cache: 512KB+512KB L2 Cache > Memory: 2048 MB DDR2 System Memory (2 Dimm) > > > I tried to boot from 7.0-release-AMD64, 7.0-release-i386 and > 6.2-release-i386 install disks (about to try 6.3-release-amd64). I > could not > successfully boot up the computer using the install disks mentioned. > Sometimes there would be a memory dump (scrolling infinitely), > sometimes I > would get the following message(s) : > > > elf_32_lookup_symbol : corrupt symbol table > > loading required module 'pci' > ACPI autoload failed - no such file or directory > \ > int=00000006 err=00000000 efl=00010002 eip=00000003 > eax=00449130 ebx=00000000 ecx=004f010f edx=0003fa40 > esi=00000000 edi=00000000 ebp=00000000 esp=000928b0 > cs=0008 ds=0010 es=0010 fs=0010 gs=0010 ss=0010 > cs:eip= f0 53 ff 00 f0 c3 e2 00-f0 53 ff 00 f0 53 ff 00 > f0 54 ff 00 f0 8a a8 00-f0 53 ff 00 f0 a5 fe 00 > ss:esp= 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 > BTX halted > > > There is no significant BIOS option in this laptop that I can think of > to at > least begin to trouble shoot this issue. Laptop works fine for other > operating systems as far as I can tell. > > Initial documentation suggests that this laptop should work, however, > I'd > like to get some more insight from freebsd-stable before continuing. > > > If any additional information is required, please let me know. > > > > Cheers, > > Kevin K. > It should be noted that I just tried 6.3-release-amd64 and it doesn't work as well. It should also be important to note that sometimes it 'dumps' before getting to the boot options screen in the freebsd startup. If I do get to that screen, I have tried "disable ACPI", to no effect. ~k From koitsu at FreeBSD.org Wed Jul 16 09:21:56 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Jul 16 09:22:02 2008 Subject: HP Pavilion dv2000 laptop wont boot off install cd In-Reply-To: <001a01c8e722$dcaf27f0$960d77d0$@com> References: <001301c8e6f5$cc68dee0$653a9ca0$@com> <001a01c8e722$dcaf27f0$960d77d0$@com> Message-ID: <20080716092155.GA98604@eos.sc1.parodius.com> On Wed, Jul 16, 2008 at 05:03:49AM -0400, Kevin K wrote: > It should be noted that I just tried 6.3-release-amd64 and it doesn't work > as well. > > It should also be important to note that sometimes it 'dumps' before getting > to the boot options screen in the freebsd startup. > > If I do get to that screen, I have tried "disable ACPI", to no effect. It sounds to me like you might be running into the problem others have reported with boot2/loader. The "continual scrolling of data" is probably a register dump from forth. John, do you have any tips/ideas? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From ari at ish.com.au Wed Jul 16 09:54:34 2008 From: ari at ish.com.au (Aristedes Maniatis) Date: Wed Jul 16 09:55:05 2008 Subject: Multi-machine mirroring choices In-Reply-To: <20080715145426.GA31340@eos.sc1.parodius.com> References: <1216130834.27608.27.camel@lanshark.dmv.com> <20080715145426.GA31340@eos.sc1.parodius.com> Message-ID: <512C3A9B-5C0C-4DB6-8916-8E2898DD06A5@ish.com.au> On 15/07/2008, at 3:54 PM, Jeremy Chadwick wrote: > We moved all of our production systems off of using dump/restore > solely > because of these aspects. We didn't move to ZFS though; we went with > rsync, which is great, except for the fact that it modifies file > atimes > (hope you use Maildir and not classic mbox/mail spools...). We do something similar, except that we use unison rather than rsync. This tool is a two way rsync, it deals with collisions and replicating files in both directions at once. Very nice. Look for it in the ports tree. This has some advantages for us since we distribute load across several machines and have a cluster of machines which all replicate to each other. The data is such that collisions are almost never a concern. Ari Maniatis --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From andrew at modulus.org Wed Jul 16 11:50:07 2008 From: andrew at modulus.org (Andrew Snow) Date: Wed Jul 16 11:50:15 2008 Subject: Multi-machine mirroring choices In-Reply-To: <512C3A9B-5C0C-4DB6-8916-8E2898DD06A5@ish.com.au> References: <1216130834.27608.27.camel@lanshark.dmv.com> <20080715145426.GA31340@eos.sc1.parodius.com> <512C3A9B-5C0C-4DB6-8916-8E2898DD06A5@ish.com.au> Message-ID: <487DE064.6020002@modulus.org> We have deployed an IMAP server running on Cyrus on FreeBSD 6.2, with a 500GB UFS2 partition mirrored with geom_mirror and geom_gate across a dedicated 1gbps link. It has proven to be very stable and reliable after appropriate tweaking. The uptime of the mirror is usually 1-3 months, sometimes it seems to break randomly, possibly because our timeout is too low. In any case, it doesn't take too long to rebuild at about 60mb/s. (I recently tested the same solution with FreeBSD-7 and found it now goes at a full 100mb/s.) From olli at lurza.secnetix.de Wed Jul 16 13:53:17 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Wed Jul 16 13:53:24 2008 Subject: HP Pavilion dv2000 laptop wont boot off install cd In-Reply-To: Message-ID: <200807161353.m6GDrDFB058142@lurza.secnetix.de> Kevin K wrote: > I tried to boot from 7.0-release-AMD64, 7.0-release-i386 and > 6.2-release-i386 install disks (about to try 6.3-release-amd64). I could not > successfully boot up the computer using the install disks mentioned. > Sometimes there would be a memory dump (scrolling infinitely), sometimes I > would get the following message(s) : Please try one of the more recent 7-stable snapshots from June or July. They're located on the FTP sites in /pub/FreeBSD/snapshots. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd With Perl you can manipulate text, interact with programs, talk over networks, drive Web pages, perform arbitrary precision arithmetic, and write programs that look like Snoopy swearing. From kkutzko at teksavvy.com Wed Jul 16 14:04:20 2008 From: kkutzko at teksavvy.com (Kevin K) Date: Wed Jul 16 14:04:27 2008 Subject: HP Pavilion dv2000 laptop wont boot off install cd In-Reply-To: <200807161353.m6GDrDFB058142@lurza.secnetix.de> References: <200807161353.m6GDrDFB058142@lurza.secnetix.de> Message-ID: <004a01c8e74c$cd95daa0$68c18fe0$@com> > Please try one of the more recent 7-stable snapshots > from June or July. They're located on the FTP sites > in /pub/FreeBSD/snapshots. > > Best regards > Oliver This was actually just recommended to me by Gavin Atkinson earlier today. I am downloading 7.0-STABLE-200806-amd64-disc1.iso right now and will try that today. I'll post the results of that here. Thanks all for your help. ~k From kkutzko at teksavvy.com Wed Jul 16 14:25:42 2008 From: kkutzko at teksavvy.com (Kevin K) Date: Wed Jul 16 14:25:49 2008 Subject: HP Pavilion dv2000 laptop wont boot off install cd In-Reply-To: <004a01c8e74c$cd95daa0$68c18fe0$@com> References: <200807161353.m6GDrDFB058142@lurza.secnetix.de> <004a01c8e74c$cd95daa0$68c18fe0$@com> Message-ID: <004b01c8e74f$c9d1c660$5d755320$@com> > > Please try one of the more recent 7-stable snapshots > > from June or July. They're located on the FTP sites > > in /pub/FreeBSD/snapshots. > > > > Best regards > > Oliver > > This was actually just recommended to me by Gavin Atkinson earlier > today. I > am downloading 7.0-STABLE-200806-amd64-disc1.iso right now and will try > that > today. Okay I just tried the above snapshot and there are still problems -- I'm not getting the BTX error message nor the infinite scrolling hex dump, but it sits at loading /boot/default/loader.conf for about 5-10 seconds then does a straight reboot without any discernable error message. After doing some more digging, I found one suggestion from someone who experienced a similar problem with an HP Pavilion ze2000 w/ amd64 turion processor : "Installation hangs at boot until you disable the apic and serial ports as follows in the boot loader command line: set hint.apic.0.disabled=1 set hint.sio.0.disabled=1 set hint.sio.1.disabled=1" I'm going to try this and see if that helps. I don't really need the serial ports on this laptop anyways, so maybe it will work. If anyone has any other suggestions, it would be greatly appreciated. Many thanks, Kevin K. From john at basicnets.co.uk Wed Jul 16 14:56:35 2008 From: john at basicnets.co.uk (John Sullivan) Date: Wed Jul 16 14:56:42 2008 Subject: Fresh 7.0 Install: Fatal Trap 12 panic when put under load In-Reply-To: <62b856460807160743v3fce951eg1b2bd9e50a35ba1d@mail.gmail.com> References: <854CADB9D95147CAB10BC35887A8E5DC@emea.hubersuhner.net> <20080716031640.7DC744500E@ptavv.es.net> <62b856460807160743v3fce951eg1b2bd9e50a35ba1d@mail.gmail.com> Message-ID: > John, a question, how is swap set up on your system? I was > swapping to a file (a memory disk device /dev/md0). I was > doing this because for some reason lost in ancient history, > this machine was not set up with a real swap partition. > Hence, no crash dump. Swap is a partition on the 1st disk. > Last night I repartitioned a second disk, set up a real swap > partition and now I'm currently waiting for this to happen > again so I can get a crash dump. I will try creating a swap partition on my second drive to see if that improves things ... I am able to cause a panic "on demand" but a crash dump is rarely written (presumably because the system believes the device is not accessible?). I must have crashed it 10-20 times now with various corruptions of the panic screen - once it had blue text with "trap 12 trap 12" all over the screen, I liked that one ;-). I did manage to complete a "make index" while the background FSCK was running, once it had finished, performing the same task caused a panic locking the machine up again with no crash dump. John From kris at FreeBSD.org Wed Jul 16 15:00:44 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Wed Jul 16 15:00:50 2008 Subject: Fresh 7.0 Install: Fatal Trap 12 panic when put under load In-Reply-To: References: <854CADB9D95147CAB10BC35887A8E5DC@emea.hubersuhner.net> <20080716031640.7DC744500E@ptavv.es.net> <62b856460807160743v3fce951eg1b2bd9e50a35ba1d@mail.gmail.com> Message-ID: <487E0D1B.2060902@FreeBSD.org> John Sullivan wrote: > >> John, a question, how is swap set up on your system? I was >> swapping to a file (a memory disk device /dev/md0). I was >> doing this because for some reason lost in ancient history, >> this machine was not set up with a real swap partition. >> Hence, no crash dump. > > Swap is a partition on the 1st disk. > >> Last night I repartitioned a second disk, set up a real swap >> partition and now I'm currently waiting for this to happen >> again so I can get a crash dump. > > I will try creating a swap partition on my second drive to see if that improves things ... I am able to cause a panic "on demand" > but a crash dump is rarely written (presumably because the system believes the device is not accessible?). I must have crashed it > 10-20 times now with various corruptions of the panic screen - once it had blue text with "trap 12 trap 12" all over the screen, I > liked that one ;-). > > I did manage to complete a "make index" while the background FSCK was running, once it had finished, performing the same task caused > a panic locking the machine up again with no crash dump. OK, the first thing to do is disable bg fsck, then force a full fsck of all filesystems. bg fsck does a poor job of fixing arbitrary filesystem corruption (it's not designed to do so, in fact), and you can get into a situation where corrupted filesystems cause further panics. Removing KDB_UNATTENDED from your kernel will allow you to interact with the debugger and obtain backtraces etc, which is useful when dumps are not being saved. Kris From mgrant at grant.org Wed Jul 16 15:12:33 2008 From: mgrant at grant.org (Michael Grant) Date: Wed Jul 16 15:12:40 2008 Subject: Fresh 7.0 Install: Fatal Trap 12 panic when put under load In-Reply-To: References: <854CADB9D95147CAB10BC35887A8E5DC@emea.hubersuhner.net> <20080716031640.7DC744500E@ptavv.es.net> Message-ID: <62b856460807160743v3fce951eg1b2bd9e50a35ba1d@mail.gmail.com> On Wed, Jul 16, 2008 at 10:38 AM, John Sullivan wrote: > >> Could be memory, but I'd also suggest looking at >> temperatures. I've had overheating systems produce lots of >> such errors. > > Temperature is fine - it never get's that hot here in the UK ;-) Seriously, I put my hand in the box, touched a few heat sync's, it > is not running hot enough to cause a problem. The BIOS reports that all is well with the temperature inside the box of just over 30 > degrees C. > > John > This looks like the same panic I reported yesterday but I'm running 6.3 patch 2. I have seen these crashes on my box since 6.3 pre-release, randomly, but under load. My box is based on a SuperMicro motherboard running Intel Xeon processors. The only commonality is that we're both using Sata drives. John, a question, how is swap set up on your system? I was swapping to a file (a memory disk device /dev/md0). I was doing this because for some reason lost in ancient history, this machine was not set up with a real swap partition. Hence, no crash dump. Last night I repartitioned a second disk, set up a real swap partition and now I'm currently waiting for this to happen again so I can get a crash dump. Michael Grant From kris at FreeBSD.org Wed Jul 16 15:21:12 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Wed Jul 16 15:21:20 2008 Subject: Fresh 7.0 Install: Fatal Trap 12 panic when put under load In-Reply-To: <62b856460807160743v3fce951eg1b2bd9e50a35ba1d@mail.gmail.com> References: <854CADB9D95147CAB10BC35887A8E5DC@emea.hubersuhner.net> <20080716031640.7DC744500E@ptavv.es.net> <62b856460807160743v3fce951eg1b2bd9e50a35ba1d@mail.gmail.com> Message-ID: <487E11E7.8020704@FreeBSD.org> Michael Grant wrote: > On Wed, Jul 16, 2008 at 10:38 AM, John Sullivan wrote: >>> Could be memory, but I'd also suggest looking at >>> temperatures. I've had overheating systems produce lots of >>> such errors. >> Temperature is fine - it never get's that hot here in the UK ;-) Seriously, I put my hand in the box, touched a few heat sync's, it >> is not running hot enough to cause a problem. The BIOS reports that all is well with the temperature inside the box of just over 30 >> degrees C. >> >> John >> > > This looks like the same panic I reported yesterday but I'm running > 6.3 patch 2. Unless you have information you haven't yet shared, no it doesn't :) "Fatal trap 12" is an effect, not a cause. We still need your backtrace to make progress understanding the cause of your panic. Kris From gnn at freebsd.org Wed Jul 16 15:23:54 2008 From: gnn at freebsd.org (gnn@freebsd.org) Date: Wed Jul 16 15:24:01 2008 Subject: igb doesn't compile in STABLE? In-Reply-To: <2a41acea0807151035w291269abt4ed99989ae45cc8b@mail.gmail.com> References: <2a41acea0807141453s7235d894i31a744a0f673fcc0@mail.gmail.com> <2a41acea0807151007q29a783c4r2ae63c5a631952ba@mail.gmail.com> <2a41acea0807151035w291269abt4ed99989ae45cc8b@mail.gmail.com> Message-ID: At Tue, 15 Jul 2008 10:35:57 -0700, Jack Vogel wrote: > > OK, will put on my todo list :) > Thanks. A kernel built that way (i.e. with igb and em) does actually work, which is good, but if you're going to split them up we should get this right before 7.1. Best, George From hausen at punkt.de Wed Jul 16 15:32:51 2008 From: hausen at punkt.de (Patrick M. Hausen) Date: Wed Jul 16 15:32:58 2008 Subject: Unattended install w/ serial console? Message-ID: <20080716153248.GD81398@hugo10.ka.punkt.de> Hello, I've managed to get sysinstall to do a completely unattended install via DHCP/PXE and reboot the system into a state where it will be possible to login via SSH. So far, so good. Unfortunately This works for VGA consoles only. If the server in question has got a serial console, I get this prompt: ------------------------------------------------------------ /stand/sysinstall running as init on serial console These are the predefined terminal types available to sysinstall when running stand-alone. Please choose the closest match for your particular terminal. 1 ...................... Standard ANSI terminal. 2 ...................... VT100 or compatible terminal. 3 ...................... FreeBSD system console (color). 4 ...................... FreeBSD system console (monochrome). 5 ...................... xterm terminal emulator. Your choice: (1-5) ------------------------------------------------------------ After entering (e.g.) 2, the complete install runs just fine without any more operator assistance. The code responsible for this seems to be in /usr/src/usr.sbin/sysinstall/termcap.c, line 92 ff.: if (!OnVTY || (stat < 0)) { if (!term) { char *term, *termcap; prompt_term(&term, &termcap); with prompt_term() being the function that displays the above menue. Term is set at the beginning of set_termcap(), line 80: term = getenv("TERM"); OK, here's the question: how do I set environment variables in install.cfg or some other file in my mfsroot? TERM=vt100 in install.cfg did not make it to sysinstall, would have been too simple, I guess ;-) Thanks a lot, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: J?rgen Egeling AG Mannheim 108285 From swhetzel at gmail.com Wed Jul 16 15:56:48 2008 From: swhetzel at gmail.com (Scot Hetzel) Date: Wed Jul 16 15:56:54 2008 Subject: Konqueror and the Cookiejar In-Reply-To: <200807151557.52338.horechuk@csolve.net> References: <200807151557.52338.horechuk@csolve.net> Message-ID: <790a9fff0807160856q3417d124o72b604c01374a7bf@mail.gmail.com> On Tue, Jul 15, 2008 at 2:57 PM, Paul Horechuk wrote: > Since upgrading to 7.0 Stable, I've noticed an occasional problem with > konqueror. I've been recompiling my ports for the past few weeks and have > noticed that some sites are complaining about cookies not being enabled. > Further investigation has revealed that if I start konqueror from the > terminal prompt, I can get an error message: > khtml (dom) Can't communicate with the cookiejar! > > A workaround I've discovered is to run kded first. Konqueror works with > cookies after that. > I have also noticed this with KDE 3.5.8 and 3.5.9. The problem isn't that kded is not being run, the real problem is that something is causing kded to core dump. Search your system for *.core files. The only solution I found was to restart kded, and then cookies worked. Scot From eugen at kuzbass.ru Wed Jul 16 16:50:23 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Wed Jul 16 16:50:30 2008 Subject: named.conf: query-source address Message-ID: <20080716162042.GA27666@svzserv.kemerovo.su> Hi! I fully understand and second efforts on educating people how to configure BIND to be stong to attacks and keep them from using "query-source address" with "port" option but how about binding named to particular IP address when host has many of them? Using "query-source address" without "port" is the only solution (not speaking of jails here) and safe one? Wouldn't all that hustle about query-source misinform users about utility of it? Eugene Grosbein From oberman at es.net Wed Jul 16 17:01:56 2008 From: oberman at es.net (Kevin Oberman) Date: Wed Jul 16 17:02:03 2008 Subject: Fresh 7.0 Install: Fatal Trap 12 panic when put under load In-Reply-To: Your message of "Wed, 16 Jul 2008 09:38:26 BST." Message-ID: <20080716170153.2FF6A45047@ptavv.es.net> > From: "John Sullivan" > Date: Wed, 16 Jul 2008 09:38:26 +0100 > > > > Could be memory, but I'd also suggest looking at > > temperatures. I've had overheating systems produce lots of > > such errors. > > Temperature is fine - it never get's that hot here in the UK ;-) > Seriously, I put my hand in the box, touched a few heat sync's, it is > not running hot enough to cause a problem. The BIOS reports that all > is well with the temperature inside the box of just over 30 degrees C. It's not the heat sink temperature that I am concerned with. It is the temperature of the CPU and (if it's not AMD) the north bridge. I have encountered several cases of improper heat sink installation which resulted in poor transfer from the chip to the heat sink. Cleaning and properly applying heat transfer grease made a huge difference. You say that BIOS is reporting a 30C temperature. If this is the CPU temperature when the CPU is busy, I don't believe it. I have a system where the BIOS (via ACPI) reports the temperature as 35C, regardless of how long the system has been under power or what it is doing. I'm not at all sure that the problem is thermal, but I don't think you should dismiss the possibility too quickly. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080716/9cfd2611/attachment.pgp From m.seaman at infracaninophile.co.uk Wed Jul 16 17:34:52 2008 From: m.seaman at infracaninophile.co.uk (Matthew Seaman) Date: Wed Jul 16 17:35:00 2008 Subject: named.conf: query-source address In-Reply-To: <20080716162042.GA27666@svzserv.kemerovo.su> References: <20080716162042.GA27666@svzserv.kemerovo.su> Message-ID: <487E312E.9090307@infracaninophile.co.uk> Eugene Grosbein wrote: > I fully understand and second efforts on educating people > how to configure BIND to be stong to attacks and keep them from using > "query-source address" with "port" option but how about > binding named to particular IP address when host has many of them? > Using "query-source address" without "port" is the only solution > (not speaking of jails here) and safe one? Wouldn't all that hustle > about query-source misinform users about utility of it? To make named bind to a particular IP, you want the 'listen-on' options -- this is the IP that clients will access for service. By the nature of things, you'll have to use port 53 for this. The 'query-source' options don't have to be specified: the system will just choose some appropriate address according to the state of the routing table. 'query-source' to set the source /IP/ is really only useful in some specific server configurations with several alias addresses any of which could be used. That's pretty rare really. Most of the uses of query-source have been to set the source /port/ -- this was a standard part of the documentation: fix the source port in order to help the DNS traffic transit firewalls. However the recent security advisory has forced the complete abandonment of that idea. It's not even particularly truthful that you need to fix the source port because of firewalling: nowadays most firewalls are stateful, which eliminates that requirement. query-source is only ever used by recursive or stub resolvers -- instances of named that will go out and make queries on the net on your behalf. Authoritative servers really don't need it. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080716/1e2b8ddb/signature.pgp From john at basicnets.co.uk Wed Jul 16 19:39:01 2008 From: john at basicnets.co.uk (john@basicnets.co.uk) Date: Wed Jul 16 19:39:08 2008 Subject: Fresh 7.0 Install: Fatal Trap 12 panic when put under load In-Reply-To: <487E0D1B.2060902@FreeBSD.org> References: <854CADB9D95147CAB10BC35887A8E5DC@emea.hubersuhner.net> <20080716031640.7DC744500E@ptavv.es.net> <62b856460807160743v3fce951eg1b2bd9e50a35ba1d@mail.gmail.com> <487E0D1B.2060902@FreeBSD.org> Message-ID: <20080716203900.5jt4qce17gg0og0o@mail.basicnets.co.uk> > OK, the first thing to do is disable bg fsck, then force a full fsck of > all filesystems.? bg fsck does a poor job of fixing arbitrary > filesystem corruption (it's not designed to do so, in fact), and you > can get into a situation where corrupted filesystems cause further > panics. Done, nothing really found wrong size in superblock which it corrected. > Removing KDB_UNATTENDED from your kernel will allow you to interact > with the debugger and obtain backtraces etc, which is useful when dumps > are not being saved. Easier said than done, this cause a few panics - no dumps though ...grrrr!! Still the same result ... the system seems to panic twice then hang.? I will keep trying unless you have some other ideas?? Thanks for your support John ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From bh at izb.knu.ac.kr Wed Jul 16 21:03:23 2008 From: bh at izb.knu.ac.kr (Byung-Hee HWANG) Date: Wed Jul 16 21:03:36 2008 Subject: cvsup server reachable via IPv6... In-Reply-To: <1215119650.75067.10.camel@neo.cse.buffalo.edu> References: <1215119650.75067.10.camel@neo.cse.buffalo.edu> Message-ID: <1216242176.34454.7.camel@jihad.izb.knu.ac.kr> On Thu, 2008-07-03 at 17:14 -0400, Ken Smith wrote: > If any of you have been wishing there was an IPv6-capable cvsup server > you could use (with csup as the client obviously since cvsup doesn't do > IPv6...) give cvsup18.freebsd.org a try. With the help of a few other > folks I got nudged into giving inetd/netcat a try as a means to feed > IPv6 connections to the cvsupd server process. > > If you try it and have problems let me know. cvsup18 is my "little > server" (handles between 200 and 300 connects a day) but if this seems > to work OK I can give it a try on my "big server" (handles between 3000 > and 4000 connects a day...). > also i checked the speed of cvsup18.freebsd.org by csup(1) a few minutes ago ;; now i want to say that's good! bh -- "But aside from that let me swear by the souls of my grandchildren that I will never break the peace we have made." -- Vito Corleone, "Chapter 20", page 292 From koitsu at FreeBSD.org Wed Jul 16 21:16:43 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Jul 16 21:16:50 2008 Subject: named.conf: query-source address In-Reply-To: <20080716162042.GA27666@svzserv.kemerovo.su> References: <20080716162042.GA27666@svzserv.kemerovo.su> Message-ID: <20080716205705.GA25198@eos.sc1.parodius.com> On Thu, Jul 17, 2008 at 12:20:42AM +0800, Eugene Grosbein wrote: > I fully understand and second efforts on educating people > how to configure BIND to be stong to attacks and keep them from using > "query-source address" with "port" option but how about > binding named to particular IP address when host has many of them? We do such on our authoritative nameservers. The options we use: listen-on { 127.0.0.1; 72.20.106.4; }; query-source address 72.20.106.4; transfer-source 72.20.106.4; notify-source 72.20.106.4; interface-interval 0; use-alt-transfer-source no; -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From hostmaster at netconsonance.com Wed Jul 16 21:40:12 2008 From: hostmaster at netconsonance.com (Jo Rhett) Date: Wed Jul 16 21:40:28 2008 Subject: how to get more logging from GEOM? In-Reply-To: References: Message-ID: On Jul 11, 2008, at 4:48 AM, Ronald Klop wrote: > You can try going into the kernel debugger to see where it is > hanging. Debugging via a serial cable is also very easy. > I don't know the details, but there is a lot of info in the Freebsd > handbook. Put this in google 'freebsd handbook kernel debug'. Thanks for the reply. I'm familiar with these options, but as the system is currently running GENERIC and trying to compile a kernel would guarantee to cause the problem to occur... I could probably keep hacking at it until I finally get everything compiled, but... Ugh. I guess this option doesn't appeal very much. Are there any other options available? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From hostmaster at netconsonance.com Wed Jul 16 21:41:36 2008 From: hostmaster at netconsonance.com (Jo Rhett) Date: Wed Jul 16 21:41:43 2008 Subject: how to get more logging from GEOM? In-Reply-To: <20080711155831.GA72963@slackbox.xs4all.nl> References: <20080711155831.GA72963@slackbox.xs4all.nl> Message-ID: <6AA8BC91-AF84-4CC7-B6BE-4CA84D82EC1E@netconsonance.com> On Jul 11, 2008, at 8:58 AM, Roland Smith wrote: >> After about 2 weeks of watching it carefully I've learned almost >> nothing. It's not a disk failure (AFAIK) it's not cpu overheat (now >> running healthd without complaints) it's not based on any given >> network traffic... however it does appear to accompany heavy cpu/ >> disk >> activity. It usually dies when indexing my websites at night (but >> not >> always) and it sometimes dies when compiling programs. Just heavy >> disk isn't enough to do the job, as backups proceed without >> problems. Heavy cpu by itself isn't enough to do it either. But if >> I start compiling things and keep going a while, it will eventually >> hang. > >> Is there anything else I should be looking at? > > Power supply or motherboard would be my first guess. If the system went offline, I agree. But it's clearly a kernel deadlock, since the system remains pingable, answers TCP connections, etc etcc.... but doesn't respond. No TCP negotiation, no response on the console, etc. It's higher level activity which isn't working... -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From hostmaster at netconsonance.com Wed Jul 16 21:42:33 2008 From: hostmaster at netconsonance.com (Jo Rhett) Date: Wed Jul 16 21:42:40 2008 Subject: how to get more logging from GEOM? In-Reply-To: <20080711164939.GA10238@lava.net> References: <20080711164939.GA10238@lava.net> Message-ID: > On Fri, Jul 11, 2008 at 12:59:33AM -0700, Jo Rhett wrote: >> Every time it is rebuilding ad0. Every single boot in the last two >> weeks. On Jul 11, 2008, at 9:49 AM, Clifton Royston wrote: > That just means that it halted without a proper shutdown. If it > crashes, the mirror isn't stopped properly, so it's marked dirty, so > it > must rebuild it. It is the precise analogy of finding all the file > systems dirty on boot and fscking them, following a crash. Thanks for the clarification. Dang, I hoped I was on to something. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From spork at bway.net Wed Jul 16 21:48:49 2008 From: spork at bway.net (Charles Sprickman) Date: Wed Jul 16 21:48:58 2008 Subject: named.conf: query-source address In-Reply-To: <20080716205705.GA25198@eos.sc1.parodius.com> References: <20080716162042.GA27666@svzserv.kemerovo.su> <20080716205705.GA25198@eos.sc1.parodius.com> Message-ID: On Wed, 16 Jul 2008, Jeremy Chadwick wrote: > On Thu, Jul 17, 2008 at 12:20:42AM +0800, Eugene Grosbein wrote: >> I fully understand and second efforts on educating people >> how to configure BIND to be stong to attacks and keep them from using >> "query-source address" with "port" option but how about >> binding named to particular IP address when host has many of them? > > We do such on our authoritative nameservers. The options we use: Same here... > listen-on { 127.0.0.1; 72.20.106.4; }; > query-source address 72.20.106.4; > transfer-source 72.20.106.4; > notify-source 72.20.106.4; But just that portion. It works, and it passes the test with a std. dev of 19K or so on the port "randomness". Charles > interface-interval 0; > use-alt-transfer-source no; > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From koitsu at FreeBSD.org Wed Jul 16 21:49:58 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Jul 16 21:50:05 2008 Subject: named.conf: query-source address In-Reply-To: <487E66D0.1050000@FreeBSD.org> References: <20080716162042.GA27666@svzserv.kemerovo.su> <20080716205705.GA25198@eos.sc1.parodius.com> <487E66D0.1050000@FreeBSD.org> Message-ID: <20080716214957.GA26869@eos.sc1.parodius.com> On Wed, Jul 16, 2008 at 02:23:28PM -0700, Doug Barton wrote: > Jeremy Chadwick wrote: >> On Thu, Jul 17, 2008 at 12:20:42AM +0800, Eugene Grosbein wrote: >>> I fully understand and second efforts on educating people >>> how to configure BIND to be stong to attacks and keep them from using >>> "query-source address" with "port" option but how about >>> binding named to particular IP address when host has many of them? >> >> We do such on our authoritative nameservers. The options we use: >> >> listen-on { 127.0.0.1; 72.20.106.4; }; >> query-source address 72.20.106.4; >> transfer-source 72.20.106.4; >> notify-source 72.20.106.4; >> interface-interval 0; >> use-alt-transfer-source no; > > Have you found those -source options to be necessary in practice? In > general named should be smart enough not to try reaching the outside > world on the loopback address. It's not loopback I'm worried about. The config parms we use are necessary. Removing them will break DNS for us breaks horribly (AXFRs failing due to ACLs on master servers, recursive queries being made from the wrong src, NOTIFYs being sent from the wrong src). BIND will usually pick the first non-aliased IP to perform things from, unless queries or other things come across a different network route, in which case it'll respond with whatever IP it deems appropriate (based on the routing table, I presume). Showing our ifconfig will probably speak for itself: bge0: flags=8843 mtu 1500 options=1b inet 72.20.106.2 netmask 0xffffff80 broadcast 72.20.106.127 inet 72.20.106.3 netmask 0xffffffff broadcast 72.20.106.3 inet 72.20.106.4 netmask 0xffffffff broadcast 72.20.106.4 inet 72.20.106.5 netmask 0xffffffff broadcast 72.20.106.5 inet 72.20.106.7 netmask 0xffffffff broadcast 72.20.106.7 inet 72.20.106.8 netmask 0xffffffff broadcast 72.20.106.8 inet 72.20.106.40 netmask 0xffffffff broadcast 72.20.106.40 inet 72.20.106.41 netmask 0xffffffff broadcast 72.20.106.41 ether 00:30:48:81:fc:8a media: Ethernet autoselect (100baseTX ) status: active The "interface-interval 0" option can be safely removed, but I do not see the point in having BIND continually look for new IPs on an interface when we want it only using a specific IP (that will never get removed or changed on the fly). "use-alt-transfer-source no" is an absolute must. BIND tries to be cute/smart about cycling through all IPs to attempt an AXFR, which is behaviour that (IMHO) should be question in the first place. The comment I have in our named.conf explaining why we use it: # Do not attempt to use an alternative IP address for zone # transfers. This keeps named from trying to use the main # IP address of the box if an xfer via transfer-source fails. > Also, I'm guessing that you have more than one public IP address > configured on that box? Otherwise none of those options should be > necessary. Correct -- and that's what Eugene was asking about. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From dougb at FreeBSD.org Wed Jul 16 21:50:10 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Wed Jul 16 21:50:21 2008 Subject: named.conf: query-source address In-Reply-To: <20080716205705.GA25198@eos.sc1.parodius.com> References: <20080716162042.GA27666@svzserv.kemerovo.su> <20080716205705.GA25198@eos.sc1.parodius.com> Message-ID: <487E66D0.1050000@FreeBSD.org> Jeremy Chadwick wrote: > On Thu, Jul 17, 2008 at 12:20:42AM +0800, Eugene Grosbein wrote: >> I fully understand and second efforts on educating people >> how to configure BIND to be stong to attacks and keep them from using >> "query-source address" with "port" option but how about >> binding named to particular IP address when host has many of them? > > We do such on our authoritative nameservers. The options we use: > > listen-on { 127.0.0.1; 72.20.106.4; }; > query-source address 72.20.106.4; > transfer-source 72.20.106.4; > notify-source 72.20.106.4; > interface-interval 0; > use-alt-transfer-source no; Have you found those -source options to be necessary in practice? In general named should be smart enough not to try reaching the outside world on the loopback address. Also, I'm guessing that you have more than one public IP address configured on that box? Otherwise none of those options should be necessary. Doug -- This .signature sanitized for your protection From rsmith at xs4all.nl Wed Jul 16 22:14:23 2008 From: rsmith at xs4all.nl (Roland Smith) Date: Wed Jul 16 22:14:35 2008 Subject: how to get more logging from GEOM? In-Reply-To: <6AA8BC91-AF84-4CC7-B6BE-4CA84D82EC1E@netconsonance.com> References: <20080711155831.GA72963@slackbox.xs4all.nl> <6AA8BC91-AF84-4CC7-B6BE-4CA84D82EC1E@netconsonance.com> Message-ID: <20080716221416.GA39265@slackbox.xs4all.nl> On Wed, Jul 16, 2008 at 02:41:28PM -0700, Jo Rhett wrote: > On Jul 11, 2008, at 8:58 AM, Roland Smith wrote: > >> After about 2 weeks of watching it carefully I've learned almost > >> nothing. It's not a disk failure (AFAIK) it's not cpu overheat (now > >> running healthd without complaints) it's not based on any given > >> network traffic... however it does appear to accompany heavy cpu/ > >> disk > >> activity. It usually dies when indexing my websites at night (but > >> not > >> always) and it sometimes dies when compiling programs. Just heavy > >> disk isn't enough to do the job, as backups proceed without > >> problems. Heavy cpu by itself isn't enough to do it either. But if > >> I start compiling things and keep going a while, it will eventually > >> hang. > > > >> Is there anything else I should be looking at? > > > > Power supply or motherboard would be my first guess. > > > If the system went offline, I agree. But it's clearly a kernel > deadlock, since the system remains pingable, answers TCP connections, > etc etcc.... but doesn't respond. Ah. Well, you did said the system 'dies', not 'becomes unresponsive'. > No TCP negotiation, no response on > the console, etc. It's higher level activity which isn't working... Try compiling a kernel with debugging options e.g. WITNESS(4), MUTEX_DEBUG, LOCK_PROFILING, DIAGNOSTIC and INVARIANTS. See /usr/src/sys/conf/NOTES This will create a lot of messages in the dmesg output. If you can hook the system up to another machine via serial console, you might be able to debug the kernel. Read the kernel debugging chapter in the Developers' Handbook. Another tip is to create a cron job that makes log entries every couple of minutes with logger. This might help you pinpoint the exact time of the mishap, to correlate it to other system activity. Be _really_ sure that it isn't hardware though. Otherwise you'll be led on a merry goose chase looking for software errors that aren't there. If you can restore a backup of this machine's software to a similar one, do so and see if the hangs persist. If they don't, it's hardware. 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) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080716/7c905dd3/attachment.pgp From utisoft at googlemail.com Wed Jul 16 22:20:15 2008 From: utisoft at googlemail.com (Chris Rees) Date: Wed Jul 16 22:20:23 2008 Subject: Failure building apache22 and mysql51 In-Reply-To: <487B70A3.8020203@psrk.com> References: <487B70A3.8020203@psrk.com> Message-ID: 2008/7/14 Sorin P?nca : > I'm sorry for my late response, I was on vacation. > I think this was the case (although I thought we have only amd64 machines). > Is there a way to recover from this situation by ssh access only? > > Thank you! > Sorin. > > Chris Rees wrote: >>> >>> Date: Mon, 23 Jun 2008 18:43:04 +0300 >>> From: Sorin P?nca >> >> >>> Hello people! >>> I recently upgraded a amd64 machine from FreeBSD-6.2-RELEASE-p11 to >>> FreeBSD-7.0-RELEASE-p2 using the tutorial found at >>> >>> http://www.daemonology.net/blog/2007-11-11-freebsd-major-version-upgrade.html >>> All went well with the base system. >> >> I don't want to patronise, but are you sure you were running >> FreeBSD/amd64-6.2 before? Looks kinda like you've tried to upgrade >> from 6.2/i386 to 7.0/amd64. In case you have, you can't do that. >> >> Check you haven't disabled and processor-specific extensions in your >> BIOS, like SSE, that would also create problems if you have optimised >> your ports. >> >> Chris >> >> >> >> >> >>> I thought devel/linuxthreads was using some old library so I tried to >>> rebuild it: >>> >>> # cd ../../devel/linuxthreads && make install clean # portupgrade -f >>> wouldn't do anything >>> ===> linuxthreads-2.2.3_23 is only for i386, while you are running >>> amd64. >>> *** Error code 1 >>> >>> Stop in /usr/ports/devel/linuxthreads. >>> >>> >>> Any ideas what to do next? >>> Thank you! >>> >>> Sorin. >>> > > If I understand you correctly, you want to revert to FreeBSD/i386; in which case I'd advise that you are *extremely* careful, and make sure that everything important is recompiled in i386; FreeBSD/amd64 can run binaries from FreeBSD/i386, but not vice-versa. I *think* that you should be ok running a source update (csup sources, make buildworld installworld kernel) with arch as i386, then reboot, pkg_delete -f portupgrade\*, pkg_add -r portupgrade, portupgrade -faP etc Don't take my word for it, it is beyond my expertise, I've deliberately made it obtuse; get someone with more knowledge to elucidate :P Or, you could stick with /amd64. -- R< $&h ! > $- ! $+ $@ $2 < @ $1 .UUCP. > (sendmail.cf) From rsmith at xs4all.nl Wed Jul 16 22:41:17 2008 From: rsmith at xs4all.nl (Roland Smith) Date: Wed Jul 16 22:41:24 2008 Subject: Failure building apache22 and mysql51 In-Reply-To: References: <487B70A3.8020203@psrk.com> Message-ID: <20080716224113.GC39265@slackbox.xs4all.nl> On Wed, Jul 16, 2008 at 11:20:13PM +0100, Chris Rees wrote: > 2008/7/14 Sorin P?nca : > > I'm sorry for my late response, I was on vacation. > > I think this was the case (although I thought we have only amd64 machines). > > Is there a way to recover from this situation by ssh access only? > > > > Thank you! > > Sorin. > > > > Chris Rees wrote: > >>> > >>> Date: Mon, 23 Jun 2008 18:43:04 +0300 > >>> From: Sorin P?nca > >> > >> > >>> Hello people! > >>> I recently upgraded a amd64 machine from FreeBSD-6.2-RELEASE-p11 to > >>> FreeBSD-7.0-RELEASE-p2 using the tutorial found at > >>> > >>> http://www.daemonology.net/blog/2007-11-11-freebsd-major-version-upgrade.html > >>> All went well with the base system. > >> > >> I don't want to patronise, but are you sure you were running > >> FreeBSD/amd64-6.2 before? Looks kinda like you've tried to upgrade > >> from 6.2/i386 to 7.0/amd64. In case you have, you can't do that. > >> > >> Check you haven't disabled and processor-specific extensions in your > >> BIOS, like SSE, that would also create problems if you have optimised > >> your ports. > >> > >> Chris > >>> I thought devel/linuxthreads was using some old library so I tried to > >>> rebuild it: > >>> > >>> # cd ../../devel/linuxthreads && make install clean # portupgrade -f > >>> wouldn't do anything > >>> ===> linuxthreads-2.2.3_23 is only for i386, while you are running > >>> amd64. > >>> *** Error code 1 > >>> > >>> Stop in /usr/ports/devel/linuxthreads. > >>> > >>> > >>> Any ideas what to do next? > >>> Thank you! > >>> > >>> Sorin. > > If I understand you correctly, you want to revert to FreeBSD/i386; in > which case I'd advise that you are *extremely* careful, and make sure > that everything important is recompiled in i386; FreeBSD/amd64 can run > binaries from FreeBSD/i386, but not vice-versa. > > I *think* that you should be ok running a source update (csup sources, > make buildworld installworld kernel) with arch as i386, then reboot, > pkg_delete -f portupgrade\*, pkg_add -r portupgrade, portupgrade -faP > etc Installworld is supposed to be done after a reboot, in this case (cross-build) you'll have a 32-bit kernel stuck with a 64-bit userland. That won't work. If you do the installworld before the reboot with a cross-buils, it will be the other way around. I'm not sure if the installworld will even complete; every system binary that is replaced will be of the wrong architecture. > Don't take my word for it, it is beyond my expertise, I've > deliberately made it obtuse; get someone with more knowledge to > elucidate :P If you have a spare partition, you could install the new kernel and userland there, and then switch partitions. If that's not an option, make backups of your data and re-install with the i386 version. It's quicker and probably less painfull. :) For changing architectures you'll also have to remove all ports/packages and re-compile/install them for the new architecture. But you should do that anyway when going from 6.x to 7. 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) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080716/d8392da3/attachment.pgp From minter at lunenburg.org Wed Jul 16 22:48:32 2008 From: minter at lunenburg.org (H. Wade Minter) Date: Wed Jul 16 22:49:44 2008 Subject: Switching from 32 to 64 bit with freebsd-update? Message-ID: <806C9CF5-A9DD-4C7D-94A9-07724B731D74@lunenburg.org> I have a 64-bit system that had the 32-bit version of 6.3 installed on it. Is it possible to use freebsd-update (or another somewhat painless method) to switch the system to 64-bit? We're running into the 4GB memory limit. --Wade From kkutzko at teksavvy.com Wed Jul 16 22:56:02 2008 From: kkutzko at teksavvy.com (Kevin K) Date: Wed Jul 16 22:56:10 2008 Subject: HP Pavilion dv2000 laptop wont boot off install cd In-Reply-To: <200807161353.m6GDrDFB058142@lurza.secnetix.de> References: <200807161353.m6GDrDFB058142@lurza.secnetix.de> Message-ID: <009301c8e797$1385e880$3a91b980$@com> > Please try one of the more recent 7-stable snapshots > from June or July. They're located on the FTP sites > in /pub/FreeBSD/snapshots. > > Best regards > Oliver > Adding : set hint.apic.0.disabled=1 set hint.sio.0.disabled=1 set hint.sio.1.disabled=1 Did not help, I still got a hard reboot on the latest 7.0-release amd64 snapshot. Any further suggestions are welcome. Thank you, Kevin K. From kkutzko at teksavvy.com Wed Jul 16 23:00:38 2008 From: kkutzko at teksavvy.com (Kevin K) Date: Wed Jul 16 23:00:45 2008 Subject: Switching from 32 to 64 bit with freebsd-update? In-Reply-To: <806C9CF5-A9DD-4C7D-94A9-07724B731D74@lunenburg.org> References: <806C9CF5-A9DD-4C7D-94A9-07724B731D74@lunenburg.org> Message-ID: <009701c8e797$b8d05c80$2a711580$@com> > I have a 64-bit system that had the 32-bit version of 6.3 installed on > it. Is it possible to use freebsd-update (or another somewhat > painless method) to switch the system to 64-bit? > > We're running into the 4GB memory limit. > > --Wade I believe this is possible but you will come into a lot of trouble with statically linked libraries -- a much more reliable and secure would be to build a clean amd64 on a separate system and re-compile the needed software and move the files from i386 over after it has been tested. From Mark_Andrews at isc.org Wed Jul 16 23:10:20 2008 From: Mark_Andrews at isc.org (Mark Andrews) Date: Wed Jul 16 23:10:26 2008 Subject: named.conf: query-source address In-Reply-To: Your message of "Wed, 16 Jul 2008 13:57:05 MST." <20080716205705.GA25198@eos.sc1.parodius.com> Message-ID: <200807162310.m6GNAGCS042459@drugs.dv.isc.org> > We do such on our authoritative nameservers. The options we use: > > listen-on { 127.0.0.1; 72.20.106.4; }; > query-source address 72.20.106.4; > transfer-source 72.20.106.4; > notify-source 72.20.106.4; > interface-interval 0; > use-alt-transfer-source no; That's perfectly fine. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From andrewd at webzone.net.au Wed Jul 16 23:31:03 2008 From: andrewd at webzone.net.au (Andrew D) Date: Wed Jul 16 23:31:10 2008 Subject: Switching from 32 to 64 bit with freebsd-update? In-Reply-To: <009701c8e797$b8d05c80$2a711580$@com> References: <806C9CF5-A9DD-4C7D-94A9-07724B731D74@lunenburg.org> <009701c8e797$b8d05c80$2a711580$@com> Message-ID: <487E821E.9080408@webzone.net.au> Kevin K wrote: >> I have a 64-bit system that had the 32-bit version of 6.3 installed on >> it. Is it possible to use freebsd-update (or another somewhat >> painless method) to switch the system to 64-bit? >> >> We're running into the 4GB memory limit. >> >> --Wade > FreeBSD-update is used for updates to binary files for the current installed version of FreeBSD. Using sysinstall and do a binary upgrade should do the trick or doing the below. Just make sure you make a backup of everything b4 you start. > > I believe this is possible but you will come into a lot of trouble with > statically linked libraries -- a much more reliable and secure would be to > build a clean amd64 on a separate system and re-compile the needed software > and move the files from i386 over after it has been tested. > You should be able to do the above on the system in question provided you follow the handbook to the letter. After the installing of the new world and kernel, make sure you do a full recompile of all ports to be sure. HTH Cheers cya Andrew > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From minimarmot at gmail.com Thu Jul 17 01:53:18 2008 From: minimarmot at gmail.com (Ben Kaduk) Date: Thu Jul 17 01:53:25 2008 Subject: how to get more logging from GEOM? In-Reply-To: References: Message-ID: <47d0403c0807161825m45bff8d7w41eca673315e77d4@mail.gmail.com> On Wed, Jul 16, 2008 at 5:40 PM, Jo Rhett wrote: > On Jul 11, 2008, at 4:48 AM, Ronald Klop wrote: >> >> You can try going into the kernel debugger to see where it is hanging. >> Debugging via a serial cable is also very easy. >> I don't know the details, but there is a lot of info in the Freebsd >> handbook. Put this in google 'freebsd handbook kernel debug'. > > > Thanks for the reply. I'm familiar with these options, but as the system is > currently running GENERIC and trying to compile a kernel would guarantee to > cause the problem to occur... I could probably keep hacking at it until I > finally get everything compiled, but... > > Ugh. I guess this option doesn't appeal very much. Are there any other > options available? > You don't need to compile the kernel on the same machine that you use it on -- you can copy the compiled kernel into /boot/kernel.new -Ben Kaduk From eugen at kuzbass.ru Thu Jul 17 03:52:00 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Thu Jul 17 03:52:07 2008 Subject: named.conf: query-source address In-Reply-To: <487E312E.9090307@infracaninophile.co.uk> References: <20080716162042.GA27666@svzserv.kemerovo.su> <487E312E.9090307@infracaninophile.co.uk> Message-ID: <20080717035155.GA81536@svzserv.kemerovo.su> On Wed, Jul 16, 2008 at 06:34:38PM +0100, Matthew Seaman wrote: > The 'query-source' options don't have to be specified: the system > will just choose some appropriate address according to the state of > the routing table. 'query-source' to set the source /IP/ is really > only useful in some specific server configurations with several alias > addresses any of which could be used. That's pretty rare really. Isn't this common to have multiple aliases at an interface? Sometimes only one of them should be used for all DNS traffic. > query-source is only ever used by recursive or stub resolvers -- > instances of named that will go out and make queries on the net on your > behalf. Authoritative servers really don't need it. Sometimes one needs to bind named to distinct IP address for all data it sends to the net on its own, not as answers to queries only. There is nothing wrong in using 'query-source' without 'port' option, I mean. Eugene Grosbein From cswiger at mac.com Thu Jul 17 04:24:59 2008 From: cswiger at mac.com (Chuck Swiger) Date: Thu Jul 17 04:25:06 2008 Subject: named.conf: query-source address In-Reply-To: <20080717035155.GA81536@svzserv.kemerovo.su> References: <20080716162042.GA27666@svzserv.kemerovo.su> <487E312E.9090307@infracaninophile.co.uk> <20080717035155.GA81536@svzserv.kemerovo.su> Message-ID: <8DFF6DCD-6619-4251-9944-59CED8DF1B19@mac.com> On Jul 16, 2008, at 8:51 PM, Eugene Grosbein wrote: > On Wed, Jul 16, 2008 at 06:34:38PM +0100, Matthew Seaman wrote: >> The 'query-source' options don't have to be specified: the system >> will just choose some appropriate address according to the state of >> the routing table. 'query-source' to set the source /IP/ is really >> only useful in some specific server configurations with several alias >> addresses any of which could be used. That's pretty rare really. > > Isn't this common to have multiple aliases at an interface? > Sometimes only one of them should be used for all DNS traffic. About the only common reason to set up multiple aliases on an interface is when you're doing something like hosting multiple SSL webservers on a single box which actually need to have distinct IPs as a consequence. Other than that, using public IPs for aliases is usually wasteful of IP address space. YMMV... Regards, -- -Chuck From koitsu at FreeBSD.org Thu Jul 17 04:41:06 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Jul 17 04:41:13 2008 Subject: named.conf: query-source address In-Reply-To: <8DFF6DCD-6619-4251-9944-59CED8DF1B19@mac.com> References: <20080716162042.GA27666@svzserv.kemerovo.su> <487E312E.9090307@infracaninophile.co.uk> <20080717035155.GA81536@svzserv.kemerovo.su> <8DFF6DCD-6619-4251-9944-59CED8DF1B19@mac.com> Message-ID: <20080717044106.GA53681@eos.sc1.parodius.com> On Wed, Jul 16, 2008 at 09:06:33PM -0700, Chuck Swiger wrote: > On Jul 16, 2008, at 8:51 PM, Eugene Grosbein wrote: >> On Wed, Jul 16, 2008 at 06:34:38PM +0100, Matthew Seaman wrote: >>> The 'query-source' options don't have to be specified: the system >>> will just choose some appropriate address according to the state of >>> the routing table. 'query-source' to set the source /IP/ is really >>> only useful in some specific server configurations with several alias >>> addresses any of which could be used. That's pretty rare really. >> >> Isn't this common to have multiple aliases at an interface? >> Sometimes only one of them should be used for all DNS traffic. > > About the only common reason to set up multiple aliases on an interface > is when you're doing something like hosting multiple SSL webservers on a > single box which actually need to have distinct IPs as a consequence. > Other than that, using public IPs for aliases is usually wasteful of IP > address space. YMMV... This is off-topic, but the reason we use public IPs for web hosting (read: standard HTTP) is so we can rate-limit the network I/O using pf and ALTQ. We tried for many years to use bandwidth-limiting modules such as mod_bw and mod_cband, but the modules are incredibly buggy. (Our most recent experience was with mod_cband, which will literally deadlock the entire webserver during heavy multipart downloads. The Debian folks found the same problem, and it was ultimately removed from their package repo.) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From dougb at FreeBSD.org Thu Jul 17 05:11:06 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Thu Jul 17 05:11:12 2008 Subject: named.conf: query-source address In-Reply-To: <20080716214957.GA26869@eos.sc1.parodius.com> References: <20080716162042.GA27666@svzserv.kemerovo.su> <20080716205705.GA25198@eos.sc1.parodius.com> <487E66D0.1050000@FreeBSD.org> <20080716214957.GA26869@eos.sc1.parodius.com> Message-ID: <487ED467.3000000@FreeBSD.org> Jeremy Chadwick wrote: > The config parms we use are necessary. That's all you had to say. :) I see a lot of people attempt to over-engineer stuff with named that leads to complications later. If you are doing things for a good reason, keep doing them. Doug -- This .signature sanitized for your protection From pschmehl_lists at tx.rr.com Thu Jul 17 05:20:43 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Thu Jul 17 05:20:50 2008 Subject: named.conf: query-source address In-Reply-To: <8DFF6DCD-6619-4251-9944-59CED8DF1B19@mac.com> References: <20080716162042.GA27666@svzserv.kemerovo.su> <487E312E.9090307@infracaninophile.co.uk> <20080717035155.GA81536@svzserv.kemerovo.su> <8DFF6DCD-6619-4251-9944-59CED8DF1B19@mac.com> Message-ID: --On July 16, 2008 9:06:33 PM -0700 Chuck Swiger wrote: > On Jul 16, 2008, at 8:51 PM, Eugene Grosbein wrote: >> On Wed, Jul 16, 2008 at 06:34:38PM +0100, Matthew Seaman wrote: >>> The 'query-source' options don't have to be specified: the system >>> will just choose some appropriate address according to the state of >>> the routing table. 'query-source' to set the source /IP/ is really >>> only useful in some specific server configurations with several alias >>> addresses any of which could be used. That's pretty rare really. >> >> Isn't this common to have multiple aliases at an interface? >> Sometimes only one of them should be used for all DNS traffic. > > About the only common reason to set up multiple aliases on an interface > is when you're doing something like hosting multiple SSL webservers on a > single box which actually need to have distinct IPs as a consequence. > Other than that, using public IPs for aliases is usually wasteful of IP > address space. YMMV... > I would have thought that the most common reason for setting up multiple aliases on an interface was for hosting multiple domains on a single server. At least that's why I do it. Paul Schmehl If it isn't already obvious, my opinions are my own and not those of my employer. From spork at bway.net Thu Jul 17 05:22:53 2008 From: spork at bway.net (Charles Sprickman) Date: Thu Jul 17 05:23:01 2008 Subject: named.conf: query-source address In-Reply-To: <8DFF6DCD-6619-4251-9944-59CED8DF1B19@mac.com> References: <20080716162042.GA27666@svzserv.kemerovo.su> <487E312E.9090307@infracaninophile.co.uk> <20080717035155.GA81536@svzserv.kemerovo.su> <8DFF6DCD-6619-4251-9944-59CED8DF1B19@mac.com> Message-ID: On Wed, 16 Jul 2008, Chuck Swiger wrote: > On Jul 16, 2008, at 8:51 PM, Eugene Grosbein wrote: >> On Wed, Jul 16, 2008 at 06:34:38PM +0100, Matthew Seaman wrote: >>> The 'query-source' options don't have to be specified: the system >>> will just choose some appropriate address according to the state of >>> the routing table. 'query-source' to set the source /IP/ is really >>> only useful in some specific server configurations with several alias >>> addresses any of which could be used. That's pretty rare really. >> >> Isn't this common to have multiple aliases at an interface? >> Sometimes only one of them should be used for all DNS traffic. > > About the only common reason to set up multiple aliases on an interface is > when you're doing something like hosting multiple SSL webservers on a single > box which actually need to have distinct IPs as a consequence. Other than > that, using public IPs for aliases is usually wasteful of IP address space. I think another common reason is portability of services. When I setup a box, it gets an IP that sticks with that piece of hardware. Each distinct service that I pile onto it then gets it's own IP. This has at least two major advantages that I've found: -If the box dies, it's easy to move any of the services to another box without waiting for DNS changes to propogate. -If one of the services outgrows the box, it's a simple matter to move that service elsewhere, again without playing with DNS. I also will sometimes move services away for a major upgrade of the box. All of this becomes simple when you just bring an alias down on one box and up on another. Next step, putting each service in a jail and moving the jail when needed. > YMMV... On the internets, it always does. :) Charles > Regards, > -- > -Chuck > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From david at vizion2000.net Thu Jul 17 09:07:11 2008 From: david at vizion2000.net (David Southwell) Date: Thu Jul 17 09:07:18 2008 Subject: Dragon_Saver Error 19 Freebsd 7.0 AMD64 Message-ID: <200807170208.58598.david@vizion2000.net> Just upgraded from Freebsd 6.3 to 7.0 uname -a FreeBSD dns1.vizion2000.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul 16 09:27:38 PDT 2008 root@dns1.vizion2000.net:/usr/obj/usr/src/sys/GENERIC amd64 Have the following entry in /var/log/essages: Jul 17 01:28:46 dns1 kernel: dragon_saver: the console does not support M_VGA_CG320 Jul 17 01:28:46 dns1 kernel: module_register_init: MOD_LOAD (dragon_saver, 0xffffffffadf7a140, 0) error 19 Can anyone please point me in the right direction Thanks David From koitsu at FreeBSD.org Thu Jul 17 09:17:12 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Jul 17 09:17:20 2008 Subject: Dragon_Saver Error 19 Freebsd 7.0 AMD64 In-Reply-To: <200807170208.58598.david@vizion2000.net> References: <200807170208.58598.david@vizion2000.net> Message-ID: <20080717091712.GA65200@eos.sc1.parodius.com> On Thu, Jul 17, 2008 at 02:08:58AM -0700, David Southwell wrote: > Just upgraded from Freebsd 6.3 to 7.0 > > uname -a > FreeBSD dns1.vizion2000.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul 16 > 09:27:38 PDT 2008 root@dns1.vizion2000.net:/usr/obj/usr/src/sys/GENERIC > amd64 > Have the following entry in > > /var/log/essages: > > Jul 17 01:28:46 dns1 kernel: dragon_saver: the console does not support > M_VGA_CG320 > Jul 17 01:28:46 dns1 kernel: module_register_init: MOD_LOAD (dragon_saver, > 0xffffffffadf7a140, 0) error 19 That looks to be some kind of screen-saver for VGA consoles, similar to daemon_saver or green_saver. Look at the splash(4) manpage. There is no 'dragon_saver' that comes with FreeBSD 7.0, however. And I don't remember reading about it on FreeBSD 6.x either. Usually things like that are loaded via rc.conf or loader.conf. > Can anyone please point me in the right direction http://www.hrwiki.org/index.php/Trogdor -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Thu Jul 17 09:24:40 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Jul 17 09:24:50 2008 Subject: Dragon_Saver Error 19 Freebsd 7.0 AMD64 In-Reply-To: <20080717091712.GA65200@eos.sc1.parodius.com> References: <200807170208.58598.david@vizion2000.net> <20080717091712.GA65200@eos.sc1.parodius.com> Message-ID: <20080717092434.GA65528@eos.sc1.parodius.com> On Thu, Jul 17, 2008 at 02:17:12AM -0700, Jeremy Chadwick wrote: > On Thu, Jul 17, 2008 at 02:08:58AM -0700, David Southwell wrote: > > Just upgraded from Freebsd 6.3 to 7.0 > > > > uname -a > > FreeBSD dns1.vizion2000.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul 16 > > 09:27:38 PDT 2008 root@dns1.vizion2000.net:/usr/obj/usr/src/sys/GENERIC > > amd64 > > Have the following entry in > > > > /var/log/essages: > > > > Jul 17 01:28:46 dns1 kernel: dragon_saver: the console does not support > > M_VGA_CG320 > > Jul 17 01:28:46 dns1 kernel: module_register_init: MOD_LOAD (dragon_saver, > > 0xffffffffadf7a140, 0) error 19 > > That looks to be some kind of screen-saver for VGA consoles, similar to > daemon_saver or green_saver. Look at the splash(4) manpage. > > There is no 'dragon_saver' that comes with FreeBSD 7.0, however. And I > don't remember reading about it on FreeBSD 6.x either. > > Usually things like that are loaded via rc.conf or loader.conf. I stand corrected -- it appears to come with FreeBSD since the 4.x days: http://lists.freebsd.org/pipermail/cvs-all/2003-July/017624.html I've still never heard of it though, and it's not mentioned in the applicable manpages either. But there's an amusing part, too: You posted this exact question on freebsd-questions 1.5 years ago, where you were running FreeBSD 6.1. So this problem has little to do with your 6.3 --> 7.0 upgrade. http://lists.freebsd.org/pipermail/freebsd-questions/2007-January/139096.html -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From norwoh at comcast.net Thu Jul 17 11:11:15 2008 From: norwoh at comcast.net (norwoh@comcast.net) Date: Thu Jul 17 11:11:52 2008 Subject: how to get more logging from GEOM? Message-ID: <071720081111.19253.487F28D00006459500004B3522155934140801999D0102@comcast.net> -------------- Original message ---------------------- From: "Ben Kaduk" > On Wed, Jul 16, 2008 at 5:40 PM, Jo Rhett wrote: > > On Jul 11, 2008, at 4:48 AM, Ronald Klop wrote: > >> > >> You can try going into the kernel debugger to see where it is hanging. > >> Debugging via a serial cable is also very easy. > >> I don't know the details, but there is a lot of info in the Freebsd > >> handbook. Put this in google 'freebsd handbook kernel debug'. > > > > > > Thanks for the reply. I'm familiar with these options, but as the system is > > currently running GENERIC and trying to compile a kernel would guarantee to > > cause the problem to occur... I could probably keep hacking at it until I > > finally get everything compiled, but... > > > > Ugh. I guess this option doesn't appeal very much. Are there any other > > options available? > > > > You don't need to compile the kernel on the same machine that you use it > on -- you can copy the compiled kernel into /boot/kernel.new > But how do you handle the issue of differences in contents on the board where you don't have exact identical hardwares? SJK www.sulima.com <> > -Ben Kaduk > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From sorin.panca at psrk.com Thu Jul 17 11:30:20 2008 From: sorin.panca at psrk.com (=?UTF-8?B?U29yaW4gUMOibmNh?=) Date: Thu Jul 17 11:30:31 2008 Subject: Failure building apache22 and mysql51 In-Reply-To: <20080716224113.GC39265@slackbox.xs4all.nl> References: <487B70A3.8020203@psrk.com> <20080716224113.GC39265@slackbox.xs4all.nl> Message-ID: <487F2CE7.5060604@psrk.com> Roland Smith wrote: > On Wed, Jul 16, 2008 at 11:20:13PM +0100, Chris Rees wrote: >> 2008/7/14 Sorin P?nca : >>> I'm sorry for my late response, I was on vacation. >>> I think this was the case (although I thought we have only amd64 machines). >>> Is there a way to recover from this situation by ssh access only? >>> >>> Thank you! >>> Sorin. >>> >>> Chris Rees wrote: >>>>> Date: Mon, 23 Jun 2008 18:43:04 +0300 >>>>> From: Sorin P?nca >>>> >>>>> Hello people! >>>>> I recently upgraded a amd64 machine from FreeBSD-6.2-RELEASE-p11 to >>>>> FreeBSD-7.0-RELEASE-p2 using the tutorial found at >>>>> >>>>> http://www.daemonology.net/blog/2007-11-11-freebsd-major-version-upgrade.html >>>>> All went well with the base system. >>>> I don't want to patronise, but are you sure you were running >>>> FreeBSD/amd64-6.2 before? Looks kinda like you've tried to upgrade >>>> from 6.2/i386 to 7.0/amd64. In case you have, you can't do that. >>>> >>>> Check you haven't disabled and processor-specific extensions in your >>>> BIOS, like SSE, that would also create problems if you have optimised >>>> your ports. >>>> >>>> Chris > >>>>> I thought devel/linuxthreads was using some old library so I tried to >>>>> rebuild it: >>>>> >>>>> # cd ../../devel/linuxthreads && make install clean # portupgrade -f >>>>> wouldn't do anything >>>>> ===> linuxthreads-2.2.3_23 is only for i386, while you are running >>>>> amd64. >>>>> *** Error code 1 >>>>> >>>>> Stop in /usr/ports/devel/linuxthreads. >>>>> >>>>> >>>>> Any ideas what to do next? >>>>> Thank you! >>>>> >>>>> Sorin. >> If I understand you correctly, you want to revert to FreeBSD/i386; in >> which case I'd advise that you are *extremely* careful, and make sure >> that everything important is recompiled in i386; FreeBSD/amd64 can run >> binaries from FreeBSD/i386, but not vice-versa. >> >> I *think* that you should be ok running a source update (csup sources, >> make buildworld installworld kernel) with arch as i386, then reboot, >> pkg_delete -f portupgrade\*, pkg_add -r portupgrade, portupgrade -faP >> etc > > Installworld is supposed to be done after a reboot, in this case > (cross-build) you'll have a 32-bit kernel stuck with a 64-bit > userland. That won't work. > > If you do the installworld before the reboot with a cross-buils, it will > be the other way around. I'm not sure if the installworld will even > complete; every system binary that is replaced will be of the wrong > architecture. > >> Don't take my word for it, it is beyond my expertise, I've >> deliberately made it obtuse; get someone with more knowledge to >> elucidate :P > > If you have a spare partition, you could install the new kernel and > userland there, and then switch partitions. If that's not an option, > make backups of your data and re-install with the i386 version. It's > quicker and probably less painfull. :) > > For changing architectures you'll also have to remove all ports/packages > and re-compile/install them for the new architecture. But you should do > that anyway when going from 6.x to 7. > > > Roland Actually I want to run on amd64 architecture on that system (let's call it system0). And recently I had a similar system running FreeBSD-6.2 (amd64 - I'm sure about this one; let's call it system1) and tried to upgrade it to FreeBSD-7.0. To my surprise I had the same errors with missing PIC flag for libpthread. While for system0 I was able to fix the issue by installing devel/pth and symlinking the binary in proper locations, I experimented a little with system1 until I rendered it unusable. My question now is: what happend to the second system? Why did the upgrade fail on this one? Unfortunatly I had to reinstall it ASAP using a FreeBSD CD, because system1 is a production system and I really can't investigate further. I still have other four systems waiting to be upgraded from 6.1 or 6.2 to 7.0 or 7.1 and even they are production, they are replaceable. So I might have the chance to experiment on them, if you think this issue should be chased down. Sorin. From kkutzko at teksavvy.com Thu Jul 17 12:16:53 2008 From: kkutzko at teksavvy.com (Kevin K) Date: Thu Jul 17 12:17:14 2008 Subject: HP Pavilion dv2000 laptop wont boot off install cd In-Reply-To: <009301c8e797$1385e880$3a91b980$@com> References: <200807161353.m6GDrDFB058142@lurza.secnetix.de> <009301c8e797$1385e880$3a91b980$@com> Message-ID: <00b301c8e806$eeb3d5b0$cc1b8110$@com> I just tried to boot off the latest 8.0-CURRENT amd64 snapshot. According to documentation, if you hold the spacebar as it is loading /boot/default/loader.conf you can get to the boot menu. Pressing 6 and entering : set hint.apic.0.disabled=1 set hint.sio.0.disabled=1 set hint.sio.1.disabled=1 Gets the laptop to boot. It crashing during the boot process however : Lock order reversal: (sleepable after non-sleepable) 1st 0xffffff000226e878 bufobj interlock (bufobj interlock) @ /usr/src/sys/kern/vfs_bio.c:2442 2nd 0xffffffff9a7a3040 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2456 KDB: stack backtrace: Db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Witness_checkorder() at witness_checkorder+0x609 __lockmgr_args() at __lockmgr_args+0x502 getblk() at getblk+0xe3 breadn() at breadn+0x3f bread() at bread+0x1e ffs_blkatoff() at ffs_blkatoff+0x61 ufs_lookup() at ufs_lookup+0x5f3 vfs_cache_lookup() at vfs_cache_lookup+0xf8 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x95 Lookup() at lookup+0x4b2 namei() at namei+0x43f kern_unlinkat() at kern_unlinkat+0x9d vfs_mountroot_try() at vfs_mountroot_try+0x402 vfs_mountroot() at vfs_mountroot+0x40b start_init() at start_init+0x62 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffff8142fd30, rbp = 0 --- Sorry if theres typos in the above as I had to type out manually. ~k From kkutzko at teksavvy.com Thu Jul 17 12:31:58 2008 From: kkutzko at teksavvy.com (Kevin K) Date: Thu Jul 17 12:32:04 2008 Subject: HP Pavilion dv2000 laptop wont boot off install cd In-Reply-To: <00b301c8e806$eeb3d5b0$cc1b8110$@com> References: <200807161353.m6GDrDFB058142@lurza.secnetix.de> <009301c8e797$1385e880$3a91b980$@com> <00b301c8e806$eeb3d5b0$cc1b8110$@com> Message-ID: <00b401c8e809$0ed63c50$2c82b4f0$@com> > I just tried to boot off the latest 8.0-CURRENT amd64 snapshot. > According to > documentation, if you hold the spacebar as it is loading > /boot/default/loader.conf you can get to the boot menu. Pressing 6 and > entering : > > > set hint.apic.0.disabled=1 > set hint.sio.0.disabled=1 > set hint.sio.1.disabled=1 Just tried the above with 6.3-RELEASE amd64 snapshot (200806) , as well as 7.0-RELEASE amd64 snapshot (200806), with pressing the spacebar, pressing 6 at boot screen and typing the above options. For 6.3-RELEASE, it actually got to sysinstall. For 7.0-RELEASE, it seemed to hang at "Trying to mount root from ufs:/dev/md0". When I have time (tonight perhaps), I will try to do a full install of 6.3-RELEASE and see how that functions. Unfortunately there are no amd64 snapshots for 200807, so if I cant install 6.3 I may wait until more updated snapshots come out. ~k From jlm at caamora.com.au Thu Jul 17 12:37:27 2008 From: jlm at caamora.com.au (jonathan michaels) Date: Thu Jul 17 12:37:34 2008 Subject: named.conf: query-source address In-Reply-To: <487ED467.3000000@FreeBSD.org>; from Doug Barton on Wed, Jul 16, 2008 at 10:11:03PM -0700 References: <20080716162042.GA27666@svzserv.kemerovo.su> <20080716205705.GA25198@eos.sc1.parodius.com> <487E66D0.1050000@FreeBSD.org> <20080716214957.GA26869@eos.sc1.parodius.com> <487ED467.3000000@FreeBSD.org> Message-ID: <20080717221942.41191@caamora.com.au> On Wed, Jul 16, 2008 at 10:11:03PM -0700, Doug Barton wrote: > Jeremy Chadwick wrote: > > > The config parms we use are necessary. > > That's all you had to say. :) I see a lot of people attempt to > over-engineer stuff with named that leads to complications later. If > you are doing things for a good reason, keep doing them. > Doug, et al, i for one appreciate this "over-engieered" responce because it has given me (and those like me) a chance to get answers to questions that we have asked for over a year in my case, about this whole bind setup issue. as an asideo, it would be better for people coming in cold could find a better source of who to setup support services such as bind and all teh others for a woring freebsd based network .. i don't mean teh existant 'engineering speak that assumes we all know everything .. this is clearly not teh case to a whole lot of people coming to freebsd. kind regards jonathan -- ================================================================ powered by .. QNX, OS9 and freeBSD -- http://caamora com au/operating system ==== === appropriate solution in an inappropriate world === ==== From david at vizion2000.net Thu Jul 17 13:31:48 2008 From: david at vizion2000.net (David Southwell) Date: Thu Jul 17 13:31:55 2008 Subject: Dragon_Saver Error 19 Freebsd 7.0 AMD64 In-Reply-To: <20080717092434.GA65528@eos.sc1.parodius.com> References: <200807170208.58598.david@vizion2000.net> <20080717091712.GA65200@eos.sc1.parodius.com> <20080717092434.GA65528@eos.sc1.parodius.com> Message-ID: <200807170653.16864.david@vizion2000.net> On Thursday 17 July 2008 02:24:34 Jeremy Chadwick wrote: > On Thu, Jul 17, 2008 at 02:17:12AM -0700, Jeremy Chadwick wrote: > > On Thu, Jul 17, 2008 at 02:08:58AM -0700, David Southwell wrote: > > > Just upgraded from Freebsd 6.3 to 7.0 > > > > > > uname -a > > > FreeBSD dns1.vizion2000.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul > > > 16 09:27:38 PDT 2008 > > > root@dns1.vizion2000.net:/usr/obj/usr/src/sys/GENERIC amd64 > > > Have the following entry in > > > > > > /var/log/essages: > > > > > > Jul 17 01:28:46 dns1 kernel: dragon_saver: the console does not support > > > M_VGA_CG320 > > > Jul 17 01:28:46 dns1 kernel: module_register_init: MOD_LOAD > > > (dragon_saver, 0xffffffffadf7a140, 0) error 19 > > > > That looks to be some kind of screen-saver for VGA consoles, similar to > > daemon_saver or green_saver. Look at the splash(4) manpage. > > > > There is no 'dragon_saver' that comes with FreeBSD 7.0, however. And I > > don't remember reading about it on FreeBSD 6.x either. > > > > Usually things like that are loaded via rc.conf or loader.conf. > > I stand corrected -- it appears to come with FreeBSD since the 4.x > days: http://lists.freebsd.org/pipermail/cvs-all/2003-July/017624.html > > I've still never heard of it though, and it's not mentioned in the > applicable manpages either. > > But there's an amusing part, too: > > You posted this exact question on freebsd-questions 1.5 years ago, > where you were running FreeBSD 6.1. So this problem has little to do > with your 6.3 --> 7.0 upgrade. > > http://lists.freebsd.org/pipermail/freebsd-questions/2007-January/139096.ht >ml RTFM Well I cant remember -- It must have gone away on 6.3 -holding stomach as I roar with laughter!!!! Well done... Ah well as you will see from my next posting I have something alittle bit odder to report!! David From david at vizion2000.net Thu Jul 17 13:33:59 2008 From: david at vizion2000.net (David Southwell) Date: Thu Jul 17 13:34:06 2008 Subject: Portsclean doesnt like my upgrade from 6.3 > 7.0 Message-ID: <200807170655.30131.david@vizion2000.net> It looks as though I have missed something!! FreeBSD dns1.vizion2000.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul 16 09:27:38 PDT 2008 root@dns1.vizion2000.net:/usr/obj/usr/src/sys/GENERIC amd64 [root@dns1 ~]# portsclean FFaattaall eerrrroorr ''Thread is not system scope. Thread is not system scope. '' aatt lliinnee 331199 iinn ffiillee /usr/src/lib/libpthread/thread/thr_sig.c/usr/src/lib/libpthread/thread/thr_sig.c ((eerrrrnnoo == 22)) Segmentation fault: 11 (core dumped) Ok where do I go from here?? David From kris at FreeBSD.org Thu Jul 17 13:39:28 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Thu Jul 17 13:39:35 2008 Subject: Portsclean doesnt like my upgrade from 6.3 > 7.0 In-Reply-To: <200807170655.30131.david@vizion2000.net> References: <200807170655.30131.david@vizion2000.net> Message-ID: <487F4B8E.9040909@FreeBSD.org> David Southwell wrote: > It looks as though I have missed something!! > FreeBSD dns1.vizion2000.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul 16 > 09:27:38 PDT 2008 root@dns1.vizion2000.net:/usr/obj/usr/src/sys/GENERIC > amd64 > > [root@dns1 ~]# portsclean > FFaattaall eerrrroorr ''Thread is not system scope. > Thread is not system scope. > '' aatt lliinnee 331199 iinn > ffiillee /usr/src/lib/libpthread/thread/thr_sig.c/usr/src/lib/libpthread/thread/thr_sig.c > ((eerrrrnnoo == 22)) > > Segmentation fault: 11 (core dumped) > > Ok where do I go from here?? Find out which port(s) you didnt recompile as part of the upgrade (e.g. check mtime in /usr/local), and do that now. You may need to also recompile the ports that depend on them to undo the damage. Kris From minimarmot at gmail.com Thu Jul 17 13:58:32 2008 From: minimarmot at gmail.com (Ben Kaduk) Date: Thu Jul 17 13:59:33 2008 Subject: how to get more logging from GEOM? In-Reply-To: <071720081111.19253.487F28D00006459500004B3522155934140801999D0102@comcast.net> References: <071720081111.19253.487F28D00006459500004B3522155934140801999D0102@comcast.net> Message-ID: <47d0403c0807170658u35278859g761caac1ae8caebb@mail.gmail.com> On Thu, Jul 17, 2008 at 7:11 AM, wrote: > > -------------- Original message ---------------------- > From: "Ben Kaduk" >> >> You don't need to compile the kernel on the same machine that you use it >> on -- you can copy the compiled kernel into /boot/kernel.new >> > But how do you handle the issue of differences in contents on the board where you don't have exact identical hardwares? > The kernel configuration file specifies which device drivers will be included in the compiled kernel; if those devices aren't present in the system, the relevant code is present but doesn't get used. For example, the GENERIC kernel has the majority of device drivers included, so that most devices will be recognized out-of-the-box. A more difficult problem to solve is when you want to compile a kernel for a different architecture; say, to compile a kernel for x86 on an amd64 build machine. This can still be done, but it requires a fair amount more work. -Ben Kaduk From eugen at kuzbass.ru Thu Jul 17 14:00:22 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Thu Jul 17 14:00:29 2008 Subject: named.conf: query-source address In-Reply-To: <8DFF6DCD-6619-4251-9944-59CED8DF1B19@mac.com> References: <20080716162042.GA27666@svzserv.kemerovo.su> <487E312E.9090307@infracaninophile.co.uk> <20080717035155.GA81536@svzserv.kemerovo.su> <8DFF6DCD-6619-4251-9944-59CED8DF1B19@mac.com> Message-ID: <20080717140018.GA91530@svzserv.kemerovo.su> On Wed, Jul 16, 2008 at 09:06:33PM -0700, Chuck Swiger wrote: > >Isn't this common to have multiple aliases at an interface? > >Sometimes only one of them should be used for all DNS traffic. > > About the only common reason to set up multiple aliases on an > interface is when you're doing something like hosting multiple SSL > webservers on a single box which actually need to have distinct IPs as > a consequence. Other than that, using public IPs for aliases is > usually wasteful of IP address space. YMMV... Think about multiple IP-based services (not HTTP "virtual" servers) at one physical host that should use distinct IP addresses for some reasons (local policy/billing/monitoring/etc.) Eugene Grosbein From david at vizion2000.net Thu Jul 17 14:08:37 2008 From: david at vizion2000.net (David Southwell) Date: Thu Jul 17 14:08:44 2008 Subject: Portsclean doesnt like my upgrade from 6.3 > 7.0 In-Reply-To: <487F4B8E.9040909@FreeBSD.org> References: <200807170655.30131.david@vizion2000.net> <487F4B8E.9040909@FreeBSD.org> Message-ID: <200807170730.08649.david@vizion2000.net> On Thursday 17 July 2008 06:39:26 Kris Kennaway wrote: > David Southwell wrote: > > It looks as though I have missed something!! > > FreeBSD dns1.vizion2000.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul 16 > > 09:27:38 PDT 2008 > > root@dns1.vizion2000.net:/usr/obj/usr/src/sys/GENERIC amd64 > > > > [root@dns1 ~]# portsclean > > FFaattaall eerrrroorr ''Thread is not system scope. > > Thread is not system scope. > > '' aatt lliinnee 331199 iinn > > ffiillee > > /usr/src/lib/libpthread/thread/thr_sig.c/usr/src/lib/libpthread/thread/th > >r_sig.c ((eerrrrnnoo == 22)) > > > > Segmentation fault: 11 (core dumped) > > > > Ok where do I go from here?? > > Find out which port(s) you didnt recompile as part of the upgrade (e.g. > check mtime in /usr/local), and do that now. You may need to also > recompile the ports that depend on them to undo the damage. > > Kris > _______________________________________________ Thanks Kris I have been unable to find instructions in the manual about recompiling ports as part of a system upgrade process. There seems to be no reference to it. The upgrade from 6.1 to 6.3 seemed to work OK once I sorted out a problem with perl. However 6.3 to 7.0 seems to produce more difficulties than I bargained for!!! How can I best reconfigure and recompile all th installed ports? As you can see from below: [root@dns1 ~]# portupgrade -a Fatal error 'Thread is not system scope. ' at line 319 in file /usr/src/lib/libpthread/thread/thr_sig.c (errno = 2) Segmentation fault: 11 (core dumped) I have definitely omitted a vital step From sven at dmv.com Thu Jul 17 14:16:59 2008 From: sven at dmv.com (Sven Willenberger) Date: Thu Jul 17 14:17:06 2008 Subject: Multi-machine mirroring choices In-Reply-To: References: Message-ID: <1216304215.14562.19.camel@lanshark.dmv.com> On Tue, 2008-07-15 at 16:20 +0100, Pete French wrote: > > However, I must ask you this: why are you doing things the way you are? > > Why are you using the equivalent of RAID 1 but for entire computers? Is > > there some reason you aren't using a filer (e.g. NetApp) for your data, > > thus keeping it centralised? > > I am not the roiginal poster, but I am doing something very similar and > can answer that question for you. Some people get paranoid about the > whole "single point of failure" thing. I originally suggestted that we buy > a filer and have identical servers so if one breaks we connect the other > to the filer, but the response I got was "what if the filer breaks?". So > in the end I had to show we have duplicate independent machines, with the > data kept symetrical on them at all times. > > It does actually work quite nicely actually - I have an "'active" database > machine, and a "passive". The opassive is only used if the active fails, > and the drives are run as a gmirror pair with the remote one being mounted > using ggated. It also means I can flip from active to passive when I want > to do an OS upgrade on the active machine. Switching takes a few seconds, > and this is fine for our setup. > > So the answer is that the descisiuon was taken out of my hands - but this > is not uncommon, and as a roll-your-own cluster it works very nicely. > > -pete. > _______________________________________________ I have for now gone with using ggate[cd] along with zpool and so far it's not bad. I can fail the master, stop ggated on the slave at which point geom reads the glabeled disks. From there I can zpool import to an alternate root. When the master comes back up I can zpool export and then, on the master, zpool import at which point zfs handles the resilvering. The *big* issue I have right now is dealing with the slave machine going down. Once the master no longer has a connection to the ggated devices, all processes trying to use the device hang in D status. I have tried pkill'ing ggatec to no avail and ggatec destroy returns a message of gctl being busy. Trying to ggatec destroy -f panics the machine. Does anyone know how to successfully time out a failed ggatec connection so that I can zpool detach or somehow have zfs removed the unavailable drive? Sven -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080717/d2c27f62/attachment.pgp From jhb at freebsd.org Thu Jul 17 14:25:46 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu Jul 17 14:26:11 2008 Subject: RELENG_7: /boot/loader command prompt mode broken? In-Reply-To: <1b1b33f10807080654s785f0f8aj487730337026a9e6@mail.gmail.com> References: <1b1b33f10807080654s785f0f8aj487730337026a9e6@mail.gmail.com> Message-ID: <200807171022.27825.jhb@freebsd.org> On Tuesday 08 July 2008 09:54:29 am Kelly Black wrote: > >Message: 4 > >Date: Mon, 07 Jul 2008 14:10:45 -0700 > >From: "Kevin Oberman" > >Subject: Re: RELENG_7: /boot/loader command prompt mode broken? > >To: Eugene Grosbein > >Cc: stable@freebsd.org > >Message-ID: <20080707211045.90F274500E@ptavv.es.net> > >Content-Type: text/plain; charset="us-ascii" > > > >> Date: Mon, 7 Jul 2008 18:21:47 +0800 > >> From: Eugene Grosbein > >> Sender: owner-freebsd-stable@freebsd.org > >> > >> Hi! > >> > >> Today I've updated my 7.0-STABLE system using source upgrade path. > >> loader(8) boots it just fine but it's impossible to issue commands > >> using its command prompt mode (N.B.: beastie_disable="YES" > >> and autoboot_delay="2" are in my /boot/loader.conf). > >> > >> At boot time, I hit "Space" button to reach its command prompt - that works. > >> While typing of a command, I observe one of bad things: > >> > >> 1) it just hangs solid (keyboard LEDs do not switch) after a couple > >> of characters entered, or > >> 2) system spontaneously reboots while typing, or > >> 3) it shows endless flow of hex dump, presumably from BTX. > >> > >> Most of time it hangs, a couple of times I've got reboot > >> and once there was hex dump. I use vidconsole with PS/2 keyboard. > >> > >> Seldom I've allowed to type 'boot -s' and hit enter without a problem - > >> it boots system OK then. So, I assume there is a problem > >> with vidconsole input/output routines. > >> > [Snip ... ] > >> > > I am having a similar problem. I removed the config.boot file with no > change. Someone in this list posted the following links: Are you using a serial console? -- John Baldwin From andrewd at webzone.net.au Thu Jul 17 14:43:15 2008 From: andrewd at webzone.net.au (Andrew D) Date: Thu Jul 17 14:43:23 2008 Subject: Portsclean doesnt like my upgrade from 6.3 > 7.0 In-Reply-To: <200807170730.08649.david@vizion2000.net> References: <200807170655.30131.david@vizion2000.net> <487F4B8E.9040909@FreeBSD.org> <200807170730.08649.david@vizion2000.net> Message-ID: <487F57EB.3050007@webzone.net.au> David Southwell wrote: > On Thursday 17 July 2008 06:39:26 Kris Kennaway wrote: >> David Southwell wrote: >>> It looks as though I have missed something!! >>> FreeBSD dns1.vizion2000.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul 16 >>> 09:27:38 PDT 2008 >>> root@dns1.vizion2000.net:/usr/obj/usr/src/sys/GENERIC amd64 >>> >>> [root@dns1 ~]# portsclean >>> FFaattaall eerrrroorr ''Thread is not system scope. >>> Thread is not system scope. >>> '' aatt lliinnee 331199 iinn >>> ffiillee >>> /usr/src/lib/libpthread/thread/thr_sig.c/usr/src/lib/libpthread/thread/th >>> r_sig.c ((eerrrrnnoo == 22)) >>> >>> Segmentation fault: 11 (core dumped) >>> >>> Ok where do I go from here?? >> Find out which port(s) you didnt recompile as part of the upgrade (e.g. >> check mtime in /usr/local), and do that now. You may need to also >> recompile the ports that depend on them to undo the damage. >> >> Kris >> _______________________________________________ > Thanks Kris > I have been unable to find instructions in the manual about recompiling ports > as part of a system upgrade process. There seems to be no reference to it. > The upgrade from 6.1 to 6.3 seemed to work OK once I sorted out a problem > with perl. However 6.3 to 7.0 seems to produce more difficulties than I > bargained for!!! > > How can I best reconfigure and recompile all th installed ports? > > As you can see from below: > [root@dns1 ~]# portupgrade -a > Fatal error 'Thread is not system scope. > ' at line 319 in file /usr/src/lib/libpthread/thread/thr_sig.c (errno = 2) > Segmentation fault: 11 (core dumped) > I saw this not too long ago, The culprit was ruby. Go into each of these ports and 'make clean && make && make deinstall reinstall' them lang/ruby18 (I assume) databases/ruby-bdb ports-mgmt/portupgrade you might have blow away /var/db/pkg/pkgdb.db a couple of times for it to work. Then portupgrade should work fine :) HTH cya Andrew > I have definitely omitted a vital step > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From kris at FreeBSD.org Thu Jul 17 14:46:08 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Thu Jul 17 14:46:15 2008 Subject: Portsclean doesnt like my upgrade from 6.3 > 7.0 In-Reply-To: <200807170730.08649.david@vizion2000.net> References: <200807170655.30131.david@vizion2000.net> <487F4B8E.9040909@FreeBSD.org> <200807170730.08649.david@vizion2000.net> Message-ID: <487F5B2F.1030003@FreeBSD.org> David Southwell wrote: > On Thursday 17 July 2008 06:39:26 Kris Kennaway wrote: >> David Southwell wrote: >>> It looks as though I have missed something!! >>> FreeBSD dns1.vizion2000.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul 16 >>> 09:27:38 PDT 2008 >>> root@dns1.vizion2000.net:/usr/obj/usr/src/sys/GENERIC amd64 >>> >>> [root@dns1 ~]# portsclean >>> FFaattaall eerrrroorr ''Thread is not system scope. >>> Thread is not system scope. >>> '' aatt lliinnee 331199 iinn >>> ffiillee >>> /usr/src/lib/libpthread/thread/thr_sig.c/usr/src/lib/libpthread/thread/th >>> r_sig.c ((eerrrrnnoo == 22)) >>> >>> Segmentation fault: 11 (core dumped) >>> >>> Ok where do I go from here?? >> Find out which port(s) you didnt recompile as part of the upgrade (e.g. >> check mtime in /usr/local), and do that now. You may need to also >> recompile the ports that depend on them to undo the damage. >> >> Kris >> _______________________________________________ > Thanks Kris > I have been unable to find instructions in the manual about recompiling ports > as part of a system upgrade process. There seems to be no reference to it. > The upgrade from 6.1 to 6.3 seemed to work OK once I sorted out a problem > with perl. However 6.3 to 7.0 seems to produce more difficulties than I > bargained for!!! It was clearly mentioned in the release announcement :) > How can I best reconfigure and recompile all th installed ports? > > As you can see from below: > [root@dns1 ~]# portupgrade -a > Fatal error 'Thread is not system scope. > ' at line 319 in file /usr/src/lib/libpthread/thread/thr_sig.c (errno = 2) > Segmentation fault: 11 (core dumped) Try pkg_deleting portupgrade and ruby* and reinstalling them, then proceed with portupgrade -fa (note -f!) or -faP. Kris From mbhavsar at niksun.com Thu Jul 17 15:11:26 2008 From: mbhavsar at niksun.com (Mihir Bhavsar) Date: Thu Jul 17 15:11:34 2008 Subject: iLO virtual Drive setup help In-Reply-To: <1216242176.34454.7.camel@jihad.izb.knu.ac.kr> Message-ID: <200807171439.m6HEd26M012586@anuket.mj.niksun.com> Hi, I was trying to mount virtual CDROM using Intel RMM module. RMM module is capable of redirecting four iso images or drives, and looking in to /dev my filesystem FreeBSD has labeled those as /cd0, /cd1, /cd2, /cd3. Once I boot the system connecting virtual drive, it boots from that drive and after that it's asking about to select drive to boot from (here cd0, cd1, cd2, acd0), after that it is not going further. My "camcontrol devlist" output reflects following. at scbus0 target 0 lun 0 (cd0,pass0) at scbus1 target 0 lun 0 (cd1,pass1) at scbus2 target 0 lun 0 (cd2,pass2) at scbus3 target 0 lun 0 (cd3,pass3) When I try to mount cdrom with "mount_cd9660 /dev/cd0 /cdrom" it gives me following error G_vfs_done():cd0[READ(offset=32768, length-2048)]error = 5 Mount_cd9660: /dev/cd0: Input/output error My part of /etc/fstab file reads like following ********** ******** ****** **** /dev/cd0 /cdrom4 cd9660 ro,noauto 0 0 /dev/cd1 /cdrom1 cd9660 ro,noauto 0 0 /dev/cd2 /cdrom2 cd9660 ro,noauto 0 0 /dev/cd3 /cdrom3 cd9660 ro,noauto 0 0 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 ****** ***** ****** I am a newbie to FreeBSD, so any help really appreciated. Sincerely yours, M. Bhavsar From david at vizion2000.net Thu Jul 17 15:25:00 2008 From: david at vizion2000.net (David Southwell) Date: Thu Jul 17 15:25:07 2008 Subject: Portsclean doesnt like my upgrade from 6.3 > 7.0 In-Reply-To: <487F57EB.3050007@webzone.net.au> References: <200807170655.30131.david@vizion2000.net> <200807170730.08649.david@vizion2000.net> <487F57EB.3050007@webzone.net.au> Message-ID: <200807170846.30483.david@vizion2000.net> On Thursday 17 July 2008 07:32:11 Andrew D wrote: > David Southwell wrote: > > On Thursday 17 July 2008 06:39:26 Kris Kennaway wrote: > >> David Southwell wrote: > >>> It looks as though I have missed something!! > >>> FreeBSD dns1.vizion2000.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul > >>> 16 09:27:38 PDT 2008 > >>> root@dns1.vizion2000.net:/usr/obj/usr/src/sys/GENERIC amd64 > >>> > >>> [root@dns1 ~]# portsclean > >>> FFaattaall eerrrroorr ''Thread is not system scope. > >>> Thread is not system scope. > >>> '' aatt lliinnee 331199 iinn > >>> ffiillee > >>> /usr/src/lib/libpthread/thread/thr_sig.c/usr/src/lib/libpthread/thread/ > >>>th r_sig.c ((eerrrrnnoo == 22)) > >>> > >>> Segmentation fault: 11 (core dumped) > >>> > >>> Ok where do I go from here?? > >> > >> Find out which port(s) you didnt recompile as part of the upgrade (e.g. > >> check mtime in /usr/local), and do that now. You may need to also > >> recompile the ports that depend on them to undo the damage. > >> > >> Kris > >> _______________________________________________ > > > > Thanks Kris > > I have been unable to find instructions in the manual about recompiling > > ports as part of a system upgrade process. There seems to be no reference > > to it. The upgrade from 6.1 to 6.3 seemed to work OK once I sorted out a > > problem with perl. However 6.3 to 7.0 seems to produce more difficulties > > than I bargained for!!! > > > > How can I best reconfigure and recompile all th installed ports? > > > > As you can see from below: > > [root@dns1 ~]# portupgrade -a > > Fatal error 'Thread is not system scope. > > ' at line 319 in file /usr/src/lib/libpthread/thread/thr_sig.c (errno = > > 2) Segmentation fault: 11 (core dumped) > > I saw this not too long ago, The culprit was ruby. > > Go into each of these ports and > 'make clean && make && make deinstall reinstall' them > > lang/ruby18 (I assume) > databases/ruby-bdb > ports-mgmt/portupgrade > > you might have blow away /var/db/pkg/pkgdb.db a couple of times for it > to work. > > Then portupgrade should work fine :) > Right on the nail !! I now have portupgrade -af fulfilling its magic Thank you and everyone else. David From torfinn.ingolfsen at broadpark.no Thu Jul 17 16:06:05 2008 From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen) Date: Thu Jul 17 16:06:12 2008 Subject: HP Pavilion dv2000 laptop wont boot off install cd In-Reply-To: <00b401c8e809$0ed63c50$2c82b4f0$@com> References: <200807161353.m6GDrDFB058142@lurza.secnetix.de> <009301c8e797$1385e880$3a91b980$@com> <00b301c8e806$eeb3d5b0$cc1b8110$@com> <00b401c8e809$0ed63c50$2c82b4f0$@com> Message-ID: <20080717170601.b7f1f9ad.torfinn.ingolfsen@broadpark.no> On Thu, 17 Jul 2008 08:31:37 -0400 Kevin K wrote: > For 7.0-RELEASE, it > seemed to hang at "Trying to mount root from ufs:/dev/md0". How long did you wait? If you didn't wait 10 or 15 minutes, please do. Various tests / probes take a long time to time out on some hardware. HTH -- Regards, Torfinn Ingolfsen From steve at ibctech.ca Thu Jul 17 16:38:28 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Thu Jul 17 16:38:35 2008 Subject: taskqueue timeout In-Reply-To: <487CCD46.8080506@ibctech.ca> References: <487CCD46.8080506@ibctech.ca> Message-ID: <487F7583.5050305@ibctech.ca> Steve Bertrand wrote: > I'm wondering if the problems described in the following link have been > resolved: > > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2008-02/msg00211.html > > > I've got four 500GB SATA disks in a ZFS raidz pool, and all four of them > are experiencing the behavior. Thanks to all who have provided patches off list. Unfortunately, none of them helped. The only other box I have with four SATA ports on it is my actual workstation. The board is ASUS P5GD1, and has an Intel 82801FR SATA controller. I despise the thought that if this works, I'll have to rebuild my workstation, but heres to sacrificing my Windows PC in the name of ruling out the problem. In the meantime, can anyone provide any feedback on the board I mentioned in regards to FreeBSD? Steve From steve at ibctech.ca Thu Jul 17 18:24:51 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Thu Jul 17 18:24:57 2008 Subject: taskqueue timeout [SOLVED] Message-ID: <59775.208.70.104.100.1216319301.squirrel@webmail.ibctech.ca> > Steve Bertrand wrote: > The only other box I have with four SATA ports on it is my actual > workstation. The board is ASUS P5GD1, and has an Intel 82801FR SATA > controller. I transferred the SATA disks to the above board, loaded up the zpool, and I can not reproduce the problem :) Currently, for the last 15 minutes, I'm writing 80MB/s to the zpool with no problems. Thanks all, Steve From cswiger at mac.com Thu Jul 17 20:20:24 2008 From: cswiger at mac.com (Chuck Swiger) Date: Thu Jul 17 20:20:31 2008 Subject: Using IP aliases, was: named.conf: query-source address In-Reply-To: <20080717140018.GA91530@svzserv.kemerovo.su> References: <20080716162042.GA27666@svzserv.kemerovo.su> <487E312E.9090307@infracaninophile.co.uk> <20080717035155.GA81536@svzserv.kemerovo.su> <8DFF6DCD-6619-4251-9944-59CED8DF1B19@mac.com> <20080717140018.GA91530@svzserv.kemerovo.su> Message-ID: On Jul 17, 2008, at 7:00 AM, Eugene Grosbein wrote: >> About the only common reason to set up multiple aliases on an >> interface is when you're doing something like hosting multiple SSL >> webservers on a single box which actually need to have distinct IPs >> as >> a consequence. Other than that, using public IPs for aliases is >> usually wasteful of IP address space. YMMV... > > Think about multiple IP-based services (not HTTP "virtual" servers) > at one physical host that should use distinct IP addresses > for some reasons (local policy/billing/monitoring/etc.) I'll reply to this particular message, but let me generalize against some of the other responses as well. If your organization does billing based on traffic, or wants to do traffic shaping or bandwidth limitation, great; but IPFW+Dummynet or PF +ALTQ don't care whether you recognize traffic by IP alone or by IP +port(s), so long as the ports are distinct for each billing category or packet queue you want to run. If you want to organize specific services on specific ports which have different backend hosts handling them to distribute load or allow you to rebalance your hardware to meet changing demand, by all means. You can have a hardware load-balancer like a NetScaler, or even use the RFC-2391 capabilities of IPFW+natd or "RDR ROUND ROBIN" with PF. But if you do that, you might as well put the actual backend machines on a RFC-1918 subnet and you might well end up using fewer public IPs than you would if all machines had public IPs. I don't have any problem with people deciding for themselves how they want to manage their services and their networks. It's just that, too often, people use IP aliases to do things like make a single physical machine appear as two so they don't actually bother to provide two actual machines for hosting DNS services with proper redundancy. Even for the shared webhosting case, where you need separate IPs per SSL cert as HTTPS doesn't support name-based virtual hosts, I'm a little dubious about the notion that having a single machine hosting lots of distinct websites, probably for different clients, is a good idea from the standpoint of security. Regards, -- -Chuck From david at vizion2000.net Thu Jul 17 20:49:00 2008 From: david at vizion2000.net (David Southwell) Date: Thu Jul 17 20:49:07 2008 Subject: Following upgrade 6.3 >7.0 /usr/libexec/save-entropy query Message-ID: <200807171410.32179.david@vizion2000.net> Receiving Automated message from cron No such messages under 6.3 Is there anything I need to attend to here? Subject: Cron <...> /usr/libexec/save-entropy Date: Thursday 17 July 2008 From: Cron Daemon To: >.......@..... unlink: /var/db/entropy/saved-entropy.8: No such file or directory mv: /var/db/entropy/saved-entropy.7: No such file or directory mv: /var/db/entropy/saved-entropy.5: No such file or directory mv: /var/db/entropy/saved-entropy.1: No such file or directory David -------------- next part -------------- unlink: /var/db/entropy/saved-entropy.8: No such file or directory mv: /var/db/entropy/saved-entropy.7: No such file or directory mv: /var/db/entropy/saved-entropy.5: No such file or directory mv: /var/db/entropy/saved-entropy.1: No such file or directory From dougb at FreeBSD.org Thu Jul 17 22:27:16 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Thu Jul 17 22:27:23 2008 Subject: Following upgrade 6.3 >7.0 /usr/libexec/save-entropy query In-Reply-To: <200807171410.32179.david@vizion2000.net> References: <200807171410.32179.david@vizion2000.net> Message-ID: <487FC742.4090000@FreeBSD.org> David Southwell wrote: > Receiving Automated message from cron > > No such messages under 6.3 > > Is there anything I need to attend to here? > > Subject: Cron <...> /usr/libexec/save-entropy > Date: Thursday 17 July 2008 > From: Cron Daemon > To: >.......@..... > > unlink: /var/db/entropy/saved-entropy.8: No such file or directory > mv: /var/db/entropy/saved-entropy.7: No such file or directory > mv: /var/db/entropy/saved-entropy.5: No such file or directory > mv: /var/db/entropy/saved-entropy.1: No such file or directory Looks like some of those files went missing, but not all. This problem will correct itself in roughly 88 minutes, but if it hasn't, or if it's annoying you, just 'rm /var/db/entropy/*' and let it start from scratch. hth, Doug -- This .signature sanitized for your protection From Mark_Andrews at isc.org Thu Jul 17 23:14:30 2008 From: Mark_Andrews at isc.org (Mark Andrews) Date: Thu Jul 17 23:14:36 2008 Subject: named.conf: query-source address In-Reply-To: Your message of "Wed, 16 Jul 2008 18:34:38 +0100." <487E312E.9090307@infracaninophile.co.uk> Message-ID: <200807172314.m6HNEPMN059378@drugs.dv.isc.org> > query-source is only ever used by recursive or stub resolvers -- > instances of named that will go out and make queries on the net on your=20 > behalf. Authoritative servers really don't need it. Actually authoritative servers make queries to work out where to send notify messages. While sending a notify to the wrong place is not that bad. It is good practice to see that authoritative servers are also fixed now rather than later. Servers have a habit of changing roles and when that happens not everyone will looks in options to see if query source is correct. Also at some point I'd like to be able to get rid of masters clauses or at least go from IP addresses to hostnames. The slave / stub zones would then have to go out and discover the ip address on the fly. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From markir at paradise.net.nz Fri Jul 18 05:38:12 2008 From: markir at paradise.net.nz (Mark Kirkwood) Date: Fri Jul 18 05:38:21 2008 Subject: USB stall with creative nomad In-Reply-To: <480C2FDE.8020903@paradise.net.nz> References: <47EC63CA.5060009@paradise.net.nz> <480AEB12.8050404@paradise.net.nz> <480C2FDE.8020903@paradise.net.nz> Message-ID: <48802849.6060300@paradise.net.nz> Mark Kirkwood wrote: > >> I wrote: >>> >>> Mar 27 13:32:30 zmori kernel: da0: >>> Removable Direct Access SCSI-4 device >>> Mar 27 13:32:30 zmori kernel: da0: 1.000MB/s transfers >>> Mar 27 13:32:30 zmori kernel: da0: 125MB (256001 512 byte sectors: >>> 64H 32S/T 125C) >>> Mar 27 13:32:39 zmori kernel: umass0: BBB reset failed, STALLED >>> Mar 27 13:32:39 zmori kernel: umass0: BBB bulk-in clear stall >>> failed, STALLED >>> >> > > ...and this is already logged as usb/119481, sorry missed it when > searching gnats previously. > Actually that above pr is for a stall on different hardware - the correct one is: usb/78984 There is a patch included there for RELENG_7, which basically applies an off-by-1 quirk to the particular device. It was commented in (one of) the related prs that this should not be necessary as Linux does not quirk any of its Nomad entries. Interestingly, it actually needs to - the 128MB Nomad does not work in Linux either! Cheers Mark From smithi at nimnet.asn.au Fri Jul 18 06:25:39 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Fri Jul 18 06:25:46 2008 Subject: named.conf: query-source address In-Reply-To: <200807172314.m6HNEPMN059378@drugs.dv.isc.org> Message-ID: On Fri, 18 Jul 2008, Mark Andrews wrote: > To: Matthew Seaman > > query-source is only ever used by recursive or stub resolvers -- > > instances of named that will go out and make queries on the net on your=20 > > behalf. Authoritative servers really don't need it. > > Actually authoritative servers make queries to work out > where to send notify messages. While sending a notify to > the wrong place is not that bad. It is good practice to > see that authoritative servers are also fixed now rather > than later. Servers have a habit of changing roles and > when that happens not everyone will looks in options to see > if query source is correct. > > Also at some point I'd like to be able to get rid of masters > clauses or at least go from IP addresses to hostnames. The > slave / stub zones would then have to go out and discover > the ip address on the fly. Re the latter point, I can see the advantage of being able to move a primary server to a new IP address without needing slave/s to update their config. On the other hand I can see possible chicken/egg issues in some instances, for example testing axfrs before a new domain comes online, or a domain disappearing even temporarily ([re-]registration problems, politics or other upstream failures) where specifying masters by IP address keeps things rolling. At least consider keeping config-time hostname resolution of masters optional? And I guess the same principles apply to allow-transfer, forwarders and other address lists? cheers, Ian From screwdriver at lxnt.info Fri Jul 18 08:18:37 2008 From: screwdriver at lxnt.info (Alexander Sabourenkov) Date: Fri Jul 18 08:18:44 2008 Subject: Using IP aliases, was: named.conf: query-source address In-Reply-To: References: <20080716162042.GA27666@svzserv.kemerovo.su> <487E312E.9090307@infracaninophile.co.uk> <20080717035155.GA81536@svzserv.kemerovo.su> <8DFF6DCD-6619-4251-9944-59CED8DF1B19@mac.com> <20080717140018.GA91530@svzserv.kemerovo.su> Message-ID: <4880484C.2030203@lxnt.info> Chuck Swiger wrote: > I'm a little dubious > about the notion that having a single machine hosting lots of distinct > websites, probably for different clients, is a good idea from the > standpoint of security. > Well, good luck selling the idea of replacing one dual xeon 1U box with 2000+ other boxes to the management. -- ./lxnt From rb at gid.co.uk Fri Jul 18 14:39:07 2008 From: rb at gid.co.uk (Bob Bishop) Date: Fri Jul 18 14:39:14 2008 Subject: em vs IPMI Message-ID: Hi, Under 7.0R, I've had problems with IPMI over LAN failing across reboot on an Intel S3200SH m/b. I see the following at line 669 of if_em.c: /* Indicate SOL/IDER usage */ if (e1000_check_reset_block(&adapter->hw)) device_printf(dev, "PHY reset is blocked due to SOL/IDER session.\n"); Two questions: 1. Am I correct to infer that PHY reset will kill the IPMI LAN setup? 2. Does the above mean I don't have to worry about losing IPMI if I have an established SOL session? I'm particularly concerned about getting into single user. I figured out how to reestablish access using ipmitool to poke the IPMI LAN setup, but of course I can only get in to do that if the box is up multiuser. I'd find out the answers by experiment, but the box is in production in a colo so it's not so easy. Thanks -- Bob Bishop +44 (0)118 940 1243 rb@gid.co.uk fax +44 (0)118 940 1295 mobile +44 (0)783 626 4518 From kkutzko at teksavvy.com Fri Jul 18 15:32:04 2008 From: kkutzko at teksavvy.com (Kevin K) Date: Fri Jul 18 15:32:10 2008 Subject: HP Pavilion dv2000 laptop wont boot off install cd In-Reply-To: <20080717170601.b7f1f9ad.torfinn.ingolfsen@broadpark.no> References: <200807161353.m6GDrDFB058142@lurza.secnetix.de> <009301c8e797$1385e880$3a91b980$@com> <00b301c8e806$eeb3d5b0$cc1b8110$@com> <00b401c8e809$0ed63c50$2c82b4f0$@com> <20080717170601.b7f1f9ad.torfinn.ingolfsen@broadpark.no> Message-ID: <000301c8e8eb$6c56de10$45049a30$@com> > How long did you wait? If you didn't wait 10 or 15 minutes, please do. > Various tests / probes take a long time to time out on some hardware. > > HTH > -- > Regards, > Torfinn Ingolfsen I'll try that as soon as I get a chance. For anyone who's interested, here's more details on the hardware of my hp pavilion dv2000 laptop : Motherboard manufacturer :Wistron Model: 30B5 Version: 62.57 North Bridge: NVIDIA GeForce 6150 Revision A2 South Bridge: NVIDIA nForce 410/430 MCP Revision A2 CPU: AMD Turion(tm) 64 X2 Mobile tl-56 CPU Socket: Socket S1 (638) CPU Code Name: Trinidad Instructions: MMX(+), 3DNow! (+), SSE, SSE2, SSE3, x86-64, NX, VMX From unga888 at yahoo.com Sat Jul 19 02:05:18 2008 From: unga888 at yahoo.com (Unga) Date: Sat Jul 19 02:05:24 2008 Subject: Pseudoterminals increase: compilation error Message-ID: <519800.22206.qm@web57003.mail.re3.yahoo.com> Hi all I'm using FreeBSD 7.0. As per FAQ, http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/admin.html, I tried to increase the number of ptys: "10.19.1 Build and install a new kernel with the line in the configuration file: device pty N where N is the number of requested pseudoterminals." I tried to recompile the kernel. I have modified the GENERIC as follows: device pty 64 # Pseudo-ttys (telnet etc) This results a compilation error: config: /usr/src/sys/i386/conf/GENERIC:268: syntax error *** Error code 1 What is the correct syntax? Kind Regards Unga From killing at multiplay.co.uk Sat Jul 19 02:33:38 2008 From: killing at multiplay.co.uk (Steven Hartland) Date: Sat Jul 19 02:33:44 2008 Subject: Pseudoterminals increase: compilation error References: <519800.22206.qm@web57003.mail.re3.yahoo.com> Message-ID: <89DD759A9BAB4BA8AAE96F38F652218E@multiplay.co.uk> iirc pty is totally dynamic in 7 and doesn't require any special tweaks. Regards Steve ----- Original Message ----- From: "Unga" To: Sent: Saturday, July 19, 2008 2:38 AM Subject: Pseudoterminals increase: compilation error > Hi all > > I'm using FreeBSD 7.0. > > As per FAQ, http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/admin.html, I tried to increase the number of ptys: > "10.19.1 > Build and install a new kernel with the line in the > configuration file: > device pty N > where N is the number of requested pseudoterminals." > > I tried to recompile the kernel. I have modified the GENERIC as follows: > device pty 64 # Pseudo-ttys (telnet etc) > > This results a compilation error: > config: /usr/src/sys/i386/conf/GENERIC:268: syntax error > *** Error code 1 > > What is the correct syntax? > > Kind Regards > Unga > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From unga888 at yahoo.com Sat Jul 19 02:36:24 2008 From: unga888 at yahoo.com (Unga) Date: Sat Jul 19 02:36:31 2008 Subject: Pseudoterminals increase: compilation error In-Reply-To: <89DD759A9BAB4BA8AAE96F38F652218E@multiplay.co.uk> Message-ID: <677096.31987.qm@web57014.mail.re3.yahoo.com> --- On Sat, 7/19/08, Steven Hartland wrote: > From: Steven Hartland > Subject: Re: Pseudoterminals increase: compilation error > To: unga888@yahoo.com, freebsd-stable@freebsd.org > Date: Saturday, July 19, 2008, 10:15 AM > iirc pty is totally dynamic in 7 and doesn't require any > special tweaks. > Hi, thanks for the reply. I get this error: "The system has no more ptys. Ask your system administrator to create more." 1) That is, this error message is nothing to do with ptys? What does it trying to say then? 2) Even if ptys are totally dynamic in 7, what is the upper limit and where it is defined? in which source file or header file? Please answer if you know this. I'm really stuck. kind regards Unga From killing at multiplay.co.uk Sat Jul 19 02:43:39 2008 From: killing at multiplay.co.uk (Steven Hartland) Date: Sat Jul 19 02:43:46 2008 Subject: Pseudoterminals increase: compilation error References: <677096.31987.qm@web57014.mail.re3.yahoo.com> Message-ID: <8410CCD0D6994784839D8FE43BB32F2B@multiplay.co.uk> Ahh according to the man page its not a sysctl: kern.pts.max man 4 pty for more info. ----- Original Message ----- From: "Unga" > Hi, thanks for the reply. > > I get this error: "The system has no more ptys. Ask your system administrator to create more." > > 1) That is, this error message is nothing to do with ptys? What does it trying to say then? > > 2) Even if ptys are totally dynamic in 7, what is the upper limit and where it is defined? in which source file or header file? > > Please answer if you know this. I'm really stuck. ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From unga888 at yahoo.com Sat Jul 19 02:50:34 2008 From: unga888 at yahoo.com (Unga) Date: Sat Jul 19 02:50:41 2008 Subject: Pseudoterminals increase: compilation error In-Reply-To: <8410CCD0D6994784839D8FE43BB32F2B@multiplay.co.uk> Message-ID: <967400.26093.qm@web57015.mail.re3.yahoo.com> --- On Sat, 7/19/08, Steven Hartland wrote: > From: Steven Hartland > Subject: Re: Pseudoterminals increase: compilation error > To: unga888@yahoo.com > Cc: freebsd-stable@freebsd.org > Date: Saturday, July 19, 2008, 10:38 AM > Ahh according to the man page its not a sysctl: > kern.pts.max > > man 4 pty for more info. > I use the the original BSD pty. According to the man page kern.pts.max is for SysVR4 pts-like implementation, well, that how I understand. Anyway, I'll give it a try and let the list know. Regards Unga From unga888 at yahoo.com Sat Jul 19 02:53:51 2008 From: unga888 at yahoo.com (Unga) Date: Sat Jul 19 02:53:58 2008 Subject: Pseudoterminals increase: compilation error In-Reply-To: <967400.26093.qm@web57015.mail.re3.yahoo.com> Message-ID: <116638.27943.qm@web57008.mail.re3.yahoo.com> --- On Sat, 7/19/08, Unga wrote: > From: Unga > Subject: Re: Pseudoterminals increase: compilation error > To: "Steven Hartland" > Cc: freebsd-stable@freebsd.org > Date: Saturday, July 19, 2008, 10:50 AM > --- On Sat, 7/19/08, Steven Hartland > wrote: > > > From: Steven Hartland > > Subject: Re: Pseudoterminals increase: compilation > error > > To: unga888@yahoo.com > > Cc: freebsd-stable@freebsd.org > > Date: Saturday, July 19, 2008, 10:38 AM > > Ahh according to the man page its not a sysctl: > > kern.pts.max > > > > man 4 pty for more info. > > > > I use the the original BSD pty. According to the man page > kern.pts.max is for SysVR4 pts-like implementation, well, > that how I understand. Anyway, I'll give it a try and > let the list know. > Ooops, I forgot: kern.pts.max defaults to 1000. If this is the default, I may not have a problem :) Regards Unga From peter at wemm.org Sat Jul 19 06:29:51 2008 From: peter at wemm.org (Peter Wemm) Date: Sat Jul 19 06:29:58 2008 Subject: how to get more logging from GEOM? In-Reply-To: References: <20080711164939.GA10238@lava.net> Message-ID: On Wed, Jul 16, 2008 at 2:42 PM, Jo Rhett wrote: >> On Fri, Jul 11, 2008 at 12:59:33AM -0700, Jo Rhett wrote: >>> >>> Every time it is rebuilding ad0. Every single boot in the last two >>> weeks. > > On Jul 11, 2008, at 9:49 AM, Clifton Royston wrote: >> >> That just means that it halted without a proper shutdown. If it >> crashes, the mirror isn't stopped properly, so it's marked dirty, so it >> must rebuild it. It is the precise analogy of finding all the file >> systems dirty on boot and fscking them, following a crash. > > > Thanks for the clarification. Dang, I hoped I was on to something. This is really off on a tangent, but I thought I'd mention it on the off-chance that it fit your problem. Recently there have been grumblings about heat problems with certain nvidia chipsets on consumer boards. Apparently, there is some process issue, if you believe trade rags like theinquirer.net etc. Apparently there is some issue with heat damage over time. Consumer motherboards with passive cooled (no fan) heat pipes etc seem to be particularly vulnerable. I use the word "apparently" because it is far from a verified fact. However, I've got two motherboards, one running freebsd, one running windows, with nvidia chipsets. Both used to be fine with onboard IDE activity. Both now use raid controllers so the IDE interfaces have been idle for a good year or so. Something came up and I had to use the IDE interfaces for a lot of data transfer. Suddenly, both machines are flakey. The windows machine blue screens under load. My freebsd box just "turns off" (motherboard appears to power off, but the power supply is on still). The same happens when I use a linux boot disk, so I know its not FreeBSD's fault. The common factor seems to be that the motherboards are now about a year and a half old. They both have the same nvidia south bridge that theinquirer.net was trashing. Both used to work fine, now have problems with IDE. and now I recalled the article and started wondering... Do you, by any wildly remote chance, have an nvidia based motherboard? I believe the fault I'm seeing is the system asserting a fatal error by doing a HT ECC flood to halt everything. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From dougb at FreeBSD.org Sat Jul 19 07:05:12 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Sat Jul 19 07:05:19 2008 Subject: named.conf: query-source address In-Reply-To: <20080717221942.41191@caamora.com.au> References: <20080716162042.GA27666@svzserv.kemerovo.su> <20080716205705.GA25198@eos.sc1.parodius.com> <487E66D0.1050000@FreeBSD.org> <20080716214957.GA26869@eos.sc1.parodius.com> <487ED467.3000000@FreeBSD.org> <20080717221942.41191@caamora.com.au> Message-ID: <48819224.5010502@FreeBSD.org> jonathan michaels wrote: > Doug, et al, > > i for one appreciate this "over-engieered" responce because it has > given me (and those like me) a chance to get answers to questions that > we have asked for over a year in my case, about this whole bind setup > issue. I have no idea what you mean by "questions that we have asked for over a year." (Although, if you've asked on freebsd-questions@ I would not have seen it.) There is the bind-users@isc.org mailing list where you can get answers to anything bind-related, and there are plenty of people knowledgeable about running it on freebsd on that list even if I don't get a chance to answer first. Of course there are also plenty of resources, the most important being "DNS and BIND, 5th Edition." http://oreilly.com/catalog/9780596100575/index.html which you should definitely read and have handy if you're doing any DNS work that is even marginally complex. > as an asideo, it would be better for people coming in cold could find a > better source of who to setup support services such as bind and all teh > others for a woring freebsd based network .. Our Handbook is an excellent source for this. If you feel that the articles are written at too high a level feel free to send some feedback on that. Most of us have long ago lost our ability to see things the way the mythical "average user" does, so that kind of feedback is very valuable. Someone else also mentioned http://www.absolutefreebsd.com/, which I highly recommend. hth, Doug -- This .signature sanitized for your protection From oleg at opentransfer.com Sat Jul 19 07:46:11 2008 From: oleg at opentransfer.com (Oleg V. Nauman) Date: Sat Jul 19 07:46:18 2008 Subject: ACPI regression on recent 7.0-STABLE: HPET stops working Message-ID: <20080719100315.2td4dl2q5ck88wkw@webmail.opentransfer.com> It seems to be something was changed with ACPI support on 7.0-STABLE so my next system upgrade ended with ACPI HPET not working anymore on my ASUS A9Rp laptop. Here is the part of /var/log/dmesg.today dated July 13: FreeBSD 7.0-STABLE #65: Tue Jul 8 22:05:07 EEST 2008 root@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2 [..] acpi0: on motherboard acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 77f00000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 Here is the fresh dmesg output info: FreeBSD 7.0-STABLE #66: Tue Jul 15 22:11:27 EEST 2008 root@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2 [..] acpi0: on motherboard acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 77f00000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 [..] acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 device_attach: acpi_hpet0 attach returned 12 And the part of actual sysctl kern.timecounter output: kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) dummy(-1000000) kern.timecounter.hardware: ACPI-safe -- Oleg From koitsu at FreeBSD.org Sat Jul 19 08:02:12 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sat Jul 19 08:02:20 2008 Subject: ACPI regression on recent 7.0-STABLE: HPET stops working In-Reply-To: <20080719100315.2td4dl2q5ck88wkw@webmail.opentransfer.com> References: <20080719100315.2td4dl2q5ck88wkw@webmail.opentransfer.com> Message-ID: <20080719080212.GA89036@eos.sc1.parodius.com> On Sat, Jul 19, 2008 at 10:03:15AM +0300, Oleg V. Nauman wrote: > It seems to be something was changed with ACPI support on 7.0-STABLE so > my next system upgrade ended with ACPI HPET not working anymore on my > ASUS A9Rp laptop. > > Here is the part of /var/log/dmesg.today dated July 13: > > FreeBSD 7.0-STABLE #65: Tue Jul 8 22:05:07 EEST 2008 > root@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2 > [..] > acpi0: on motherboard > acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, 77f00000 (3) failed > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > acpi_ec0: port 0x62,0x66 on acpi0 > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 900 > > Here is the fresh dmesg output info: > > FreeBSD 7.0-STABLE #66: Tue Jul 15 22:11:27 EEST 2008 > root@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2 > [..] > acpi0: on motherboard > acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, 77f00000 (3) failed > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > [..] > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > device_attach: acpi_hpet0 attach returned 12 > > And the part of actual sysctl kern.timecounter output: > > kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) dummy(-1000000) > kern.timecounter.hardware: ACPI-safe Seems okay here: FreeBSD icarus.home.lan 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat Jul 12 10:53:08 PDT 2008 root@icarus.home.lan:/usr/obj/usr/src/sys/PDSMI_PLUS_amd64 amd64 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Timecounter "HPET" frequency 14318180 Hz quality 900 Timecounters tick every 1.000 msec kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) dummy(-1000000) kern.timecounter.hardware: ACPI-fast You sure you haven't upgraded your BIOS or something and forgot to re-enable HPET? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From oleg at opentransfer.com Sat Jul 19 08:19:53 2008 From: oleg at opentransfer.com (Oleg V. Nauman) Date: Sat Jul 19 08:20:00 2008 Subject: ACPI regression on recent 7.0-STABLE: HPET stops working In-Reply-To: <20080719080212.GA89036@eos.sc1.parodius.com> References: <20080719100315.2td4dl2q5ck88wkw@webmail.opentransfer.com> <20080719080212.GA89036@eos.sc1.parodius.com> Message-ID: <20080719111838.il32fec2880wok4g@webmail.opentransfer.com> Quoting Jeremy Chadwick : > On Sat, Jul 19, 2008 at 10:03:15AM +0300, Oleg V. Nauman wrote: >> It seems to be something was changed with ACPI support on 7.0-STABLE so >> my next system upgrade ended with ACPI HPET not working anymore on my >> ASUS A9Rp laptop. >> >> Here is the part of /var/log/dmesg.today dated July 13: >> >> FreeBSD 7.0-STABLE #65: Tue Jul 8 22:05:07 EEST 2008 >> root@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2 >> [..] >> acpi0: on motherboard >> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 >> acpi0: [ITHREAD] >> acpi0: Power Button (fixed) >> acpi0: reservation of 0, a0000 (3) failed >> acpi0: reservation of 100000, 77f00000 (3) failed >> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 >> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 >> acpi_ec0: port 0x62,0x66 on acpi0 >> acpi_hpet0: iomem >> 0xfed00000-0xfed003ff on acpi0 >> Timecounter "HPET" frequency 14318180 Hz quality 900 >> >> Here is the fresh dmesg output info: >> >> FreeBSD 7.0-STABLE #66: Tue Jul 15 22:11:27 EEST 2008 >> root@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2 >> [..] >> acpi0: on motherboard >> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 >> acpi0: [ITHREAD] >> acpi0: Power Button (fixed) >> acpi0: reservation of 0, a0000 (3) failed >> acpi0: reservation of 100000, 77f00000 (3) failed >> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 >> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 >> [..] >> acpi_hpet0: iomem >> 0xfed00000-0xfed003ff on acpi0 >> device_attach: acpi_hpet0 attach returned 12 >> >> And the part of actual sysctl kern.timecounter output: >> >> kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) dummy(-1000000) >> kern.timecounter.hardware: ACPI-safe > > Seems okay here: > > FreeBSD icarus.home.lan 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat Jul 12 > 10:53:08 PDT 2008 > root@icarus.home.lan:/usr/obj/usr/src/sys/PDSMI_PLUS_amd64 amd64 > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > Timecounter "HPET" frequency 14318180 Hz quality 900 > Timecounters tick every 1.000 msec > > kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) > i8254(0) dummy(-1000000) > kern.timecounter.hardware: ACPI-fast > > You sure you haven't upgraded your BIOS or something and forgot to > re-enable HPET? No it was not upgraded.. Have no option to enable/disable HPET through BIOS settings though From daniel_k_eriksson at telia.com Sat Jul 19 08:51:24 2008 From: daniel_k_eriksson at telia.com (Daniel Eriksson) Date: Sat Jul 19 08:51:31 2008 Subject: Panic on ZFS startup after crash Message-ID: <4F9C9299A10AE74E89EA580D14AA10A61A197A@royal64.emp.zapto.org> I have a large ZFS pool that seems to be partially corrupt, causing a panic on ZFS startup. This is on a RELENG_7_0 machine. This is what happens when I try to start ZFS (written down by hand): ZFS: WARNING: can't process intent log for tank02/home ZFS: WARNING: can't process intent log for tank02 panic: solaris assert: dmu_read(os, smo->smo_object, offset, size, entry_map) == 0 (0x5 == 0x0), file: /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/spa ce_map.c, line: 341 The pool sits on top of a geli-encrypted hardware raid-array (Highpoint RocketRAID 2340, 8 x 500GB in RAID-5 config). Unfortunately the array broke (2 drives disconnected) due to a bad PSU, and this eventually crashed the box. When I restarted the box the above message showed up as soon as I started ZFS. It is my understanding that the intent log is emptied on clean shutdown, and if it is not empty during startup ZFS tries to "replay" the transactions recorded in it. I assume the initial crash left the intent log in an inconsistent state and that ZFS panics on startup due to badly formatted data in the intent log. Is there any way I can recover this pool? ___ Daniel Eriksson (http://www.toomuchdata.com/) From alex at trull.org Sat Jul 19 09:17:22 2008 From: alex at trull.org (Alex Trull) Date: Sat Jul 19 09:17:29 2008 Subject: Panic on ZFS startup after crash In-Reply-To: <4F9C9299A10AE74E89EA580D14AA10A61A197A@royal64.emp.zapto.org> References: <4F9C9299A10AE74E89EA580D14AA10A61A197A@royal64.emp.zapto.org> Message-ID: <1216459022.6521.6.camel@porksoda> I've tried neither of these in your particular case, but they might be worth a try: Just a suggestion, but try specify vfs.zfs.zil_disable=1 or as a kernel variable in the boot cli. You may want to try export and import the pool and see how it likes it then. -- Alex On Sat, 2008-07-19 at 10:51 +0200, Daniel Eriksson wrote: > I have a large ZFS pool that seems to be partially corrupt, causing a > panic on ZFS startup. This is on a RELENG_7_0 machine. > > This is what happens when I try to start ZFS (written down by hand): > > ZFS: WARNING: can't process intent log for tank02/home > ZFS: WARNING: can't process intent log for tank02 > panic: solaris assert: dmu_read(os, smo->smo_object, offset, size, > entry_map) == 0 (0x5 == 0x0), file: > /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/spa > ce_map.c, line: 341 > > The pool sits on top of a geli-encrypted hardware raid-array (Highpoint > RocketRAID 2340, 8 x 500GB in RAID-5 config). Unfortunately the array > broke (2 drives disconnected) due to a bad PSU, and this eventually > crashed the box. When I restarted the box the above message showed up as > soon as I started ZFS. > > It is my understanding that the intent log is emptied on clean shutdown, > and if it is not empty during startup ZFS tries to "replay" the > transactions recorded in it. I assume the initial crash left the intent > log in an inconsistent state and that ZFS panics on startup due to badly > formatted data in the intent log. > > Is there any way I can recover this pool? > > > ___ > Daniel Eriksson (http://www.toomuchdata.com/) > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080719/f0e6f39e/attachment.pgp From daniel_k_eriksson at telia.com Sat Jul 19 10:51:06 2008 From: daniel_k_eriksson at telia.com (Daniel Eriksson) Date: Sat Jul 19 10:51:13 2008 Subject: Panic on ZFS startup after crash In-Reply-To: <1216459022.6521.6.camel@porksoda> References: <4F9C9299A10AE74E89EA580D14AA10A61A197A@royal64.emp.zapto.org> <1216459022.6521.6.camel@porksoda> Message-ID: <4F9C9299A10AE74E89EA580D14AA10A61A197B@royal64.emp.zapto.org> Alex Trull wrote: > I've tried neither of these in your particular case, but they might be > worth a try: > > Just a suggestion, but try specify vfs.zfs.zil_disable=1 or > as a kernel > variable in the boot cli. > > You may want to try export and import the pool and see how it likes it > then. I considered disabling the zil but didn't think it would make a difference (because zfs will most likely check if there is any data in zil on startup anyway). I'll try it though! Importing the pool results in the exact same problem. (I couldn't export the live pool because the box paniced, but by making sure the vdev was unavailable on zfs startup I could export the stale pool, enable the vdev (by doing a "geli attach") and then I tried to import the pool. No luck, same panic message. ___ Daniel Eriksson (http://www.toomuchdata.com/) From peterjeremy at optushome.com.au Sat Jul 19 12:04:38 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Sat Jul 19 12:04:46 2008 Subject: Pseudoterminals increase: compilation error In-Reply-To: <519800.22206.qm@web57003.mail.re3.yahoo.com> References: <519800.22206.qm@web57003.mail.re3.yahoo.com> Message-ID: <20080719120434.GK62764@server.vk2pj.dyndns.org> On 2008-Jul-18 18:38:36 -0700, Unga wrote: >As per FAQ, http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/admin.html, I tried to increase the number of ptys: > "10.19.1 > Build and install a new kernel with the line in the > configuration file: > device pty N > where N is the number of requested pseudoterminals." That has been obsolete for a while. Do you actually have a problem with insufficient PTYs? -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080719/c8d533be/attachment.pgp From unga888 at yahoo.com Sat Jul 19 13:49:40 2008 From: unga888 at yahoo.com (Unga) Date: Sat Jul 19 13:49:48 2008 Subject: Pseudoterminals increase: compilation error In-Reply-To: <20080719120434.GK62764@server.vk2pj.dyndns.org> Message-ID: <355179.86182.qm@web57003.mail.re3.yahoo.com> --- On Sat, 7/19/08, Peter Jeremy wrote: > From: Peter Jeremy > Subject: Re: Pseudoterminals increase: compilation error > To: "Unga" > Cc: freebsd-stable@freebsd.org > Date: Saturday, July 19, 2008, 8:04 PM > On 2008-Jul-18 18:38:36 -0700, Unga > wrote: > >As per FAQ, > http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/admin.html, > I tried to increase the number of ptys: > > "10.19.1 > > Build and install a new kernel with the line in the > > configuration file: > > device pty N > > where N is the number of requested > pseudoterminals." > > That has been obsolete for a while. Do you actually have a > problem > with insufficient PTYs? > Looks like, may not be. The Problem: expect -c "spawn ls" spawn ls The system has no more ptys. Ask your system administrator to create more. while executing "spawn ls" It now seems to be a permission problem as explained in http://expect.nist.gov/FAQ.html#q67 . Still investigating. Any help will be very much appreciated. Unga From daniel_k_eriksson at telia.com Sat Jul 19 16:59:13 2008 From: daniel_k_eriksson at telia.com (Daniel Eriksson) Date: Sat Jul 19 16:59:20 2008 Subject: Panic on ZFS startup after crash In-Reply-To: <1216459022.6521.6.camel@porksoda> References: <4F9C9299A10AE74E89EA580D14AA10A61A197A@royal64.emp.zapto.org> <1216459022.6521.6.camel@porksoda> Message-ID: <4F9C9299A10AE74E89EA580D14AA10A61A197C@royal64.emp.zapto.org> Alex Trull wrote: > Just a suggestion, but try specify vfs.zfs.zil_disable=1 or > as a kernel variable in the boot cli. I just tried this and unfortunately it didn't work. I got the exact same kernel panic. I've been looking through the code to try to find a way to fool ZFS into thinking the intent log. Anyone familiar with the code that could point me in the right direction? ___ Daniel Eriksson (http://www.toomuchdata.com/) From marck at rinet.ru Sat Jul 19 18:11:41 2008 From: marck at rinet.ru (Dmitry Morozovsky) Date: Sat Jul 19 18:11:49 2008 Subject: Panic on ZFS startup after crash In-Reply-To: <4F9C9299A10AE74E89EA580D14AA10A61A197C@royal64.emp.zapto.org> References: <4F9C9299A10AE74E89EA580D14AA10A61A197A@royal64.emp.zapto.org> <1216459022.6521.6.camel@porksoda> <4F9C9299A10AE74E89EA580D14AA10A61A197C@royal64.emp.zapto.org> Message-ID: <20080719221051.K84934@woozle.rinet.ru> On Sat, 19 Jul 2008, Daniel Eriksson wrote: DE> > Just a suggestion, but try specify vfs.zfs.zil_disable=1 or DE> > as a kernel variable in the boot cli. DE> DE> I just tried this and unfortunately it didn't work. I got the exact same DE> kernel panic. DE> DE> I've been looking through the code to try to find a way to fool ZFS into DE> thinking the intent log. Anyone familiar with the code that could point DE> me in the right direction? You may find useful trying to ask Pawel (pjd@) directly. I'd CC:d him to simplify process ;-) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From dnelson at allantgroup.com Sat Jul 19 21:56:11 2008 From: dnelson at allantgroup.com (Dan Nelson) Date: Sat Jul 19 21:56:18 2008 Subject: Pseudoterminals increase: compilation error In-Reply-To: <355179.86182.qm@web57003.mail.re3.yahoo.com> References: <20080719120434.GK62764@server.vk2pj.dyndns.org> <355179.86182.qm@web57003.mail.re3.yahoo.com> Message-ID: <20080719213056.GE19044@dan.emsphone.com> In the last episode (Jul 19), Unga said: > On Sat, 7/19/08, Peter Jeremy wrote: > > On 2008-Jul-18 18:38:36 -0700, Unga wrote: > > >As per FAQ, > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/admin.html, > > > I tried to increase the number of ptys: "10.19.1 Build and > > > install a new kernel with the line in the configuration file: > > > device pty N where N is the number of requested pseudoterminals." > > > > That has been obsolete for a while. Do you actually have a problem > > with insufficient PTYs? > > Looks like, may not be. > > The Problem: > expect -c "spawn ls" > spawn ls > The system has no more ptys. Ask your system administrator to create > more. while executing "spawn ls" > > It now seems to be a permission problem as explained in > http://expect.nist.gov/FAQ.html#q67 . > > Still investigating. Any help will be very much appreciated. Expect's error message doesn't say anything except "something isn't working but I won't tell you what". Run truss -o truss.log -f expect -c "spawn ls" and determine which syscall is failing, with what error number, just before expect prints its "no more ptys" message. That will tell you whether it's a permissions issue, or something else. If there are no obvious errors, post a part of the log. Also, what version of expect are you running? Versions between 5.38.0_1 and 5.43.0_2 had a bug in the port Makefile that limited the number of ptys expect could see. See http://www.freebsd.org/cgi/query-pr.cgi?pr=108311 . -- Dan Nelson dnelson@allantgroup.com From pjd at FreeBSD.org Sat Jul 19 22:47:01 2008 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Sat Jul 19 22:47:30 2008 Subject: Panic on ZFS startup after crash In-Reply-To: <4F9C9299A10AE74E89EA580D14AA10A61A197A@royal64.emp.zapto.org> References: <4F9C9299A10AE74E89EA580D14AA10A61A197A@royal64.emp.zapto.org> Message-ID: <20080719221813.GC4733@garage.freebsd.pl> On Sat, Jul 19, 2008 at 10:51:21AM +0200, Daniel Eriksson wrote: > > I have a large ZFS pool that seems to be partially corrupt, causing a > panic on ZFS startup. This is on a RELENG_7_0 machine. > > This is what happens when I try to start ZFS (written down by hand): > > ZFS: WARNING: can't process intent log for tank02/home > ZFS: WARNING: can't process intent log for tank02 > panic: solaris assert: dmu_read(os, smo->smo_object, offset, size, > entry_map) == 0 (0x5 == 0x0), file: > /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/spa > ce_map.c, line: 341 > > The pool sits on top of a geli-encrypted hardware raid-array (Highpoint > RocketRAID 2340, 8 x 500GB in RAID-5 config). Unfortunately the array > broke (2 drives disconnected) due to a bad PSU, and this eventually > crashed the box. When I restarted the box the above message showed up as > soon as I started ZFS. > > It is my understanding that the intent log is emptied on clean shutdown, > and if it is not empty during startup ZFS tries to "replay" the > transactions recorded in it. I assume the initial crash left the intent > log in an inconsistent state and that ZFS panics on startup due to badly > formatted data in the intent log. > > Is there any way I can recover this pool? Can you try this patch? http://people.freebsd.org/~pjd/patches/space_map.c.patch -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080719/befab733/attachment.pgp From unga888 at yahoo.com Sun Jul 20 02:44:19 2008 From: unga888 at yahoo.com (Unga) Date: Sun Jul 20 02:44:26 2008 Subject: Pseudoterminals increase: compilation error In-Reply-To: <20080719213056.GE19044@dan.emsphone.com> Message-ID: <545719.90429.qm@web57010.mail.re3.yahoo.com> --- On Sun, 7/20/08, Dan Nelson wrote: > Expect's error message doesn't say anything except > "something isn't > working but I won't tell you what". Run > > truss -o truss.log -f expect -c "spawn ls" > > and determine which syscall is failing, with what error > number, just > before expect prints its "no more ptys" message. > That will tell you > whether it's a permissions issue, or something else. > If there are no > obvious errors, post a part of the log. > > Also, what version of expect are you running? Versions > between > 5.38.0_1 and 5.43.0_2 had a bug in the port Makefile that > limited the > number of ptys expect could see. See > http://www.freebsd.org/cgi/query-pr.cgi?pr=108311 . > Here are more detail. In fact, I noted it through strace after my previous email. ls -l /dev/ | grep pty crw-rw-rw- 1 root wheel 0, 169 Jul 20 10:11 ptyp0 crw-rw-rw- 1 root wheel 0, 171 Jul 20 10:22 ptyp1 truss -o truss.log -f expect -c "spawn ls" 1178: open("/dev/ptyp0",O_RDWR,027757763030) ERR#5 'Input/output error' 1178: open("/dev/ptyp1",O_RDWR,027757763030) ERR#5 'Input/output error' 1178: open("/dev/ptyp2",O_RDWR,027757763030) = 5 (0x5) 1178: fstat(5,{mode=crw-rw-rw- ,inode=178,size=0,blksize=4096}) = 0 (0x0) : : 1178: chown("/dev/ttyp2",1002,4) ERR#1 'Operation not permitted' 1178: close(5) = 0 (0x0) 1178: close(-1) ERR#9 'Bad file descriptor' 1178: close(-1) ERR#9 'Bad file descriptor' 1178: open("/",O_RDONLY,027757764430) = 5 (0x5) 1178: close(5) = 0 (0x0) 1178: write(2,"The system has no more ptys. As"...,106) = 106 (0x6a) 1178: write(2,"\r\n",2) = 1179 (0x49b) = 2 (0x2) ls -l /dev/ | grep pty crw-rw-rw- 1 root wheel 0, 169 Jul 20 10:11 ptyp0 crw-rw-rw- 1 root wheel 0, 171 Jul 20 10:23 ptyp1 crw-rw-rw- 1 root wheel 0, 178 Jul 20 10:11 ptyp2 I'm using Expect-5.43.0 compiled from sources. So, it looks like some sort of a misconfiguration. Still investigating. Regards Unga From brett at lariat.net Sun Jul 20 02:50:40 2008 From: brett at lariat.net (Brett Glass) Date: Sun Jul 20 02:50:48 2008 Subject: FreeBSD 7.1 and BIND exploit Message-ID: <200807200230.UAA17164@lariat.net> Everyone: Will FreeBSD 7.1 be released in time to use it as an upgrade to close the BIND cache poisoning hole? We'd like to upgrade affected servers to the latest FreeBSD at the same time that we upgrade BIND if possible. --Brett Glass From delphij at delphij.net Sun Jul 20 03:02:35 2008 From: delphij at delphij.net (Xin LI) Date: Sun Jul 20 03:02:43 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <200807200230.UAA17164@lariat.net> References: <200807200230.UAA17164@lariat.net> Message-ID: <4882AAC1.6010501@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brett Glass wrote: | Everyone: | | Will FreeBSD 7.1 be released in time to use it as an upgrade to | close the BIND cache poisoning hole? We'd like to upgrade affected | servers to the latest FreeBSD at the same time that we upgrade | BIND if possible. Yes. FreeBSD 7-STABLE and RELENG_7_0 errata branches are already patched and not vulnerable to the problem. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkiCqsEACgkQi+vbBBjt66CnfQCfRazbYaZYS/u9oqV2FV6MdP7U 7OsAni83DoLYN6fkUVCZig0YZbSFTLuW =OMOy -----END PGP SIGNATURE----- From brett at lariat.net Sun Jul 20 03:21:15 2008 From: brett at lariat.net (Brett Glass) Date: Sun Jul 20 03:21:22 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <4882AAC1.6010501@delphij.net> References: <200807200230.UAA17164@lariat.net> <4882AAC1.6010501@delphij.net> Message-ID: <200807200321.VAA17553@lariat.net> I'd like to install a fully tested 7.1-RELEASE, rather than a snapshot of 7-STABLE (in which there have, apparently, been some problems due to driver updates and work on the TCP stack). Alas, I haven't seen any schedule or "to do" list for the release process yet -- just a note saying that 7.1-RELEASE is scheduled for August. I'm sure that a lot of folks are in the same boat as I: they'd like to start with a complete release that doesn't need patching and recompiling. --Brett Glass At 09:02 PM 7/19/2008, Xin LI wrote: >Yes. FreeBSD 7-STABLE and RELENG_7_0 errata branches are already >patched and not vulnerable to the problem. > >Cheers, >- -- >Xin LI http://www.delphij.net/ From brett at lariat.net Sun Jul 20 03:36:57 2008 From: brett at lariat.net (Brett Glass) Date: Sun Jul 20 03:37:04 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: References: <200807200230.UAA17164@lariat.net> <4882AAC1.6010501@delphij.net> <200807200321.VAA17553@lariat.net> Message-ID: <200807200336.VAA17727@lariat.net> At 09:28 PM 7/19/2008, Subhro wrote: >You need to understand the release engineering process of FreeeBSD. I've been watching it (and testing release candidates) since 2.x, so I think I may possibly have some understanding of it by now. ;-) >The release edition is essential created from the stabe edition. 7.1R >would not be something new which is *not* present on 7-STABLE today. Mostly true. But the new release would undergo extensive testing, and changes which were "not ready for prime time" would be rolled back or made solid. I've had enough trouble with some recent snapshots of -STABLE that I'd rather install a release that's been thoroughly tested... preferably with the latest ports. That's why I'm asking about the likely actual release date of 7.1. --Brett From delphij at delphij.net Sun Jul 20 03:40:03 2008 From: delphij at delphij.net (Xin LI) Date: Sun Jul 20 03:40:10 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <200807200321.VAA17553@lariat.net> References: <200807200230.UAA17164@lariat.net> <4882AAC1.6010501@delphij.net> <200807200321.VAA17553@lariat.net> Message-ID: <4882B389.7050806@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brett Glass wrote: | I'd like to install a fully tested 7.1-RELEASE, rather than | a snapshot of 7-STABLE (in which there have, apparently, been | some problems due to driver updates and work on the TCP stack). If you presently installed FreeBSD 7.0-RELEASE, you can use the new binary update approach -- freebsd-update to patch it, which contains only security/stability fixes. Another way is to upgrade to RELENG_7_0, which will give you 7.0-RELEASE-p3 at this moment, it's the same as binary upgrade approach but useful if you did some customization in compiling. | Alas, I haven't seen any schedule or "to do" list for the release | process yet -- just a note saying that 7.1-RELEASE is scheduled | for August. | | I'm sure that a lot of folks are in the same boat as I: they'd | like to start with a complete release that doesn't need patching | and recompiling. | | --Brett Glass | | At 09:02 PM 7/19/2008, Xin LI wrote: | |> Yes. FreeBSD 7-STABLE and RELENG_7_0 errata branches are already |> patched and not vulnerable to the problem. |> |> Cheers, |> - -- |> Xin LI http://www.delphij.net/ | | _______________________________________________ | freebsd-stable@freebsd.org mailing list | http://lists.freebsd.org/mailman/listinfo/freebsd-stable | To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkiCs4kACgkQi+vbBBjt66CJ+gCgrJzqiUGVgELB6wcEl/lDJCKa N6sAnRYNl25Lxdd/YNuT/H9vSIN+DRAf =sjpM -----END PGP SIGNATURE----- From subhro.kar at gmail.com Sun Jul 20 03:44:13 2008 From: subhro.kar at gmail.com (Subhro) Date: Sun Jul 20 03:44:20 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <200807200321.VAA17553@lariat.net> References: <200807200230.UAA17164@lariat.net> <4882AAC1.6010501@delphij.net> <200807200321.VAA17553@lariat.net> Message-ID: Brett, You need to understand the release engineering process of FreeeBSD. The release edition is essential created from the stabe edition. 7.1R would not be something new which is *not* present on 7-STABLE today. In addition, while a particular branch is alive (not declared as end of life) all security updates are backported. The fix which you are looking for is also present on 7.0-R so you may well install that. Thanks Subhro On Sun, Jul 20, 2008 at 8:50 AM, Brett Glass wrote: > I'd like to install a fully tested 7.1-RELEASE, rather than > a snapshot of 7-STABLE (in which there have, apparently, been > some problems due to driver updates and work on the TCP stack). > > Alas, I haven't seen any schedule or "to do" list for the release > process yet -- just a note saying that 7.1-RELEASE is scheduled > for August. > > I'm sure that a lot of folks are in the same boat as I: they'd > like to start with a complete release that doesn't need patching > and recompiling. > > --Brett Glass > > At 09:02 PM 7/19/2008, Xin LI wrote: > >>Yes. FreeBSD 7-STABLE and RELENG_7_0 errata branches are already >>patched and not vulnerable to the problem. >> >>Cheers, >>- -- >>Xin LI http://www.delphij.net/ > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Subhro Kar Software Engineer Dynamic Digital Technologies Pvt. Ltd. EPY-3, Sector: V Salt Lake City 700091 India From edwin at mavetju.org Sun Jul 20 04:40:35 2008 From: edwin at mavetju.org (Edwin Groothuis) Date: Sun Jul 20 04:40:42 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <200807200336.VAA17727@lariat.net> References: <200807200230.UAA17164@lariat.net> <4882AAC1.6010501@delphij.net> <200807200321.VAA17553@lariat.net> <200807200336.VAA17727@lariat.net> Message-ID: <20080720042209.GA3928@k7.mavetju> On Sat, Jul 19, 2008 at 09:36:38PM -0600, Brett Glass wrote: > At 09:28 PM 7/19/2008, Subhro wrote: > > >You need to understand the release engineering process of FreeeBSD. > > I've been watching it (and testing release candidates) since 2.x, so > I think I may possibly have some understanding of it by now. ;-) > > >The release edition is essential created from the stabe edition. 7.1R > >would not be something new which is *not* present on 7-STABLE today. > > Mostly true. But the new release would undergo extensive testing, and > changes which were "not ready for prime time" would be rolled back or > made solid. I've had enough trouble with some recent snapshots of > -STABLE that I'd rather install a release that's been thoroughly > tested... preferably with the latest ports. That's why I'm asking > about the likely actual release date of 7.1. The best thing a looking glass can come up with is: http://www.freebsd.org/releng/#schedule But that unless an announcement that as much worth as the lifetime of the electrons hitting the back of your eyes. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From unga888 at yahoo.com Sun Jul 20 05:19:50 2008 From: unga888 at yahoo.com (Unga) Date: Sun Jul 20 05:19:58 2008 Subject: Pseudoterminals increase: compilation error In-Reply-To: <545719.90429.qm@web57010.mail.re3.yahoo.com> Message-ID: <451954.40252.qm@web57008.mail.re3.yahoo.com> --- On Sun, 7/20/08, Unga wrote: > From: Unga > Subject: Re: Pseudoterminals increase: compilation error > To: "Dan Nelson" > Cc: freebsd-stable@freebsd.org > Date: Sunday, July 20, 2008, 10:44 AM > --- On Sun, 7/20/08, Dan Nelson > wrote: > > > Expect's error message doesn't say anything > except > > "something isn't > > working but I won't tell you what". Run > > > > truss -o truss.log -f expect -c "spawn ls" > > > > and determine which syscall is failing, with what > error > > number, just > > before expect prints its "no more ptys" > message. > > That will tell you > > whether it's a permissions issue, or something > else. > > If there are no > > obvious errors, post a part of the log. > > > > Also, what version of expect are you running? > Versions > > between > > 5.38.0_1 and 5.43.0_2 had a bug in the port Makefile > that > > limited the > > number of ptys expect could see. See > > http://www.freebsd.org/cgi/query-pr.cgi?pr=108311 . > > > > Here are more detail. In fact, I noted it through strace > after my previous email. > > ls -l /dev/ | grep pty > crw-rw-rw- 1 root wheel 0, 169 Jul 20 10:11 ptyp0 > crw-rw-rw- 1 root wheel 0, 171 Jul 20 10:22 ptyp1 > > truss -o truss.log -f expect -c "spawn ls" > > 1178: open("/dev/ptyp0",O_RDWR,027757763030) > ERR#5 'Input/output error' > 1178: open("/dev/ptyp1",O_RDWR,027757763030) > ERR#5 'Input/output error' > 1178: open("/dev/ptyp2",O_RDWR,027757763030) > = 5 (0x5) > 1178: fstat(5,{mode=crw-rw-rw- > ,inode=178,size=0,blksize=4096}) = 0 (0x0) > : > : > 1178: chown("/dev/ttyp2",1002,4) > ERR#1 'Operation not permitted' > 1178: close(5) = 0 (0x0) > 1178: close(-1) ERR#9 > 'Bad file descriptor' > 1178: close(-1) ERR#9 > 'Bad file descriptor' > 1178: open("/",O_RDONLY,027757764430) > = 5 (0x5) > 1178: close(5) = 0 (0x0) > 1178: write(2,"The system has no more ptys. > As"...,106) = 106 (0x6a) > 1178: write(2,"\r\n",2) > = 1179 (0x49b) > = 2 (0x2) > > ls -l /dev/ | grep pty > crw-rw-rw- 1 root wheel 0, 169 Jul 20 10:11 ptyp0 > crw-rw-rw- 1 root wheel 0, 171 Jul 20 10:23 ptyp1 > crw-rw-rw- 1 root wheel 0, 178 Jul 20 10:11 ptyp2 > > I'm using Expect-5.43.0 compiled from sources. > > So, it looks like some sort of a misconfiguration. Still > investigating. > Here is a more narrow down. This problem is happening inside a chroot jail but only as a normal user: Here is what it create for following command: expect -c "spawn ls" On FreeBSD ========== crw--w---- 1 test tty 0, 181 Jul 20 10:11 ttyp3 On chroot ========= crw-rw-rw- 1 root wheel 0, 181 Jul 20 10:11 ttyp3 For some reason devfs creates ttys differently. "devfs rule showsets" shows same for both /dev and /path/dev. Its just 1, 2, 3, 4. I tried to add a new ruleset as follows (inside chroot jail): devfs ruleset 10 devfs rule add path tty* type tty mode 660 group tty devfs rule applyset Now devfs creates ttys as follows: crw-rw---- 1 root tty 0, 179 Jul 20 13:08 ttyp2 So, now the question is how to get the devfs to create ttys owned by the requested user? or can it be something else? As for Gavin's suggestion to upgrade to Expect-5.43.0_2, actually, there is no such version on http://expect.nist.gov/, latest is still Expect-5.43.0. Regards Unga From peterjeremy at optushome.com.au Sun Jul 20 10:37:15 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Sun Jul 20 10:37:22 2008 Subject: Pseudoterminals increase: compilation error In-Reply-To: <545719.90429.qm@web57010.mail.re3.yahoo.com> References: <20080719213056.GE19044@dan.emsphone.com> <545719.90429.qm@web57010.mail.re3.yahoo.com> Message-ID: <20080720103711.GG24076@server.vk2pj.dyndns.org> On 2008-Jul-19 19:44:18 -0700, Unga wrote: >truss -o truss.log -f expect -c "spawn ls" > > 1178: open("/dev/ptyp0",O_RDWR,027757763030) ERR#5 'Input/output error' > 1178: open("/dev/ptyp1",O_RDWR,027757763030) ERR#5 'Input/output error' > 1178: open("/dev/ptyp2",O_RDWR,027757763030) = 5 (0x5) > 1178: fstat(5,{mode=crw-rw-rw- ,inode=178,size=0,blksize=4096}) = 0 (0x0) > : > : > 1178: chown("/dev/ttyp2",1002,4) ERR#1 'Operation not permitted' This is definitely wrong. expect should not be calling chown(2), it should be calling pt_chown. >I'm using Expect-5.43.0 compiled from sources. > >So, it looks like some sort of a misconfiguration. Still investigating. Have you built the FreeBSD port or used your own build configuration? If the latter, I suggest you build the port - it works for me. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080720/faaa9ffd/attachment.pgp From unga888 at yahoo.com Sun Jul 20 13:41:53 2008 From: unga888 at yahoo.com (Unga) Date: Sun Jul 20 13:41:59 2008 Subject: Pseudoterminals increase: compilation error In-Reply-To: <20080720103711.GG24076@server.vk2pj.dyndns.org> Message-ID: <490974.88404.qm@web57011.mail.re3.yahoo.com> --- On Sun, 7/20/08, Peter Jeremy wrote: > From: Peter Jeremy > Subject: Re: Pseudoterminals increase: compilation error > To: "Unga" > Cc: freebsd-stable@freebsd.org > Date: Sunday, July 20, 2008, 6:37 PM > On 2008-Jul-19 19:44:18 -0700, Unga > wrote: > >truss -o truss.log -f expect -c "spawn ls" > > > > 1178: open("/dev/ptyp0",O_RDWR,027757763030) > ERR#5 'Input/output error' > > 1178: open("/dev/ptyp1",O_RDWR,027757763030) > ERR#5 'Input/output error' > > 1178: open("/dev/ptyp2",O_RDWR,027757763030) > = 5 (0x5) > > 1178: fstat(5,{mode=crw-rw-rw- > ,inode=178,size=0,blksize=4096}) = 0 (0x0) > > : > > : > > 1178: chown("/dev/ttyp2",1002,4) > ERR#1 'Operation not permitted' > > This is definitely wrong. expect should not be calling > chown(2), > it should be calling pt_chown. > Hmm...that's a good point. I'll check that. > >I'm using Expect-5.43.0 compiled from sources. > > > >So, it looks like some sort of a misconfiguration. > Still investigating. > > Have you built the FreeBSD port or used your own build > configuration? > If the latter, I suggest you build the port - it works for > me. > Yes, I build my own build configuration. Anyway, I'll check what are the patches applied by the FreeBSD port. Unga From oberman at es.net Sun Jul 20 16:44:32 2008 From: oberman at es.net (Kevin Oberman) Date: Sun Jul 20 16:44:39 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: Your message of "Sun, 20 Jul 2008 14:22:09 +1000." <20080720042209.GA3928@k7.mavetju> Message-ID: <20080720164432.01C024500E@ptavv.es.net> > Date: Sun, 20 Jul 2008 14:22:09 +1000 > From: Edwin Groothuis > Sender: owner-freebsd-stable@freebsd.org > > On Sat, Jul 19, 2008 at 09:36:38PM -0600, Brett Glass wrote: > > At 09:28 PM 7/19/2008, Subhro wrote: > > > > >You need to understand the release engineering process of FreeeBSD. > > > > I've been watching it (and testing release candidates) since 2.x, so > > I think I may possibly have some understanding of it by now. ;-) > > > > >The release edition is essential created from the stabe edition. 7.1R > > >would not be something new which is *not* present on 7-STABLE today. > > > > Mostly true. But the new release would undergo extensive testing, and > > changes which were "not ready for prime time" would be rolled back or > > made solid. I've had enough trouble with some recent snapshots of > > -STABLE that I'd rather install a release that's been thoroughly > > tested... preferably with the latest ports. That's why I'm asking > > about the likely actual release date of 7.1. > > The best thing a looking glass can come up with is: > > http://www.freebsd.org/releng/#schedule > > But that unless an announcement that as much worth as the lifetime > of the electrons hitting the back of your eyes. I think we might have a communications issue. If I am wrong, sorry for the waste of bandwidth, First, 7.1 will not be out before Black Hat where the details of the vulnerability will be discussed publicly, so scratch that. Second, RELENG_7_0 has the patch plus two other security patches. IT IS NOT STABLE! It is 7.0 with exactly three important security patches and nothing else. While I find stable to be more stable and generally far better tested than release versions, I understand th preference many have for release versions. You have three options: 1. Upgrade to STABLE 2. Apply the patch to your existing system 3. Upgrade to RELENG_7_0 Of these, 2 is generally the easiest. 3 is probably the closest you can get to what you want, but pulls in two other security patches (which you probably should have installed, anyway) and 1 is probably the best approach in terms of system stability, but it does make a great many changes and it is probably not the best choice for a production environment where careful testing would be needed before deployment. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080720/839f50e6/attachment.pgp From cliftonr at lava.net Sun Jul 20 18:16:08 2008 From: cliftonr at lava.net (Clifton Royston) Date: Sun Jul 20 18:16:16 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <200807200230.UAA17164@lariat.net> References: <200807200230.UAA17164@lariat.net> Message-ID: <20080720181554.GA5405@lava.net> On Sat, Jul 19, 2008 at 08:30:57PM -0600, Brett Glass wrote: > Everyone: > > Will FreeBSD 7.1 be released in time to use it as an upgrade to > close the BIND cache poisoning hole? We'd like to upgrade affected > servers to the latest FreeBSD at the same time that we upgrade > BIND if possible. Given that 7.1 and 6.4 are still listed as "August" in the RE page, and things often slip a bit as the date approaches, I'd say you'd be well-advised not to wait. Assuming you're running 7.0 or 6.3, upgrade to the latest _RELENG patch which is much less work than a full version upgrade. My opinion only. I'm not a developer, and I'm not running any recursive resolvers on BIND these days; my limited set of machines are running djbdns instead, so I have more flexibility. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From subhro.kar at gmail.com Sun Jul 20 18:25:00 2008 From: subhro.kar at gmail.com (Subhro) Date: Sun Jul 20 18:25:06 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <20080720181554.GA5405@lava.net> References: <200807200230.UAA17164@lariat.net> <20080720181554.GA5405@lava.net> Message-ID: Cilton, Off topic, but could you please tell me (us) the advantages(and disadvantages) of djbdns over bind? Thanks Subhro On Sun, Jul 20, 2008 at 11:45 PM, Clifton Royston wrote: > On Sat, Jul 19, 2008 at 08:30:57PM -0600, Brett Glass wrote: >> Everyone: >> >> Will FreeBSD 7.1 be released in time to use it as an upgrade to >> close the BIND cache poisoning hole? We'd like to upgrade affected >> servers to the latest FreeBSD at the same time that we upgrade >> BIND if possible. > > Given that 7.1 and 6.4 are still listed as "August" in the RE page, > and things often slip a bit as the date approaches, I'd say you'd be > well-advised not to wait. Assuming you're running 7.0 or 6.3, upgrade > to the latest _RELENG patch which is much less work than a full version > upgrade. > > My opinion only. I'm not a developer, and I'm not running any > recursive resolvers on BIND these days; my limited set of machines are > running djbdns instead, so I have more flexibility. > > -- Clifton > > -- > Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net > President - I and I Computing * http://www.iandicomputing.com/ > Custom programming, network design, systems and network consulting services > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Subhro Kar Software Engineer Dynamic Digital Technologies Pvt. Ltd. EPY-3, Sector: V Salt Lake City 700091 India From gpalmer at freebsd.org Sun Jul 20 18:31:11 2008 From: gpalmer at freebsd.org (Gary Palmer) Date: Sun Jul 20 18:31:21 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <20080720164432.01C024500E@ptavv.es.net> References: <20080720042209.GA3928@k7.mavetju> <20080720164432.01C024500E@ptavv.es.net> Message-ID: <20080720183106.GA26333@in-addr.com> On Sun, Jul 20, 2008 at 09:44:31AM -0700, Kevin Oberman wrote: [ snip ] > Second, RELENG_7_0 has the patch plus two other security patches. IT IS > NOT STABLE! It is 7.0 with exactly three important security patches and > nothing else. [ snip ] I believe the second sentence could be better written as IT IS NOT -STABLE! which is an important difference ;) Regards, Gary From daniel_k_eriksson at telia.com Sun Jul 20 22:29:57 2008 From: daniel_k_eriksson at telia.com (Daniel Eriksson) Date: Sun Jul 20 22:30:04 2008 Subject: Panic on ZFS startup after crash In-Reply-To: <20080719221813.GC4733@garage.freebsd.pl> References: <4F9C9299A10AE74E89EA580D14AA10A61A197A@royal64.emp.zapto.org> <20080719221813.GC4733@garage.freebsd.pl> Message-ID: <4F9C9299A10AE74E89EA580D14AA10A61A197E@royal64.emp.zapto.org> Pawel Jakub Dawidek wrote: > Can you try this patch? > > http://people.freebsd.org/~pjd/patches/space_map.c.patch Now it panics (solaris assert) at line 431 in dmu.c. I'll try to get a backtrace in a day or two if it would help. Any other suggestions Pawel? ___ Daniel Eriksson (http://www.toomuchdata.com/) From unga888 at yahoo.com Mon Jul 21 05:11:25 2008 From: unga888 at yahoo.com (Unga) Date: Mon Jul 21 05:11:33 2008 Subject: Pseudoterminals increase: compilation error [SOLVED] In-Reply-To: <20080720103711.GG24076@server.vk2pj.dyndns.org> Message-ID: <223782.94918.qm@web57004.mail.re3.yahoo.com> --- On Sun, 7/20/08, Peter Jeremy wrote: > From: Peter Jeremy > Subject: Re: Pseudoterminals increase: compilation error > To: "Unga" > Cc: freebsd-stable@freebsd.org > Date: Sunday, July 20, 2008, 6:37 PM > On 2008-Jul-19 19:44:18 -0700, Unga > wrote: > >truss -o truss.log -f expect -c "spawn ls" > > > > 1178: open("/dev/ptyp0",O_RDWR,027757763030) > ERR#5 'Input/output error' > > 1178: open("/dev/ptyp1",O_RDWR,027757763030) > ERR#5 'Input/output error' > > 1178: open("/dev/ptyp2",O_RDWR,027757763030) > = 5 (0x5) > > 1178: fstat(5,{mode=crw-rw-rw- > ,inode=178,size=0,blksize=4096}) = 0 (0x0) > > : > > : > > 1178: chown("/dev/ttyp2",1002,4) > ERR#1 'Operation not permitted' > > This is definitely wrong. expect should not be calling > chown(2), > it should be calling pt_chown. > Yep, it was pt_chown was missing. Fixed the issue. Now ttyp* are created with correct ownerships. A big thank specially to Peter Jeremy and all others who helped me to solve this. Best regards Unga From pjd at FreeBSD.org Mon Jul 21 09:02:40 2008 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Mon Jul 21 09:02:49 2008 Subject: Panic on ZFS startup after crash In-Reply-To: <4F9C9299A10AE74E89EA580D14AA10A61A197E@royal64.emp.zapto.org> References: <4F9C9299A10AE74E89EA580D14AA10A61A197A@royal64.emp.zapto.org> <20080719221813.GC4733@garage.freebsd.pl> <4F9C9299A10AE74E89EA580D14AA10A61A197E@royal64.emp.zapto.org> Message-ID: <20080721090235.GA2953@garage.freebsd.pl> On Mon, Jul 21, 2008 at 12:29:54AM +0200, Daniel Eriksson wrote: > Pawel Jakub Dawidek wrote: > > > Can you try this patch? > > > > http://people.freebsd.org/~pjd/patches/space_map.c.patch > > Now it panics (solaris assert) at line 431 in dmu.c. I'll try to get a > backtrace in a day or two if it would help. The backtrace won't help here. I'm afraid your pool's metadata is somehow corrupted that ZFS can't handle that. I saw warnings in your first e-mail about ZFS not beeing able to replay ZIL. Can you try disabling ZIL? Something like: # zpool export # kldunload zfs # kenv vfs.zfs.zil_disable=1 # kldload zfs # zpool import Although I'm not sure if disabling ZIL will prevent replaying previously prepared ZIL. If that won't help, I'm afraid the last suggestion I can provide is to try the lastest ZFS version (I can prepare a patch for you in a few days). The panic you're seeing is in dmu_write() function. You could also try to import a pool read-only, but I just tried doing so with 'zpool import -o ro ' command and it mount file systems read-write. Not sure why it doesn't work, but I'll try to fix it today. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080721/341b3fe5/attachment.pgp From pjd at FreeBSD.org Mon Jul 21 09:51:01 2008 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Mon Jul 21 09:51:10 2008 Subject: Panic on ZFS startup after crash In-Reply-To: <20080721090235.GA2953@garage.freebsd.pl> References: <4F9C9299A10AE74E89EA580D14AA10A61A197A@royal64.emp.zapto.org> <20080719221813.GC4733@garage.freebsd.pl> <4F9C9299A10AE74E89EA580D14AA10A61A197E@royal64.emp.zapto.org> <20080721090235.GA2953@garage.freebsd.pl> Message-ID: <20080721095100.GB2953@garage.freebsd.pl> On Mon, Jul 21, 2008 at 11:02:36AM +0200, Pawel Jakub Dawidek wrote: > On Mon, Jul 21, 2008 at 12:29:54AM +0200, Daniel Eriksson wrote: > > Pawel Jakub Dawidek wrote: > > > > > Can you try this patch? > > > > > > http://people.freebsd.org/~pjd/patches/space_map.c.patch > > > > Now it panics (solaris assert) at line 431 in dmu.c. I'll try to get a > > backtrace in a day or two if it would help. > > The backtrace won't help here. I'm afraid your pool's metadata is > somehow corrupted that ZFS can't handle that. I saw warnings in your > first e-mail about ZFS not beeing able to replay ZIL. Can you try > disabling ZIL? Something like: > > # zpool export > # kldunload zfs > # kenv vfs.zfs.zil_disable=1 > # kldload zfs > # zpool import > > Although I'm not sure if disabling ZIL will prevent replaying previously > prepared ZIL. If that won't help, I'm afraid the last suggestion I can > provide is to try the lastest ZFS version (I can prepare a patch for you > in a few days). > > The panic you're seeing is in dmu_write() function. You could also try > to import a pool read-only, but I just tried doing so with > 'zpool import -o ro ' command and it mount file systems > read-write. Not sure why it doesn't work, but I'll try to fix it today. I fixed 'zpool import -o ro' problem in HEAD, but you can also patch your 7.0 sources with this patch: http://people.freebsd.org/~pjd/patches/opensolaris_vfs.c.2.patch With this patch applied and ZIL disabled, try to: # zpool import -o ro -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080721/6e05a955/attachment.pgp From oleg at opentransfer.com Mon Jul 21 10:07:54 2008 From: oleg at opentransfer.com (Oleg V. Nauman) Date: Mon Jul 21 10:08:03 2008 Subject: ACPI regression on recent 7.0-STABLE: HPET stops working In-Reply-To: <20080719111838.il32fec2880wok4g@webmail.opentransfer.com> References: <20080719100315.2td4dl2q5ck88wkw@webmail.opentransfer.com> <20080719080212.GA89036@eos.sc1.parodius.com> <20080719111838.il32fec2880wok4g@webmail.opentransfer.com> Message-ID: <20080721130752.pstwcwkz88wso8cs@webmail.opentransfer.com> Quoting "Oleg V. Nauman" : > Quoting Jeremy Chadwick : > >> On Sat, Jul 19, 2008 at 10:03:15AM +0300, Oleg V. Nauman wrote: >>> It seems to be something was changed with ACPI support on 7.0-STABLE so >>> my next system upgrade ended with ACPI HPET not working anymore on my >>> ASUS A9Rp laptop. >>> >>> Here is the part of /var/log/dmesg.today dated July 13: >>> >>> FreeBSD 7.0-STABLE #65: Tue Jul 8 22:05:07 EEST 2008 >>> root@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2 >>> [..] >>> acpi0: on motherboard >>> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 >>> acpi0: [ITHREAD] >>> acpi0: Power Button (fixed) >>> acpi0: reservation of 0, a0000 (3) failed >>> acpi0: reservation of 100000, 77f00000 (3) failed >>> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 >>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 >>> acpi_ec0: port 0x62,0x66 on acpi0 >>> acpi_hpet0: iomem >>> 0xfed00000-0xfed003ff on acpi0 >>> Timecounter "HPET" frequency 14318180 Hz quality 900 >>> >>> Here is the fresh dmesg output info: >>> >>> FreeBSD 7.0-STABLE #66: Tue Jul 15 22:11:27 EEST 2008 >>> root@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2 >>> [..] >>> acpi0: on motherboard >>> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 >>> acpi0: [ITHREAD] >>> acpi0: Power Button (fixed) >>> acpi0: reservation of 0, a0000 (3) failed >>> acpi0: reservation of 100000, 77f00000 (3) failed >>> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 >>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 >>> [..] >>> acpi_hpet0: iomem >>> 0xfed00000-0xfed003ff on acpi0 >>> device_attach: acpi_hpet0 attach returned 12 >>> >>> And the part of actual sysctl kern.timecounter output: >>> >>> kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) dummy(-1000000) >>> kern.timecounter.hardware: ACPI-safe >> >> Seems okay here: >> >> FreeBSD icarus.home.lan 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat Jul >> 12 10:53:08 PDT 2008 >> root@icarus.home.lan:/usr/obj/usr/src/sys/PDSMI_PLUS_amd64 amd64 >> >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 >> acpi_hpet0: iomem >> 0xfed00000-0xfed003ff on acpi0 >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >> Timecounter "HPET" frequency 14318180 Hz quality 900 >> Timecounters tick every 1.000 msec >> >> kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) >> i8254(0) dummy(-1000000) >> kern.timecounter.hardware: ACPI-fast >> >> You sure you haven't upgraded your BIOS or something and forgot to >> re-enable HPET? > > No it was not upgraded.. Have no option to enable/disable HPET through > BIOS settings though I was unclear a bit or so. There are no ACPI related settings in my laptop's BIOS. Well.. Backout 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c (committed to RELENG_7 at July 10 by jhb) fixes this issue for me: acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 kern.timecounter.choice: TSC(800) HPET(900) ACPI-safe(850) i8254(0) dummy(-1000000) kern.timecounter.hardware: HPET Hopefully it helps to understand what is went wrong there. Oleg > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From koitsu at FreeBSD.org Mon Jul 21 10:46:48 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Jul 21 10:46:55 2008 Subject: ACPI regression on recent 7.0-STABLE: HPET stops working In-Reply-To: <20080721130752.pstwcwkz88wso8cs@webmail.opentransfer.com> References: <20080719100315.2td4dl2q5ck88wkw@webmail.opentransfer.com> <20080719080212.GA89036@eos.sc1.parodius.com> <20080719111838.il32fec2880wok4g@webmail.opentransfer.com> <20080721130752.pstwcwkz88wso8cs@webmail.opentransfer.com> Message-ID: <20080721104648.GA29700@eos.sc1.parodius.com> On Mon, Jul 21, 2008 at 01:07:52PM +0300, Oleg V. Nauman wrote: > Well.. Backout 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c > (committed to RELENG_7 at July 10 by jhb) fixes this issue for me: > > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 900 > > kern.timecounter.choice: TSC(800) HPET(900) ACPI-safe(850) i8254(0) > dummy(-1000000) > kern.timecounter.hardware: HPET > > Hopefully it helps to understand what is went wrong there. John, do you have any ideas WRT this regression? HPET on this user's system has the most granularity. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From petefrench at ticketswitch.com Mon Jul 21 11:08:39 2008 From: petefrench at ticketswitch.com (Pete French) Date: Mon Jul 21 11:09:43 2008 Subject: Multi-machine mirroring choices In-Reply-To: <1216304215.14562.19.camel@lanshark.dmv.com> Message-ID: > The *big* issue I have right now is dealing with the slave machine going > down. Once the master no longer has a connection to the ggated devices, > all processes trying to use the device hang in D status. I have tried > pkill'ing ggatec to no avail and ggatec destroy returns a message of > gctl being busy. Trying to ggatec destroy -f panics the machine. Oddly enough, this was the issue I had with iscsi which made me move to using ggated instead. On our machines I use '-t 10' as an argument to ggatec, and this makes it timeout once the connection has been down for a certain amount of time. I am using gmirror on top, not ZFS, and this handled the drive vanishing from the mirror quite happily. I haven't tried it with ZFS, which may not like having the device suddenly dissapear. -pete. From kkutzko at teksavvy.com Mon Jul 21 12:27:25 2008 From: kkutzko at teksavvy.com (Kevin K) Date: Mon Jul 21 12:27:32 2008 Subject: HP Pavilion dv2000 laptop wont boot off install cd In-Reply-To: <20080717170601.b7f1f9ad.torfinn.ingolfsen@broadpark.no> References: <200807161353.m6GDrDFB058142@lurza.secnetix.de> <009301c8e797$1385e880$3a91b980$@com> <00b301c8e806$eeb3d5b0$cc1b8110$@com> <00b401c8e809$0ed63c50$2c82b4f0$@com> <20080717170601.b7f1f9ad.torfinn.ingolfsen@broadpark.no> Message-ID: <005301c8eb2d$113598c0$33a0ca40$@com> > On Thu, 17 Jul 2008 08:31:37 -0400 > Kevin K wrote: > > > For 7.0-RELEASE, it > > seemed to hang at "Trying to mount root from ufs:/dev/md0". > > How long did you wait? If you didn't wait 10 or 15 minutes, please do. > Various tests / probes take a long time to time out on some hardware. > > HTH > -- > Regards, > Torfinn Ingolfsen I tried the 7.0-release-amd64 200807 snapshot and it booted (after holding the spacebar @ /boot/loader.conf). It stopped at Trying to mount root from ufs:/dev/md0". I waited about 30-45 minutes and it didn't continue from that point -- the keyboard was also unresponsive. Does anyone know if this is a known issue? From daniel_k_eriksson at telia.com Mon Jul 21 13:49:27 2008 From: daniel_k_eriksson at telia.com (Daniel Eriksson) Date: Mon Jul 21 13:49:34 2008 Subject: Panic on ZFS startup after crash In-Reply-To: <20080721090235.GA2953@garage.freebsd.pl> References: <4F9C9299A10AE74E89EA580D14AA10A61A197A@royal64.emp.zapto.org> <20080719221813.GC4733@garage.freebsd.pl> <4F9C9299A10AE74E89EA580D14AA10A61A197E@royal64.emp.zapto.org> <20080721090235.GA2953@garage.freebsd.pl> Message-ID: <4F9C9299A10AE74E89EA580D14AA10A61A197F@royal64.emp.zapto.org> Pawel Jakub Dawidek wrote: > I'm afraid your pool's metadata is > somehow corrupted that ZFS can't handle that. Yes, that's my conclusion also. It looks like the intent log is messed up enough to trigger an assert while ZFS tries to parse/replay it. > I saw warnings in your > first e-mail about ZFS not beeing able to replay ZIL. Can you try > disabling ZIL? Something like: I've already tried this, and it made no difference. When the box crashed ZIL was enabled, and for some reason garbage got written into the ZIL. Now whenever ZFS tries to import the pool it sees a non-empty ZIL and tries to parse/replay it. Is there an easy way to trick ZFS into thinking the ZIL is empty? > Although I'm not sure if disabling ZIL will prevent replaying > previously prepared ZIL. It won't unfortunately. > If that won't help, I'm afraid the last suggestion I can > provide is to try the lastest ZFS version (I can prepare a > patch for you in a few days). I could probably prepare a temporary install of 8-CURRENT on a spare drive and boot from that if it's easier for you to make a patch against CURRENT instead of RELENG_7_0. > You could also try > to import a pool read-only, but I just tried doing so with > 'zpool import -o ro ' command and it mount file systems > read-write. Not sure why it doesn't work, but I'll try to fix > it today. I'll try that! ___ Daniel Eriksson (http://www.toomuchdata.com/) From pjd at FreeBSD.org Mon Jul 21 13:52:00 2008 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Mon Jul 21 13:52:07 2008 Subject: Panic on ZFS startup after crash In-Reply-To: <4F9C9299A10AE74E89EA580D14AA10A61A197F@royal64.emp.zapto.org> References: <4F9C9299A10AE74E89EA580D14AA10A61A197A@royal64.emp.zapto.org> <20080719221813.GC4733@garage.freebsd.pl> <4F9C9299A10AE74E89EA580D14AA10A61A197E@royal64.emp.zapto.org> <20080721090235.GA2953@garage.freebsd.pl> <4F9C9299A10AE74E89EA580D14AA10A61A197F@royal64.emp.zapto.org> Message-ID: <20080721135156.GA6310@garage.freebsd.pl> On Mon, Jul 21, 2008 at 03:49:24PM +0200, Daniel Eriksson wrote: > Pawel Jakub Dawidek wrote: > > > I'm afraid your pool's metadata is > > somehow corrupted that ZFS can't handle that. > > Yes, that's my conclusion also. It looks like the intent log is messed > up enough to trigger an assert while ZFS tries to parse/replay it. > > > I saw warnings in your > > first e-mail about ZFS not beeing able to replay ZIL. Can you try > > disabling ZIL? Something like: > > I've already tried this, and it made no difference. When the box crashed > ZIL was enabled, and for some reason garbage got written into the ZIL. > Now whenever ZFS tries to import the pool it sees a non-empty ZIL and > tries to parse/replay it. > > Is there an easy way to trick ZFS into thinking the ZIL is empty? I'll check that. > > If that won't help, I'm afraid the last suggestion I can > > provide is to try the lastest ZFS version (I can prepare a > > patch for you in a few days). > > I could probably prepare a temporary install of 8-CURRENT on a spare > drive and boot from that if it's easier for you to make a patch against > CURRENT instead of RELENG_7_0. The ZFS code in 7.0 is the same as in HEAD, so no worries. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080721/3c403200/attachment.pgp From pjd at FreeBSD.org Mon Jul 21 14:28:02 2008 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Mon Jul 21 14:28:21 2008 Subject: Panic on ZFS startup after crash In-Reply-To: <20080721135156.GA6310@garage.freebsd.pl> References: <4F9C9299A10AE74E89EA580D14AA10A61A197A@royal64.emp.zapto.org> <20080719221813.GC4733@garage.freebsd.pl> <4F9C9299A10AE74E89EA580D14AA10A61A197E@royal64.emp.zapto.org> <20080721090235.GA2953@garage.freebsd.pl> <4F9C9299A10AE74E89EA580D14AA10A61A197F@royal64.emp.zapto.org> <20080721135156.GA6310@garage.freebsd.pl> Message-ID: <20080721142800.GB6310@garage.freebsd.pl> On Mon, Jul 21, 2008 at 03:51:56PM +0200, Pawel Jakub Dawidek wrote: > On Mon, Jul 21, 2008 at 03:49:24PM +0200, Daniel Eriksson wrote: > > Pawel Jakub Dawidek wrote: > > > > > I'm afraid your pool's metadata is > > > somehow corrupted that ZFS can't handle that. > > > > Yes, that's my conclusion also. It looks like the intent log is messed > > up enough to trigger an assert while ZFS tries to parse/replay it. > > > > > I saw warnings in your > > > first e-mail about ZFS not beeing able to replay ZIL. Can you try > > > disabling ZIL? Something like: > > > > I've already tried this, and it made no difference. When the box crashed > > ZIL was enabled, and for some reason garbage got written into the ZIL. > > Now whenever ZFS tries to import the pool it sees a non-empty ZIL and > > tries to parse/replay it. > > > > Is there an easy way to trick ZFS into thinking the ZIL is empty? > > I'll check that. Ok. We may try not to replay the ZIL, but leave it there and see what will happen. We can also try to destroy the ZIL without replaying it. What we do from now on can mess up your pool even further, so you may want to backup entire disks if you want. To skip replaying the ZIL you need to edit /sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c file, find zil_replay() function and make the head of it looks like this: void zil_replay(objset_t *os, void *arg, uint64_t *txgp, zil_replay_func_t *replay_func[TX_MAX_TYPE]) { zilog_t *zilog = dmu_objset_zil(os); const zil_header_t *zh = zilog->zl_header; zil_replay_arg_t zr; /* XXX: Try to skip the ZIL replay. */ return; if (zil_empty(zilog)) { zil_destroy(zilog, B_TRUE); return; } [...] If that won't work, we can try to destroy the ZIL without replaying it: void zil_replay(objset_t *os, void *arg, uint64_t *txgp, zil_replay_func_t *replay_func[TX_MAX_TYPE]) { zilog_t *zilog = dmu_objset_zil(os); const zil_header_t *zh = zilog->zl_header; zil_replay_arg_t zr; /* XXX: Destroy the ZIL without replaying it. */ zil_destroy(zilog, B_FALSE); return; if (zil_empty(zilog)) { zil_destroy(zilog, B_TRUE); return; } [...] -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080721/eedd1850/attachment.pgp From sven at dmv.com Mon Jul 21 15:23:59 2008 From: sven at dmv.com (Sven W) Date: Mon Jul 21 15:24:06 2008 Subject: Multi-machine mirroring choices In-Reply-To: References: Message-ID: <4884AA04.7000404@dmv.com> Pete French presumably uttered the following on 07/21/08 07:08: >> The *big* issue I have right now is dealing with the slave machine going >> down. Once the master no longer has a connection to the ggated devices, >> all processes trying to use the device hang in D status. I have tried >> pkill'ing ggatec to no avail and ggatec destroy returns a message of >> gctl being busy. Trying to ggatec destroy -f panics the machine. > > Oddly enough, this was the issue I had with iscsi which made me move > to using ggated instead. On our machines I use '-t 10' as an argument to > ggatec, and this makes it timeout once the connection has been down for > a certain amount of time. I am using gmirror on top, not ZFS, and this > handled the drive vanishing from the mirror quite happily. I haven't > tried it with ZFS, which may not like having the device suddenly dissapear. > > -pete. What I have found is that the master machine will lock up if the slave disappears during a large file transfer. I tested this by setting up zpool mirror on the master using a ggatec device from the slave. Then I: pkill'ed ggated on the slave machine. dd if=/dev/zero of=/data1/testfile2 bs=16k count=8192 [128MB] on the master The dd command finished and the /var/log/messages showed I/O errors to the slave drive as expected. Messages also showed ggatec trying to reconnect every 10 seconds (ggatec was started with the -t 10 parameter). Finally zfs marked the drive unavailable which then allowed me to ggatec destroy -u 0 without getting the "ioctl(/dev/ggctl): Device busy" error message. (By the way, using ggatec destroy does not kill the "ggatec create" that created the process to begin with, I had to pkill ggatec to get that stop - bug?) The above behavior would be acceptable for multi-machine mirroring as it would be scriptable. The problem comes with Large writes. I tried to repeat the above with dd if=/dev/zero of=/data1/testfile2 bs=16k count=32768 [512MB] which then locks zfs, and ultimately the system itself. It seems once the write size/buffer is full, zfs is unable to fail/unavail the slave drive and the entire system becomes unresponsive (cannot even ssh into it). The bottom line is that without some type of "timeout" or "time to fail" (bad I/O to fail?) zpool + ggate[cd] seems to be an unworkable solution. This is actually a shame as the recover process swapping from master to slave and back again was so much cleaner and faster than using gmirror. Sven From unixmania at gmail.com Mon Jul 21 15:51:14 2008 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Mon Jul 21 15:51:21 2008 Subject: HP Pavilion dv2000 laptop wont boot off install cd In-Reply-To: <005301c8eb2d$113598c0$33a0ca40$@com> References: <200807161353.m6GDrDFB058142@lurza.secnetix.de> <009301c8e797$1385e880$3a91b980$@com> <00b301c8e806$eeb3d5b0$cc1b8110$@com> <00b401c8e809$0ed63c50$2c82b4f0$@com> <20080717170601.b7f1f9ad.torfinn.ingolfsen@broadpark.no> <005301c8eb2d$113598c0$33a0ca40$@com> Message-ID: On Mon, Jul 21, 2008 at 9:26 AM, Kevin K wrote: >> On Thu, 17 Jul 2008 08:31:37 -0400 >> Kevin K wrote: >> >> > For 7.0-RELEASE, it >> > seemed to hang at "Trying to mount root from ufs:/dev/md0". >> >> How long did you wait? If you didn't wait 10 or 15 minutes, please do. >> Various tests / probes take a long time to time out on some hardware. >> >> HTH >> -- >> Regards, >> Torfinn Ingolfsen > > > I tried the 7.0-release-amd64 200807 snapshot and it booted (after holding > the spacebar @ /boot/loader.conf). I have seen this on some HP notebooks. It seems that the CD drive does not to stabilize on time before booting, leading to some disk read errors. The trick is to press F9 (or F12, depending on the notebook model) to force the BIOS to show the boot device menu. Then, *after the CD drive stop spinning*, choose the boot from CD/DVD option. > It stopped at Trying to mount root from > ufs:/dev/md0". I waited about 30-45 minutes and it didn't continue from that > point -- the keyboard was also unresponsive. > > Does anyone know if this is a known issue? Try to disable kbdmux before booting. Jump to the loader prompt and type: set hint.kbdmux.0.disabled=1 boot -v -- If you think things can't get worse it's probably only because you lack sufficient imagination. From dougb at FreeBSD.org Mon Jul 21 19:14:28 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Jul 21 19:14:34 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <200807200230.UAA17164@lariat.net> References: <200807200230.UAA17164@lariat.net> Message-ID: <4884E00E.1090009@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Brett Glass wrote: | Everyone: | | Will FreeBSD 7.1 be released in time to use it as an upgrade to | close the BIND cache poisoning hole? Brett, et al, I'll make this simple for you. If you have a server that is running BIND, update BIND now. If you need to use the ports, that's fine, just do it now. Make sure that you are not specifying a port via any query-source* options in named.conf, and that any firewall between your named process and the outside world does keep-state on outgoing UDP packets. If you have a system with BIND installed (as it is by default) but you are NOT running named, you don't need to worry about updating now, but you should do it "soonish" just in case someone gets a wild hair and starts up named on that box. As for the meta-question, FreeBSD is currently operating on a time-based release schedule, not a feature-based one. And to your actual question, the answer is no. hope this helps, Doug - -- ~ This .signature sanitized for your protection -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEAREDAAYFAkiE4A0ACgkQyIakK9Wy8PtSWACeN+lmId1jdMF9zGt3v905XEgy bT8AoJtmWCWRjyXSktaeJ6IHiwJas7Fk =vtRp -----END PGP SIGNATURE----- From max at love2party.net Mon Jul 21 19:51:23 2008 From: max at love2party.net (Max Laier) Date: Mon Jul 21 19:51:39 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <4884E00E.1090009@FreeBSD.org> References: <200807200230.UAA17164@lariat.net> <4884E00E.1090009@FreeBSD.org> Message-ID: <200807212138.46703.max@love2party.net> On Monday 21 July 2008 21:14:22 Doug Barton wrote: > Brett Glass wrote: > | Everyone: > | > | Will FreeBSD 7.1 be released in time to use it as an upgrade to > | close the BIND cache poisoning hole? > > Brett, et al, > > I'll make this simple for you. If you have a server that is running > BIND, update BIND now. If you need to use the ports, that's fine, just > do it now. Make sure that you are not specifying a port via any > query-source* options in named.conf, and that any firewall between > your named process and the outside world does keep-state on outgoing > UDP packets. ... and that any NAT device employs at least a somewhat random port allocation mechanism - pf provides this. > If you have a system with BIND installed (as it is by default) but you > are NOT running named, you don't need to worry about updating now, but > you should do it "soonish" just in case someone gets a wild hair and > starts up named on that box. > > As for the meta-question, FreeBSD is currently operating on a > time-based release schedule, not a feature-based one. And to your > actual question, the answer is no. > > > hope this helps, > > Doug -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From max at love2party.net Mon Jul 21 19:51:24 2008 From: max at love2party.net (Max Laier) Date: Mon Jul 21 19:51:41 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <4884E00E.1090009@FreeBSD.org> References: <200807200230.UAA17164@lariat.net> <4884E00E.1090009@FreeBSD.org> Message-ID: <200807212138.46703.max@love2party.net> On Monday 21 July 2008 21:14:22 Doug Barton wrote: > Brett Glass wrote: > | Everyone: > | > | Will FreeBSD 7.1 be released in time to use it as an upgrade to > | close the BIND cache poisoning hole? > > Brett, et al, > > I'll make this simple for you. If you have a server that is running > BIND, update BIND now. If you need to use the ports, that's fine, just > do it now. Make sure that you are not specifying a port via any > query-source* options in named.conf, and that any firewall between > your named process and the outside world does keep-state on outgoing > UDP packets. ... and that any NAT device employs at least a somewhat random port allocation mechanism - pf provides this. > If you have a system with BIND installed (as it is by default) but you > are NOT running named, you don't need to worry about updating now, but > you should do it "soonish" just in case someone gets a wild hair and > starts up named on that box. > > As for the meta-question, FreeBSD is currently operating on a > time-based release schedule, not a feature-based one. And to your > actual question, the answer is no. > > > hope this helps, > > Doug -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From oberman at es.net Mon Jul 21 20:34:54 2008 From: oberman at es.net (Kevin Oberman) Date: Mon Jul 21 20:35:07 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: Your message of "Mon, 21 Jul 2008 21:38:46 +0200." <200807212138.46703.max@love2party.net> Message-ID: <20080721202418.7CF9B4500E@ptavv.es.net> > From: Max Laier > Date: Mon, 21 Jul 2008 21:38:46 +0200 > Sender: owner-freebsd-stable@freebsd.org > > On Monday 21 July 2008 21:14:22 Doug Barton wrote: > > Brett Glass wrote: > > | Everyone: > > | > > | Will FreeBSD 7.1 be released in time to use it as an upgrade to > > | close the BIND cache poisoning hole? > > > > Brett, et al, > > > > I'll make this simple for you. If you have a server that is running > > BIND, update BIND now. If you need to use the ports, that's fine, just > > do it now. Make sure that you are not specifying a port via any > > query-source* options in named.conf, and that any firewall between > > your named process and the outside world does keep-state on outgoing > > UDP packets. > > ... and that any NAT device employs at least a somewhat random port > allocation mechanism - pf provides this. And, if you are not sure how good a job it does (and I am not), you should use the OARC test to check how well it works: dig +short porttest.dns-oarc.net TXT If the result is not "GOOD", it's not good enough. You can test a remote server by adding "@remote-server" to the dig command. The server may be specified by name or IP address. Don't forget that ANY server that caches data, including an end system running a caching only server is vulnerable. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080721/66e5bb28/attachment.pgp From oberman at es.net Mon Jul 21 20:34:54 2008 From: oberman at es.net (Kevin Oberman) Date: Mon Jul 21 20:35:09 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: Your message of "Mon, 21 Jul 2008 21:38:46 +0200." <200807212138.46703.max@love2party.net> Message-ID: <20080721202418.7CF9B4500E@ptavv.es.net> > From: Max Laier > Date: Mon, 21 Jul 2008 21:38:46 +0200 > Sender: owner-freebsd-stable@freebsd.org > > On Monday 21 July 2008 21:14:22 Doug Barton wrote: > > Brett Glass wrote: > > | Everyone: > > | > > | Will FreeBSD 7.1 be released in time to use it as an upgrade to > > | close the BIND cache poisoning hole? > > > > Brett, et al, > > > > I'll make this simple for you. If you have a server that is running > > BIND, update BIND now. If you need to use the ports, that's fine, just > > do it now. Make sure that you are not specifying a port via any > > query-source* options in named.conf, and that any firewall between > > your named process and the outside world does keep-state on outgoing > > UDP packets. > > ... and that any NAT device employs at least a somewhat random port > allocation mechanism - pf provides this. And, if you are not sure how good a job it does (and I am not), you should use the OARC test to check how well it works: dig +short porttest.dns-oarc.net TXT If the result is not "GOOD", it's not good enough. You can test a remote server by adding "@remote-server" to the dig command. The server may be specified by name or IP address. Don't forget that ANY server that caches data, including an end system running a caching only server is vulnerable. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080721/66e5bb28/attachment-0001.pgp From jhb at freebsd.org Mon Jul 21 20:56:26 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Jul 21 20:56:43 2008 Subject: ACPI regression on recent 7.0-STABLE: HPET stops working In-Reply-To: <20080721104648.GA29700@eos.sc1.parodius.com> References: <20080719100315.2td4dl2q5ck88wkw@webmail.opentransfer.com> <20080721130752.pstwcwkz88wso8cs@webmail.opentransfer.com> <20080721104648.GA29700@eos.sc1.parodius.com> Message-ID: <200807211148.46704.jhb@freebsd.org> On Monday 21 July 2008 06:46:48 am Jeremy Chadwick wrote: > On Mon, Jul 21, 2008 at 01:07:52PM +0300, Oleg V. Nauman wrote: > > Well.. Backout 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c > > (committed to RELENG_7 at July 10 by jhb) fixes this issue for me: > > > > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > > Timecounter "HPET" frequency 14318180 Hz quality 900 > > > > kern.timecounter.choice: TSC(800) HPET(900) ACPI-safe(850) i8254(0) > > dummy(-1000000) > > kern.timecounter.hardware: HPET > > > > Hopefully it helps to understand what is went wrong there. > > John, do you have any ideas WRT this regression? HPET on this user's > system has the most granularity. ENOCONTEXT. I will try to find the thread in my stable@ inbox, but right now I can't tell anything from just this e-mail. -- John Baldwin From hostmaster at netconsonance.com Mon Jul 21 21:17:38 2008 From: hostmaster at netconsonance.com (Jo Rhett) Date: Mon Jul 21 21:17:46 2008 Subject: chipset causing locks. In-Reply-To: References: <20080711164939.GA10238@lava.net> Message-ID: Thanks for the note. No, just a coincidence. The chipset is a VIA ProSavageDDR KM266. But thanks for bringing that up ;-) FWIW, as others have speculated enabling more logging from GEOM produced nothing. It does appear to be a hardware failure of some sort. On Jul 18, 2008, at 11:29 PM, Peter Wemm wrote: > On Wed, Jul 16, 2008 at 2:42 PM, Jo Rhett > wrote: >>> On Fri, Jul 11, 2008 at 12:59:33AM -0700, Jo Rhett wrote: >>>> >>>> Every time it is rebuilding ad0. Every single boot in the last >>>> two >>>> weeks. >> >> On Jul 11, 2008, at 9:49 AM, Clifton Royston wrote: >>> >>> That just means that it halted without a proper shutdown. If it >>> crashes, the mirror isn't stopped properly, so it's marked dirty, >>> so it >>> must rebuild it. It is the precise analogy of finding all the file >>> systems dirty on boot and fscking them, following a crash. >> >> >> Thanks for the clarification. Dang, I hoped I was on to something. > > This is really off on a tangent, but I thought I'd mention it on the > off-chance that it fit your problem. > > Recently there have been grumblings about heat problems with certain > nvidia chipsets on consumer boards. Apparently, there is some process > issue, if you believe trade rags like theinquirer.net etc. Apparently > there is some issue with heat damage over time. Consumer motherboards > with passive cooled (no fan) heat pipes etc seem to be particularly > vulnerable. I use the word "apparently" because it is far from a > verified fact. > > However, I've got two motherboards, one running freebsd, one running > windows, with nvidia chipsets. Both used to be fine with onboard IDE > activity. Both now use raid controllers so the IDE interfaces have > been idle for a good year or so. > > Something came up and I had to use the IDE interfaces for a lot of > data transfer. Suddenly, both machines are flakey. The windows > machine blue screens under load. My freebsd box just "turns off" > (motherboard appears to power off, but the power supply is on still). > The same happens when I use a linux boot disk, so I know its not > FreeBSD's fault. > > The common factor seems to be that the motherboards are now about a > year and a half old. They both have the same nvidia south bridge that > theinquirer.net was trashing. Both used to work fine, now have > problems with IDE. and now I recalled the article and started > wondering... > > Do you, by any wildly remote chance, have an nvidia based motherboard? > > I believe the fault I'm seeing is the system asserting a fatal error > by doing a HT ECC flood to halt everything. > > -- > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; > KI6FJV > "All of this is for nothing if we don't go to the stars" - JMS/B5 > "If Java had true garbage collection, most programs would delete > themselves upon execution." -- Robert Sewell -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From matheus at eternamente.info Mon Jul 21 21:18:19 2008 From: matheus at eternamente.info (Nenhum_de_Nos) Date: Mon Jul 21 21:18:28 2008 Subject: Panic on ZFS startup after crash In-Reply-To: <20080721135156.GA6310@garage.freebsd.pl> References: <4F9C9299A10AE74E89EA580D14AA10A61A197A@royal64.emp.zapto.org> <20080719221813.GC4733@garage.freebsd.pl> <4F9C9299A10AE74E89EA580D14AA10A61A197E@royal64.emp.zapto.org> <20080721090235.GA2953@garage.freebsd.pl> <4F9C9299A10AE74E89EA580D14AA10A61A197F@royal64.emp.zapto.org> <20080721135156.GA6310@garage.freebsd.pl> Message-ID: <1cb3959e4dbda185cbba0150f4884413.squirrel@cygnus.homeunix.com> > The ZFS code in 7.0 is the same as in HEAD, so no worries. I'm trying zfs myself in a small enviroment at home, but for that I do follow 7-STABLE. there's no need to do that, as based in the above statement ? thanks, matheus -- We will call you cygnus, The God of balance you shall be From jhb at freebsd.org Mon Jul 21 22:18:00 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Jul 21 22:18:12 2008 Subject: ACPI regression on recent 7.0-STABLE: HPET stops working In-Reply-To: <20080721130752.pstwcwkz88wso8cs@webmail.opentransfer.com> References: <20080719100315.2td4dl2q5ck88wkw@webmail.opentransfer.com> <20080719111838.il32fec2880wok4g@webmail.opentransfer.com> <20080721130752.pstwcwkz88wso8cs@webmail.opentransfer.com> Message-ID: <200807211800.12415.jhb@freebsd.org> On Monday 21 July 2008 06:07:52 am Oleg V. Nauman wrote: > Quoting "Oleg V. Nauman" : > > > Quoting Jeremy Chadwick : > > > >> On Sat, Jul 19, 2008 at 10:03:15AM +0300, Oleg V. Nauman wrote: > >>> It seems to be something was changed with ACPI support on 7.0-STABLE so > >>> my next system upgrade ended with ACPI HPET not working anymore on my > >>> ASUS A9Rp laptop. > >>> > >>> Here is the part of /var/log/dmesg.today dated July 13: > >>> > >>> FreeBSD 7.0-STABLE #65: Tue Jul 8 22:05:07 EEST 2008 > >>> root@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2 > >>> [..] > >>> acpi0: on motherboard > >>> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 > >>> acpi0: [ITHREAD] > >>> acpi0: Power Button (fixed) > >>> acpi0: reservation of 0, a0000 (3) failed > >>> acpi0: reservation of 100000, 77f00000 (3) failed > >>> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > >>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > >>> acpi_ec0: port 0x62,0x66 on acpi0 > >>> acpi_hpet0: iomem > >>> 0xfed00000-0xfed003ff on acpi0 > >>> Timecounter "HPET" frequency 14318180 Hz quality 900 > >>> > >>> Here is the fresh dmesg output info: > >>> > >>> FreeBSD 7.0-STABLE #66: Tue Jul 15 22:11:27 EEST 2008 > >>> root@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2 > >>> [..] > >>> acpi0: on motherboard > >>> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 > >>> acpi0: [ITHREAD] > >>> acpi0: Power Button (fixed) > >>> acpi0: reservation of 0, a0000 (3) failed > >>> acpi0: reservation of 100000, 77f00000 (3) failed > >>> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > >>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > >>> [..] > >>> acpi_hpet0: iomem > >>> 0xfed00000-0xfed003ff on acpi0 > >>> device_attach: acpi_hpet0 attach returned 12 > >>> > >>> And the part of actual sysctl kern.timecounter output: > >>> > >>> kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) dummy(-1000000) > >>> kern.timecounter.hardware: ACPI-safe > >> > >> Seems okay here: > >> > >> FreeBSD icarus.home.lan 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat Jul > >> 12 10:53:08 PDT 2008 > >> root@icarus.home.lan:/usr/obj/usr/src/sys/PDSMI_PLUS_amd64 amd64 > >> > >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > >> acpi_hpet0: iomem > >> 0xfed00000-0xfed003ff on acpi0 > >> Timecounter "i8254" frequency 1193182 Hz quality 0 > >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > >> Timecounter "HPET" frequency 14318180 Hz quality 900 > >> Timecounters tick every 1.000 msec > >> > >> kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) > >> i8254(0) dummy(-1000000) > >> kern.timecounter.hardware: ACPI-fast > >> > >> You sure you haven't upgraded your BIOS or something and forgot to > >> re-enable HPET? > > > > No it was not upgraded.. Have no option to enable/disable HPET through > > BIOS settings though > > I was unclear a bit or so. There are no ACPI related settings in my > laptop's BIOS. > > Well.. Backout 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c > (committed to RELENG_7 at July 10 by jhb) fixes this issue for me: > > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 900 > > kern.timecounter.choice: TSC(800) HPET(900) ACPI-safe(850) i8254(0) > dummy(-1000000) > kern.timecounter.hardware: HPET > > Hopefully it helps to understand what is went wrong there. Ok, so the attempt to allocate the resource is failing for some reason. Can you get output from 'devinfo -r' and 'devinfo -u'? -- John Baldwin From brett at lariat.net Mon Jul 21 22:20:05 2008 From: brett at lariat.net (Brett Glass) Date: Mon Jul 21 22:20:12 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <20080721202418.7CF9B4500E@ptavv.es.net> References: <20080721202418.7CF9B4500E@ptavv.es.net> Message-ID: <200807212219.QAA01486@lariat.net> At 02:24 PM 7/21/2008, Kevin Oberman wrote: >Don't forget that ANY server that caches data, including an end system >running a caching only server is vulnerable. Actually, there is an exception to this. A "forward only" cache/resolver is only as vulnerable as its forwarder(s). This is a workaround for the vulnerability for folks who have systems that they cannot easily upgrade: point at a trusted forwarder that's patched. We're also looking at using dnscache from the djbdns package. It's really idiosyncratic, but seems to work well -- and if you're just doing a caching resolver you don't have to touch it once you get it configured. Of course, all solutions that randomize ports are really just "security by obscurity," because by shuffling ports you're hiding the way to poison your cache... a little. --Brett Glass From spork at bway.net Mon Jul 21 22:31:55 2008 From: spork at bway.net (Charles Sprickman) Date: Mon Jul 21 22:32:03 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <20080721202418.7CF9B4500E@ptavv.es.net> References: <20080721202418.7CF9B4500E@ptavv.es.net> Message-ID: On Mon, 21 Jul 2008, Kevin Oberman wrote: >> From: Max Laier >> Date: Mon, 21 Jul 2008 21:38:46 +0200 >> Sender: owner-freebsd-stable@freebsd.org >> >> On Monday 21 July 2008 21:14:22 Doug Barton wrote: >>> Brett Glass wrote: >>> | Everyone: >>> | >>> | Will FreeBSD 7.1 be released in time to use it as an upgrade to >>> | close the BIND cache poisoning hole? >>> >>> Brett, et al, >>> >>> I'll make this simple for you. If you have a server that is running >>> BIND, update BIND now. If you need to use the ports, that's fine, just >>> do it now. Make sure that you are not specifying a port via any >>> query-source* options in named.conf, and that any firewall between >>> your named process and the outside world does keep-state on outgoing >>> UDP packets. >> >> ... and that any NAT device employs at least a somewhat random port >> allocation mechanism - pf provides this. > > And, if you are not sure how good a job it does (and I am not), you > should use the OARC test to check how well it works: > dig +short porttest.dns-oarc.net TXT > > If the result is not "GOOD", it's not good enough. I was playing around with this a bit. It seems like a patched server will give a standard deviation of more than 18,000. If I make some queries behind a one-to-many NAT using pf, it falls to somewhere around 6,000 (with a patched BIND - unpatched is pitiful). PF is not *adding* any randomness to unpatched servers. Since it has a (non-configurable?) range of ports it will grab when doing outbound NAT, the results are not as good as with no NAT intervention, but passable I suppose. Of course in a 1:1 NAT setup it is transparent. Charles > You can test a remote server by adding "@remote-server" to the dig > command. The server may be specified by name or IP address. > > Don't forget that ANY server that caches data, including an end system > running a caching only server is vulnerable. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman@es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > From brett at lariat.net Mon Jul 21 22:52:40 2008 From: brett at lariat.net (Brett Glass) Date: Mon Jul 21 22:52:48 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <20080721202418.7CF9B4500E@ptavv.es.net> References: <20080721202418.7CF9B4500E@ptavv.es.net> Message-ID: <200807212219.QAA01486@lariat.net> At 02:24 PM 7/21/2008, Kevin Oberman wrote: >Don't forget that ANY server that caches data, including an end system >running a caching only server is vulnerable. Actually, there is an exception to this. A "forward only" cache/resolver is only as vulnerable as its forwarder(s). This is a workaround for the vulnerability for folks who have systems that they cannot easily upgrade: point at a trusted forwarder that's patched. We're also looking at using dnscache from the djbdns package. It's really idiosyncratic, but seems to work well -- and if you're just doing a caching resolver you don't have to touch it once you get it configured. Of course, all solutions that randomize ports are really just "security by obscurity," because by shuffling ports you're hiding the way to poison your cache... a little. --Brett Glass From spork at bway.net Mon Jul 21 22:59:55 2008 From: spork at bway.net (Charles Sprickman) Date: Mon Jul 21 23:00:02 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <20080721202418.7CF9B4500E@ptavv.es.net> References: <20080721202418.7CF9B4500E@ptavv.es.net> Message-ID: On Mon, 21 Jul 2008, Kevin Oberman wrote: >> From: Max Laier >> Date: Mon, 21 Jul 2008 21:38:46 +0200 >> Sender: owner-freebsd-stable@freebsd.org >> >> On Monday 21 July 2008 21:14:22 Doug Barton wrote: >>> Brett Glass wrote: >>> | Everyone: >>> | >>> | Will FreeBSD 7.1 be released in time to use it as an upgrade to >>> | close the BIND cache poisoning hole? >>> >>> Brett, et al, >>> >>> I'll make this simple for you. If you have a server that is running >>> BIND, update BIND now. If you need to use the ports, that's fine, just >>> do it now. Make sure that you are not specifying a port via any >>> query-source* options in named.conf, and that any firewall between >>> your named process and the outside world does keep-state on outgoing >>> UDP packets. >> >> ... and that any NAT device employs at least a somewhat random port >> allocation mechanism - pf provides this. > > And, if you are not sure how good a job it does (and I am not), you > should use the OARC test to check how well it works: > dig +short porttest.dns-oarc.net TXT > > If the result is not "GOOD", it's not good enough. I was playing around with this a bit. It seems like a patched server will give a standard deviation of more than 18,000. If I make some queries behind a one-to-many NAT using pf, it falls to somewhere around 6,000 (with a patched BIND - unpatched is pitiful). PF is not *adding* any randomness to unpatched servers. Since it has a (non-configurable?) range of ports it will grab when doing outbound NAT, the results are not as good as with no NAT intervention, but passable I suppose. Of course in a 1:1 NAT setup it is transparent. Charles > You can test a remote server by adding "@remote-server" to the dig > command. The server may be specified by name or IP address. > > Don't forget that ANY server that caches data, including an end system > running a caching only server is vulnerable. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman@es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > From max at love2party.net Tue Jul 22 05:07:15 2008 From: max at love2party.net (Max Laier) Date: Tue Jul 22 05:07:23 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: References: <20080721202418.7CF9B4500E@ptavv.es.net> Message-ID: <200807220707.11870.max@love2party.net> On Tuesday 22 July 2008 00:31:53 Charles Sprickman wrote: > On Mon, 21 Jul 2008, Kevin Oberman wrote: > >> From: Max Laier > >> Date: Mon, 21 Jul 2008 21:38:46 +0200 > >> Sender: owner-freebsd-stable@freebsd.org > >> > >> On Monday 21 July 2008 21:14:22 Doug Barton wrote: > >>> Brett Glass wrote: > >>> | Everyone: > >>> | > >>> | Will FreeBSD 7.1 be released in time to use it as an upgrade to > >>> | close the BIND cache poisoning hole? > >>> > >>> Brett, et al, > >>> > >>> I'll make this simple for you. If you have a server that is running > >>> BIND, update BIND now. If you need to use the ports, that's fine, > >>> just do it now. Make sure that you are not specifying a port via > >>> any query-source* options in named.conf, and that any firewall > >>> between your named process and the outside world does keep-state on > >>> outgoing UDP packets. > >> > >> ... and that any NAT device employs at least a somewhat random port > >> allocation mechanism - pf provides this. > > > > And, if you are not sure how good a job it does (and I am not), you > > should use the OARC test to check how well it works: > > dig +short porttest.dns-oarc.net TXT > > > > If the result is not "GOOD", it's not good enough. > > I was playing around with this a bit. It seems like a patched server > will give a standard deviation of more than 18,000. If I make some > queries behind a one-to-many NAT using pf, it falls to somewhere around > 6,000 (with a patched BIND - unpatched is pitiful). While the standard deviation gives some *indication* about the randomness of the selection it is no real measurement for its quality. > PF is not *adding* any randomness to unpatched servers. Since it has a > (non-configurable?) range of ports it will grab when doing outbound > NAT, the results are not as good as with no NAT intervention, but > passable I suppose. You can configure the range on a per-NAT-rule basis, e.g.: nat on $ext_if inet from ! ($ext_if) to any -> ($ext_if) port 1024:65535 but you have to take care so that you don't collide with the ephemeral port range of the host itself. Obviously you can't do much about an unpatched bind as with UDP there is no notion of "connection" so pf (or any NAT device for that matter) has to keep the NAT binding open for "some time" and a quick sequence of queries to the same server will be sent out through the same port. So putting a NAT firewall in front of a DNS resolver is *NOT* a workaround! > Of course in a 1:1 NAT setup it is transparent. > > Charles > > > You can test a remote server by adding "@remote-server" to the dig > > command. The server may be specified by name or IP address. > > > > Don't forget that ANY server that caches data, including an end > > system running a caching only server is vulnerable. > > -- > > R. Kevin Oberman, Network Engineer > > Energy Sciences Network (ESnet) > > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > > E-mail: oberman@es.net Phone: +1 510 486-8634 > > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From pjd at FreeBSD.org Tue Jul 22 09:07:04 2008 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Tue Jul 22 09:07:15 2008 Subject: Panic on ZFS startup after crash In-Reply-To: <1cb3959e4dbda185cbba0150f4884413.squirrel@cygnus.homeunix.com> References: <4F9C9299A10AE74E89EA580D14AA10A61A197A@royal64.emp.zapto.org> <20080719221813.GC4733@garage.freebsd.pl> <4F9C9299A10AE74E89EA580D14AA10A61A197E@royal64.emp.zapto.org> <20080721090235.GA2953@garage.freebsd.pl> <4F9C9299A10AE74E89EA580D14AA10A61A197F@royal64.emp.zapto.org> <20080721135156.GA6310@garage.freebsd.pl> <1cb3959e4dbda185cbba0150f4884413.squirrel@cygnus.homeunix.com> Message-ID: <20080722090703.GD3241@garage.freebsd.pl> On Mon, Jul 21, 2008 at 06:18:10PM -0300, Nenhum_de_Nos wrote: > > The ZFS code in 7.0 is the same as in HEAD, so no worries. > > I'm trying zfs myself in a small enviroment at home, but for that I do > follow 7-STABLE. there's no need to do that, as based in the above > statement ? There might be some small differences, but the patches I provide here will apply to 7.0-RELEASE, 7-STABLE and 8-CURRENT. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080722/5c8ed40e/attachment.pgp From oleg at opentransfer.com Tue Jul 22 09:23:22 2008 From: oleg at opentransfer.com (Oleg V. Nauman) Date: Tue Jul 22 09:23:33 2008 Subject: ACPI regression on recent 7.0-STABLE: HPET stops working In-Reply-To: <200807211800.12415.jhb@freebsd.org> References: <20080719100315.2td4dl2q5ck88wkw@webmail.opentransfer.com> <20080719111838.il32fec2880wok4g@webmail.opentransfer.com> <20080721130752.pstwcwkz88wso8cs@webmail.opentransfer.com> <200807211800.12415.jhb@freebsd.org> Message-ID: <20080722113751.qp8znc0duswkgs8g@webmail.opentransfer.com> Quoting John Baldwin : > On Monday 21 July 2008 06:07:52 am Oleg V. Nauman wrote: >> Quoting "Oleg V. Nauman" : >> >> > Quoting Jeremy Chadwick : >> > >> >> On Sat, Jul 19, 2008 at 10:03:15AM +0300, Oleg V. Nauman wrote: >> >>> It seems to be something was changed with ACPI support on 7.0-STABLE so >> >>> my next system upgrade ended with ACPI HPET not working anymore on my >> >>> ASUS A9Rp laptop. >> >>> >> >>> Here is the part of /var/log/dmesg.today dated July 13: >> >>> >> >>> FreeBSD 7.0-STABLE #65: Tue Jul 8 22:05:07 EEST 2008 >> >>> root@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2 >> >>> [..] >> >>> acpi0: on motherboard >> >>> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 >> >>> acpi0: [ITHREAD] >> >>> acpi0: Power Button (fixed) >> >>> acpi0: reservation of 0, a0000 (3) failed >> >>> acpi0: reservation of 100000, 77f00000 (3) failed >> >>> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 >> >>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 >> >>> acpi_ec0: port 0x62,0x66 on acpi0 >> >>> acpi_hpet0: iomem >> >>> 0xfed00000-0xfed003ff on acpi0 >> >>> Timecounter "HPET" frequency 14318180 Hz quality 900 >> >>> >> >>> Here is the fresh dmesg output info: >> >>> >> >>> FreeBSD 7.0-STABLE #66: Tue Jul 15 22:11:27 EEST 2008 >> >>> root@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2 >> >>> [..] >> >>> acpi0: on motherboard >> >>> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 >> >>> acpi0: [ITHREAD] >> >>> acpi0: Power Button (fixed) >> >>> acpi0: reservation of 0, a0000 (3) failed >> >>> acpi0: reservation of 100000, 77f00000 (3) failed >> >>> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 >> >>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 >> >>> [..] >> >>> acpi_hpet0: iomem >> >>> 0xfed00000-0xfed003ff on acpi0 >> >>> device_attach: acpi_hpet0 attach returned 12 >> >>> >> >>> And the part of actual sysctl kern.timecounter output: >> >>> >> >>> kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) > dummy(-1000000) >> >>> kern.timecounter.hardware: ACPI-safe >> >> >> >> Seems okay here: >> >> >> >> FreeBSD icarus.home.lan 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat Jul >> >> 12 10:53:08 PDT 2008 >> >> root@icarus.home.lan:/usr/obj/usr/src/sys/PDSMI_PLUS_amd64 amd64 >> >> >> >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 >> >> acpi_hpet0: iomem >> >> 0xfed00000-0xfed003ff on acpi0 >> >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >> >> Timecounter "HPET" frequency 14318180 Hz quality 900 >> >> Timecounters tick every 1.000 msec >> >> >> >> kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) >> >> i8254(0) dummy(-1000000) >> >> kern.timecounter.hardware: ACPI-fast >> >> >> >> You sure you haven't upgraded your BIOS or something and forgot to >> >> re-enable HPET? >> > >> > No it was not upgraded.. Have no option to enable/disable HPET through >> > BIOS settings though >> >> I was unclear a bit or so. There are no ACPI related settings in my >> laptop's BIOS. >> >> Well.. Backout 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c >> (committed to RELENG_7 at July 10 by jhb) fixes this issue for me: >> >> acpi_hpet0: iomem 0xfed00000-0xfed003ff on > acpi0 >> Timecounter "HPET" frequency 14318180 Hz quality 900 >> >> kern.timecounter.choice: TSC(800) HPET(900) ACPI-safe(850) i8254(0) >> dummy(-1000000) >> kern.timecounter.hardware: HPET >> >> Hopefully it helps to understand what is went wrong there. > > Ok, so the attempt to allocate the resource is failing for some reason. Can > you get output from 'devinfo -r' and 'devinfo -u'? Of course.. The kernel with 1.243.2.2 revision of /usr/src/sys/dev/acpica/acpi.c (so HPET working for me): devinfo -r output: nexus0 apic0 ram0 I/O memory addresses: 0x0-0x9efff 0x100000-0x77fcffff npx0 acpi0 Interrupt request lines: 21 I/O ports: 0x10-0x1f 0x22-0x3f 0x63 0x65 0x67-0x6f 0x72-0x7f 0x80 0x84-0x86 0x88 0x8c-0x8e 0x90-0x9f 0xa2-0xbf 0xe0-0xef 0x250-0x25f 0x40b 0x480-0x4bf 0x4d0-0x4d1 0x4d6 0x500-0x53f 0x800-0x89f 0x900-0x90f 0x910-0x91f 0xc00-0xc01 0xc14 0xc50-0xc51 0xc52 0xc6c 0xc6f 0xcd4-0xcd5 0xcd6-0xcd7 0xcd8-0xcdf 0x4000-0x4004 0x4005-0x40ff I/O memory addresses: 0xc0000-0xcffff 0xe0000-0xfffff 0xe0000000-0xefffffff 0xfec00000-0xfec00fff 0xfee00000-0xfee00fff 0xfff80000-0xffffffff cpu0 ACPI I/O ports: 0x814 0x815 coretemp0 p4tcc0 cpufreq0 pcib0 pci0 hostb0 pcib1 pci1 vgapci0 I/O ports: 0x9800-0x98ff I/O memory addresses: 0xc0000000-0xcfffffff 0xfe1f0000-0xfe1fffff ohci0 Interrupt request lines: 19 I/O memory addresses: 0xfebff000-0xfebfffff usb0 uhub0 ums0 ohci1 I/O memory addresses: 0xfebfe000-0xfebfefff usb1 uhub1 ehci0 I/O memory addresses: 0xfebfd000-0xfebfdfff usb2 uhub2 atapci0 I/O ports: 0x170-0x177 0x1f0-0x1f7 0x376 0x3f6 0xff00-0xff0f ata0 Interrupt request lines: 14 acd0 atapicam0 ata1 Interrupt request lines: 15 ad2 atapicam1 pcm0 Interrupt request lines: 16 I/O memory addresses: 0xfebf8000-0xfebfbfff isab0 isa0 sc0 vga0 I/O ports: 0x3c0-0x3df I/O memory addresses: 0xa0000-0xbffff orm0 ACPI I/O memory addresses: 0xc0000-0xccfff pmtimer0 pcib2 pci2 rl0 Interrupt request lines: 20 I/O ports: 0xb800-0xb8ff I/O memory addresses: 0xfeaffc00-0xfeaffcff miibus0 rlphy0 cbb0 I/O memory addresses: 0xfe200000-0xfe200fff cardbus0 pccard0 atpic0 atdma0 attimer0 attimer1 npxisa0 acpi_sysresource0 acpi_sysresource1 atkbdc0 I/O ports: 0x60 0x64 atkbd0 Interrupt request lines: 1 psmcpnp0 acpi_sysresource2 acpi_ec0 I/O ports: 0x62 0x66 acpi_lid0 acpi_sysresource3 acpi_acad0 battery0 acpi_sysresource4 pci_link0 pci_link1 pci_link2 pci_link3 pci_link4 pci_link5 pci_link6 pci_link7 acpi_button0 acpi_button1 acpi_tz0 acpi_timer0 ACPI I/O ports: 0x808-0x80b acpi_hpet0 I/O memory addresses: 0xfed00000-0xfed003ff devinfo -u output: Interrupt request lines: 0 (root0) 1 (atkbd0) 3-8 (root0) 10-13 (root0) 14 (ata0) 15 (ata1) 16 (pcm0) 17-18 (root0) 19 (ohci0) 20 (rl0) 21 (acpi0) 22-23 (root0) DMA request lines: 0-7 (root0) I/O ports: 0x0-0xf (root0) 0x10-0x1f (acpi0) 0x20-0x21 (root0) 0x22-0x3f (acpi0) 0x40-0x5f (root0) 0x60 (atkbdc0) 0x61 (root0) 0x62 (acpi_ec0) 0x63 (acpi0) 0x64 (atkbdc0) 0x65 (acpi0) 0x66 (acpi_ec0) 0x67-0x6f (acpi0) 0x70-0x71 (root0) 0x72-0x7f (acpi0) 0x80 (acpi0) 0x81-0x83 (root0) 0x84-0x86 (acpi0) 0x87 (root0) 0x88 (acpi0) 0x89-0x8b (root0) 0x8c-0x8e (acpi0) 0x8f (root0) 0x90-0x9f (acpi0) 0xa0-0xa1 (root0) 0xa2-0xbf (acpi0) 0xc0-0xdf (root0) 0xe0-0xef (acpi0) 0xf0-0x16f (root0) 0x170-0x177 (atapci0) 0x178-0x1ef (root0) 0x1f0-0x1f7 (atapci0) 0x1f8-0x24f (root0) 0x250-0x25f (acpi0) 0x260-0x375 (root0) 0x376 (atapci0) 0x377-0x3bf (root0) 0x3c0-0x3df (vga0) 0x3e0-0x3f5 (root0) 0x3f6 (atapci0) 0x3f7-0x40a (root0) 0x40b (acpi0) 0x40c-0x47f (root0) 0x480-0x4bf (acpi0) 0x4c0-0x4cf (root0) 0x4d0-0x4d1 (acpi0) 0x4d2-0x4d5 (root0) 0x4d6 (acpi0) 0x4d7-0x4ff (root0) 0x500-0x53f (acpi0) 0x540-0x7ff (root0) 0x800-0x89f (acpi0) 0x8a0-0x8ff (root0) 0x900-0x90f (acpi0) 0x910-0x91f (acpi0) 0x920-0xaff (root0) 0xb00-0xb0f (ichsmb0) 0xb10-0xbff (root0) 0xc00-0xc01 (acpi0) 0xc02-0xc13 (root0) 0xc14 (acpi0) 0xc15-0xc4f (root0) 0xc50-0xc51 (acpi0) 0xc52 (acpi0) 0xc53-0xc6b (root0) 0xc6c (acpi0) 0xc6d-0xc6e (root0) 0xc6f (acpi0) 0xc70-0xcd3 (root0) 0xcd4-0xcd5 (acpi0) 0xcd6-0xcd7 (acpi0) 0xcd8-0xcdf (acpi0) 0xce0-0x3fff (root0) 0x4000-0x4004 (acpi0) 0x4005-0x40ff (acpi0) 0x4100-0x97ff (root0) 0x9800-0x98ff (vgapci0) 0x9900-0xb7ff (root0) 0xb800-0xb8ff (rl0) 0xb900-0xfeff (root0) 0xff00-0xff0f (atapci0) 0xff10-0xffff (root0) I/O memory addresses: 0x0-0x9efff (ram0) 0x9f000-0x9ffff (root0) 0xa0000-0xbffff (vga0) 0xc0000-0xcffff (acpi0) 0xd0000-0xdffff (root0) 0xe0000-0xfffff (acpi0) 0x100000-0x77fcffff (ram0) 0x77fd0000-0xbfffffff (root0) 0xc0000000-0xcfffffff (vgapci0) 0xd0000000-0xdfffffff (root0) 0xe0000000-0xefffffff (acpi0) 0xf0000000-0xfe1effff (root0) 0xfe1f0000-0xfe1fffff (vgapci0) 0xfe200000-0xfe200fff (cbb0) 0xfe201000-0xfeaff3ff (root0) 0xfeaff400-0xfeaff4ff ---- 0xfeaff500-0xfeaff7ff (root0) 0xfeaff800-0xfeaff8ff ---- 0xfeaff900-0xfeaffbff (root0) 0xfeaffc00-0xfeaffcff (rl0) 0xfeaffd00-0xfebf7fff (root0) 0xfebf8000-0xfebfbfff (pcm0) 0xfebfc000-0xfebfcfff (root0) 0xfebfd000-0xfebfdfff (ehci0) 0xfebfe000-0xfebfefff (ohci1) 0xfebff000-0xfebfffff (ohci0) 0xfec00000-0xfec00fff (acpi0) 0xfec01000-0xfecfffff (root0) 0xfed00000-0xfed003ff (acpi_hpet0) 0xfed00400-0xfedfffff (root0) 0xfee00000-0xfee00fff (acpi0) 0xfee01000-0xfff7ffff (root0) 0xfff80000-0xffffffff (acpi0) ACPI I/O ports: 0x10-0x1f (root0) 0x22-0x3f (root0) 0x63 (root0) 0x65 (root0) 0x67-0x6f (root0) 0x72-0x80 (root0) 0x84-0x86 (root0) 0x88 (root0) 0x8c-0x8e (root0) 0x90-0x9f (root0) 0xa2-0xbf (root0) 0xe0-0xef (root0) 0x250-0x25f (root0) 0x40b (root0) 0x480-0x4bf (root0) 0x4d0-0x4d1 (root0) 0x4d6 (root0) 0x500-0x53f (root0) 0x800-0x807 (root0) 0x808-0x80b (acpi_timer0) 0x80c-0x813 (root0) 0x814 (cpu0) 0x815 (cpu0) 0x816-0x89f (root0) 0x900-0x91f (root0) 0xc00-0xc01 (root0) 0xc14 (root0) 0xc50-0xc52 (root0) 0xc6c (root0) 0xc6f (root0) 0xcd4-0xcdf (root0) 0x4000-0x40ff (root0) ACPI I/O memory addresses: 0xc0000-0xccfff (orm0) 0xcd000-0xcffff (root0) 0xe0000-0xfffff (root0) 0xe0000000-0xefffffff (root0) 0xfec00000-0xfec00fff (root0) 0xfee00000-0xfee00fff (root0) 0xfff80000-0xffffffff (root0) For the kernel with 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c ( so HPET is not working for me): Will not provide with full listings but just a diff comparing two states (this good one with HPET working and bad w/o it): rainhaven# diff devinfo.r.good devinfo.r.bad 177,179d176 < acpi_hpet0 < I/O memory addresses: < 0xfed00000-0xfed003ff rainhaven# diff devinfo.u.good devinfo.u.bad 128c128 < 0xfed00000-0xfed003ff (acpi_hpet0) --- > 0xfed00000-0xfed003ff (ichsmb0) So kernel with 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c allocates the region required to ichsmb0 instead HPET (it not helps to ichsmb0 because it never was working on my laptop but it is another story I think). Thank you for looking into. > > -- > John Baldwin > From mi+mill at aldan.algebra.com Tue Jul 22 15:12:40 2008 From: mi+mill at aldan.algebra.com (Mikhail Teterin) Date: Tue Jul 22 15:12:53 2008 Subject: "sleeping without queue" ? Message-ID: <4885F2A6.5020204@aldan.algebra.com> Hello! My attempt to build openoffice.org-3 seems to be hanging. Pressing Ctrl-T produces: load: 0.11 cmd: tcsh 79759 [sleeping without queue] 0.00u 0.00s 0% 0k (tcsh is used by OOo's build-script). What is this "sleeping without queue" state, and why is process in it for so long? This is an 4-CPU amd64 system with 4Gb of RAM. Only 16% of the swap is currently in use and the box seems to be perfectly fine otherwise. Uptime is 55 days, two different X-sessions are functional... The kernel is FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37. Thanks! -mi From kris at FreeBSD.org Tue Jul 22 15:29:43 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Tue Jul 22 15:29:49 2008 Subject: "sleeping without queue" ? In-Reply-To: <4885F2A6.5020204@aldan.algebra.com> References: <4885F2A6.5020204@aldan.algebra.com> Message-ID: <4885FCE5.1060507@FreeBSD.org> Mikhail Teterin wrote: > Hello! > > My attempt to build openoffice.org-3 seems to be hanging. Pressing > Ctrl-T produces: > > load: 0.11 cmd: tcsh 79759 [sleeping without queue] 0.00u 0.00s 0% 0k > > (tcsh is used by OOo's build-script). What is this "sleeping without > queue" state, and why is process in it for so long? > > This is an 4-CPU amd64 system with 4Gb of RAM. Only 16% of the swap is > currently in use and the box seems to be perfectly fine otherwise. > Uptime is 55 days, two different X-sessions are functional... The kernel > is FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37. > > Thanks! What is the process backtrace? Kris From olli at lurza.secnetix.de Tue Jul 22 15:52:45 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Tue Jul 22 15:52:52 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <200807212219.QAA01486@lariat.net> Message-ID: <200807221552.m6MFqgpm009488@lurza.secnetix.de> Brett Glass wrote: > At 02:24 PM 7/21/2008, Kevin Oberman wrote: > > > Don't forget that ANY server that caches data, including an end system > > running a caching only server is vulnerable. > > Actually, there is an exception to this. A "forward only" > cache/resolver is only as vulnerable as its forwarder(s). This is a > workaround for the vulnerability for folks who have systems that they > cannot easily upgrade: point at a trusted forwarder that's patched. > > We're also looking at using dnscache from the djbdns package. I'm curious, is djbdns exploitable, too? Does it randomize the source ports of UDP queries? > Of course, all solutions that randomize ports are really just > "security by obscurity," because by shuffling ports you're hiding the > way to poison your cache... a little. True, but there is currently no better solution, AFAIK. The problem is inherent in the way DNS queries work. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "That's what I love about GUIs: They make simple tasks easier, and complex tasks impossible." -- John William Chambless From cpghost at cordula.ws Tue Jul 22 16:05:47 2008 From: cpghost at cordula.ws (cpghost) Date: Tue Jul 22 16:05:54 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <200807221552.m6MFqgpm009488@lurza.secnetix.de> References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> Message-ID: <20080722160542.GA14592@epia-2.farid-hajji.net> On Tue, Jul 22, 2008 at 05:52:42PM +0200, Oliver Fromme wrote: > I'm curious, is djbdns exploitable, too? Does it randomize > the source ports of UDP queries? Apparently, djbdns had randomization of the source ports a long time ago... > > Of course, all solutions that randomize ports are really just > > "security by obscurity," because by shuffling ports you're hiding the > > way to poison your cache... a little. > > True, but there is currently no better solution, AFAIK. > The problem is inherent in the way DNS queries work. Yes indeed. If I understand all this correctly, it's because the transaction ID that has to be sent back is only 2 bytes long, and if the query port doesn't change as well with every query, that can be cracked in milliseconds: sending 65536 DNS queries to a constant port is just way too easy! The namespace is way too small, and there's no way to fix this by switching to, say, 4 bytes or even more for the transaction ID without breaking existing resolvers; actually without breaking the protocol itself. > Best regards > Oliver cpghost. -- Cordula's Web. http://www.cordula.ws/ From mi+mill at aldan.algebra.com Tue Jul 22 16:13:28 2008 From: mi+mill at aldan.algebra.com (Mikhail Teterin) Date: Tue Jul 22 16:13:35 2008 Subject: "sleeping without queue" ? In-Reply-To: <4885FCE5.1060507@FreeBSD.org> References: <4885F2A6.5020204@aldan.algebra.com> <4885FCE5.1060507@FreeBSD.org> Message-ID: <48860725.9050808@aldan.algebra.com> Kris Kennaway ???????(??): > Mikhail Teterin wrote: >> Hello! >> >> My attempt to build openoffice.org-3 seems to be hanging. Pressing >> Ctrl-T produces: >> >> load: 0.11 cmd: tcsh 79759 [sleeping without queue] 0.00u 0.00s >> 0% 0k >> >> (tcsh is used by OOo's build-script). What is this "sleeping without >> queue" state, and why is process in it for so long? >> >> This is an 4-CPU amd64 system with 4Gb of RAM. Only 16% of the swap >> is currently in use and the box seems to be perfectly fine otherwise. >> Uptime is 55 days, two different X-sessions are functional... The >> kernel is FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37. >> >> Thanks! > > What is the process backtrace? Hard to say... The process ID 79759. According to ps(1), that PID exists: 79759 p6 DE+ 0:00,00 /bin/tcsh -fc /meow/ports/editors/openoffice.org-3/work/BEB300_m3/solver/300/unxfbsdx.pro/bin/makedepend @/tmp/mk2WUYYi > ../../../unxfbsdx.pro/misc/s_addincol.dpcc According to gdb, it does not: gdb 79759 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...79759: No such file or directory. Interestingly, the file mentioned in the command-line -- the s_addincol.dpcc -- does not exist anywhere under /meow/ports/editors/openoffice.org-3/work -mi From ianjhart at ntlworld.com Tue Jul 22 16:17:17 2008 From: ianjhart at ntlworld.com (ian j hart) Date: Tue Jul 22 16:17:25 2008 Subject: unable to use gmirror on supermicro 5015b-mt Message-ID: <200807221659.20396.ianjhart@ntlworld.com> These are new boxes. http://www.supermicro.com/products/system/1U/5015/SYS-5015B-MT.cfm core 2 Q6600 CPU 8Gb 667 RAM Boxes were memtested from Fri-Mon okay. 6.3-RELEASE (amd64) installs fine. Build cycle okay. Running (no load) for a week or so. However, when I try to configure gmirror they hang on boot. After some fiddling it appears issuing #kldload geom_mirror hangs the boxes very hard. Ping response stops (after 3), no CAD response, CDROM draw doesn't open! This may well be a foolish thing to do but another (different) amd64 box doesn't hang. I don't believe this to be amd64 specific, I suspect that there's something strange about this hardware. There are very many BIOS options and I feel like I've tried them all without getting anywhere. I'm "on holiday" this week and I've borrowed a box to test. Any suggestions would be welcome. I'll (re)try anything but I need help to stay focused. Before you ask, no I cannot try 7.0-RELEASE, but that's a whole other thread (which may bear fruit more quickly). I already dropped the RAM to 2Gb and disabled the memory remap in the BIOS. dmesg after sig [AHCI disabled, SATA legacy mode] Thanks -- ian j hart %dmesg Copyright (c) 1992-2008 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.3-RELEASE #0: Wed Jan 16 01:43:02 UTC 2008 root@palmer.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (2394.02-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 4 real memory = 2145845248 (2046 MB) avail memory = 2059509760 (1964 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Jan 16 2008 01:41:13) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 uhci0: port 0x1820-0x183f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] usb0: 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: port 0x1840-0x185f irq 17 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] usb1: 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: port 0x1860-0x187f irq 18 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] usb2: 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 ehci0: mem 0xd8601000-0xd86013ff irq 18 at device 26.7 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: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered pcib3: irq 16 at device 28.0 on pci0 pci5: on pcib3 pcib4: irq 16 at device 28.4 on pci0 pci13: on pcib4 em0: port 0x2000-0x201f mem 0xd8000000-0xd801ffff irq 16 at device 0.0 on pci13 em0: Ethernet address: 00:30:48:64:22:fa pcib5: irq 17 at device 28.5 on pci0 pci15: on pcib5 em1: port 0x3000-0x301f mem 0xd8200000-0xd821ffff irq 17 at device 0.0 on pci15 em1: Ethernet address: 00:30:48:64:22:fb uhci3: port 0x1880-0x189f irq 23 at device 29.0 on pci0 uhci3: [GIANT-LOCKED] usb4: on uhci3 usb4: USB revision 1.0 uhub4: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub4: 2 ports with 2 removable, self powered uhci4: port 0x18a0-0x18bf irq 22 at device 29.1 on pci0 uhci4: [GIANT-LOCKED] usb5: on uhci4 usb5: USB revision 1.0 uhub5: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub5: 2 ports with 2 removable, self powered uhci5: port 0x18c0-0x18df irq 18 at device 29.2 on pci0 uhci5: [GIANT-LOCKED] usb6: on uhci5 usb6: USB revision 1.0 uhub6: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub6: 2 ports with 2 removable, self powered ehci1: mem 0xd8601400-0xd86017ff irq 23 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub7: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub7: 6 ports with 6 removable, self powered pcib6: at device 30.0 on pci0 pci17: on pcib6 pci17: at device 3.0 (no driver attached) atapci0: port 0x4420-0x4427,0x4414-0x4417,0x4418-0x441f,0x4410-0x4413,0x4400-0x440f irq 23 at device 4.0 on pci17 ata2: on atapci0 ata3: on atapci0 isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1c10-0x1c1f,0x1c00-0x1c0f at device 31.2 on pci0 ata0: on atapci1 ata1: on atapci1 pci0: at device 31.3 (no driver attached) atapci2: port 0x1c68-0x1c6f,0x1c5c-0x1c5f,0x1c60-0x1c67,0x1c58-0x1c5b,0x1c30-0x1c3f,0x1c20-0x1c2f irq 18 at device 31.5 on pci0 ata4: on atapci2 ata5: on atapci2 pci0: at device 31.6 (no driver attached) acpi_button0: on acpi0 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 VersaPad, device ID 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 orm0: at iomem 0xc0000-0xcafff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec hptrr: no controller detected. ad0: 305245MB at ata0-master SATA300 acd0: DVDROM at ata2-slave UDMA33 SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! Trying to mount root from ufs:/dev/ad0s1a From matheus at eternamente.info Tue Jul 22 16:17:40 2008 From: matheus at eternamente.info (Nenhum_de_Nos) Date: Tue Jul 22 16:17:47 2008 Subject: Panic on ZFS startup after crash In-Reply-To: <20080722090703.GD3241@garage.freebsd.pl> References: <4F9C9299A10AE74E89EA580D14AA10A61A197A@royal64.emp.zapto.org> <20080719221813.GC4733@garage.freebsd.pl> <4F9C9299A10AE74E89EA580D14AA10A61A197E@royal64.emp.zapto.org> <20080721090235.GA2953@garage.freebsd.pl> <4F9C9299A10AE74E89EA580D14AA10A61A197F@royal64.emp.zapto.org> <20080721135156.GA6310@garage.freebsd.pl> <1cb3959e4dbda185cbba0150f4884413.squirrel@cygnus.homeunix.com> <20080722090703.GD3241@garage.freebsd.pl> Message-ID: On Tue, July 22, 2008 06:07, Pawel Jakub Dawidek wrote: > On Mon, Jul 21, 2008 at 06:18:10PM -0300, Nenhum_de_Nos wrote: >> > The ZFS code in 7.0 is the same as in HEAD, so no worries. >> >> I'm trying zfs myself in a small enviroment at home, but for that I do >> follow 7-STABLE. there's no need to do that, as based in the above >> statement ? > > There might be some small differences, but the patches I provide here > will apply to 7.0-RELEASE, 7-STABLE and 8-CURRENT. > > -- > Pawel Jakub Dawidek http://www.wheel.pl > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! ok, but my main wonder was about to be using the most new but stable zfs code :) do I keep running stable ? thanks, matheus -- We will call you cygnus, The God of balance you shall be From koitsu at FreeBSD.org Tue Jul 22 16:19:58 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Jul 22 16:20:05 2008 Subject: "sleeping without queue" ? In-Reply-To: <48860725.9050808@aldan.algebra.com> References: <4885F2A6.5020204@aldan.algebra.com> <4885FCE5.1060507@FreeBSD.org> <48860725.9050808@aldan.algebra.com> Message-ID: <20080722161958.GA11139@eos.sc1.parodius.com> On Tue, Jul 22, 2008 at 12:13:25PM -0400, Mikhail Teterin wrote: > Kris Kennaway ???????(??): >> Mikhail Teterin wrote: >>> Hello! >>> >>> My attempt to build openoffice.org-3 seems to be hanging. Pressing >>> Ctrl-T produces: >>> >>> load: 0.11 cmd: tcsh 79759 [sleeping without queue] 0.00u 0.00s >>> 0% 0k >>> >>> (tcsh is used by OOo's build-script). What is this "sleeping without >>> queue" state, and why is process in it for so long? >>> >>> This is an 4-CPU amd64 system with 4Gb of RAM. Only 16% of the swap >>> is currently in use and the box seems to be perfectly fine otherwise. >>> Uptime is 55 days, two different X-sessions are functional... The >>> kernel is FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37. >>> >>> Thanks! >> >> What is the process backtrace? > Hard to say... The process ID 79759. According to ps(1), that PID exists: > 79759 p6 DE+ 0:00,00 /bin/tcsh -fc > /meow/ports/editors/openoffice.org-3/work/BEB300_m3/solver/300/unxfbsdx.pro/bin/makedepend > @/tmp/mk2WUYYi > ../../../unxfbsdx.pro/misc/s_addincol.dpcc > According to gdb, it does not: > gdb 79759 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"...79759: No such file > or directory. Syntax appears wrong; "gdb [program] 79759" would be what you want. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From cliftonr at lava.net Tue Jul 22 16:20:28 2008 From: cliftonr at lava.net (Clifton Royston) Date: Tue Jul 22 16:20:35 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <200807221552.m6MFqgpm009488@lurza.secnetix.de> References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> Message-ID: <20080722162024.GA1279@lava.net> On Tue, Jul 22, 2008 at 05:52:42PM +0200, Oliver Fromme wrote: > Brett Glass wrote: > > At 02:24 PM 7/21/2008, Kevin Oberman wrote: > > > > > Don't forget that ANY server that caches data, including an end system > > > running a caching only server is vulnerable. > > > > Actually, there is an exception to this. A "forward only" > > cache/resolver is only as vulnerable as its forwarder(s). This is a > > workaround for the vulnerability for folks who have systems that they > > cannot easily upgrade: point at a trusted forwarder that's patched. > > > > We're also looking at using dnscache from the djbdns package. > > I'm curious, is djbdns exploitable, too? Does it randomize > the source ports of UDP queries? AFAIK Dan Bernstein first spelled out the fundamental problems with DNS response forgery in 2001. He implemented dnscache to randomize source ports and IDs from the beginning, via a cryptographic quality RNG. See for instance this page, much of it written in 2003: He rubs a lot of people the wrong way, but I think he has usually proved to be right on security issues. I also think that modular design of security-sensitive tools is the way to go, with his DNS tools as with Postfix. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From mi+mill at aldan.algebra.com Tue Jul 22 16:22:43 2008 From: mi+mill at aldan.algebra.com (Mikhail Teterin) Date: Tue Jul 22 16:22:55 2008 Subject: "sleeping without queue" ? In-Reply-To: <20080722161958.GA11139@eos.sc1.parodius.com> References: <4885F2A6.5020204@aldan.algebra.com> <4885FCE5.1060507@FreeBSD.org> <48860725.9050808@aldan.algebra.com> <20080722161958.GA11139@eos.sc1.parodius.com> Message-ID: <4886094F.4020101@aldan.algebra.com> Jeremy Chadwick ???????(??): > On Tue, Jul 22, 2008 at 12:13:25PM -0400, Mikhail Teterin wrote: > >> Kris Kennaway ???????(??): >> >>> Mikhail Teterin wrote: >>> >>>> Hello! >>>> >>>> My attempt to build openoffice.org-3 seems to be hanging. Pressing >>>> Ctrl-T produces: >>>> >>>> load: 0.11 cmd: tcsh 79759 [sleeping without queue] 0.00u 0.00s >>>> 0% 0k >>>> >>>> (tcsh is used by OOo's build-script). What is this "sleeping without >>>> queue" state, and why is process in it for so long? >>>> >>>> This is an 4-CPU amd64 system with 4Gb of RAM. Only 16% of the swap >>>> is currently in use and the box seems to be perfectly fine otherwise. >>>> Uptime is 55 days, two different X-sessions are functional... The >>>> kernel is FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37. >>>> >>> What is the process backtrace? >>> >> Hard to say... The process ID 79759. According to ps(1), that PID exists: >> 79759 p6 DE+ 0:00,00 /bin/tcsh -fc >> /meow/ports/editors/openoffice.org-3/work/BEB300_m3/solver/300/unxfbsdx.pro/bin/makedepend >> @/tmp/mk2WUYYi > ../../../unxfbsdx.pro/misc/s_addincol.dpcc >> According to gdb, it does not: >> [...] > Syntax appears wrong; "gdb [program] 79759" would be what you want. > Yes, indeed. The result is similar, though: % gdb /bin/tcsh 79759 [...] Attaching to program: /bin/tcsh, process 79759 ptrace: No such process. /meow/ports/79759: No such file or directory. Thanks, -mi From ianjhart at ntlworld.com Tue Jul 22 16:27:58 2008 From: ianjhart at ntlworld.com (ian j hart) Date: Tue Jul 22 16:28:05 2008 Subject: unable to boot 7.0-RELEASE cdrom on supermicro 5015b-mt Message-ID: <200807221727.52718.ianjhart@ntlworld.com> Same hardware as my other thread. http://www.supermicro.com/products/system/1U/5015/SYS-5015B-MT.cfm [using 2Gb RAM and SATA in legacy mode] I'd like to focus only on making the CDROM boot complete. Summary: hangs just after the CPUs are launched. 6.2-RELEASE works okay, no AHCI support 6.3-RELEASE works okay 7.0-RELEASE hangs 7.0-STABLE-200806-SNAPSHOT hangs 8.0-CURRENT-200806-SNAPSHOT hangs I thought I could do a binary search using the current snapshot boot-only CDs but they only go back to March. Are there any older ones available? Thanks -- ian j hart From dougb at FreeBSD.org Tue Jul 22 16:37:17 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Jul 22 16:37:24 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <20080722162024.GA1279@lava.net> References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> <20080722162024.GA1279@lava.net> Message-ID: <48860CBA.6010903@FreeBSD.org> Clifton Royston wrote: > I also think that modular design of security-sensitive tools is the > way to go, with his DNS tools as with Postfix. Dan didn't write postfix, he wrote qmail. If you're interested in a resolver-only solution (and that is not a bad way to go) then you should evaluate dns/unbound. It is a lightweight resolver-only server that has a good security model and already implements query port randomization. It also has the advantage of being maintained, and compliant to 21st Century DNS standards including DNSSEC (which, btw, is the real solution to the response forgery problem, it just can't be deployed universally before 8/5). hth, Doug -- This .signature sanitized for your protection From koitsu at FreeBSD.org Tue Jul 22 16:37:24 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Jul 22 16:37:32 2008 Subject: unable to boot 7.0-RELEASE cdrom on supermicro 5015b-mt In-Reply-To: <200807221727.52718.ianjhart@ntlworld.com> References: <200807221727.52718.ianjhart@ntlworld.com> Message-ID: <20080722163724.GA11757@eos.sc1.parodius.com> On Tue, Jul 22, 2008 at 05:27:52PM +0100, ian j hart wrote: > Same hardware as my other thread. > http://www.supermicro.com/products/system/1U/5015/SYS-5015B-MT.cfm > > [using 2Gb RAM and SATA in legacy mode] > > I'd like to focus only on making the CDROM boot complete. > > Summary: hangs just after the CPUs are launched. > > 6.2-RELEASE works okay, no AHCI support > 6.3-RELEASE works okay > 7.0-RELEASE hangs > 7.0-STABLE-200806-SNAPSHOT hangs > 8.0-CURRENT-200806-SNAPSHOT hangs > > I thought I could do a binary search using the current snapshot boot-only CDs > but they only go back to March. Are there any older ones available? Have you tried disabling ACPI to see if it makes any sort of difference? Also, AHCI should work just fine on those systems -- I know because I have fairly extensive experience with Supermicro hardware, although what you're using is newer than what I presently have. I don't know why you're setting Compatible/Legacy mode on your controller (you mention doing this in your other thread as well). Below is what we use on our systems; factory defaults, then make the following changes. (The G-LAN1 OPROM option you can do whatever you want with -- it's specific to our environment). * Main * Date --> Set to GMT, not local time!!! * Serial ATA --> SATA Controller Mode --> Enhanced --> SATA AHCI --> Enabled * Advanced * Boot Features --> Quiet Mode --> Disabled --> Enable Multimedia Timer --> Enabled * PCI Configuration --> Onboard G-LAN1 OPROM --> Disabled --> Large Disk Access Mode --> Other * Advanced Processor Options --> Intel(R) Virtualization Technology --> Enabled --> C1 Enhanced Mode --> Enabled -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From dougb at FreeBSD.org Tue Jul 22 16:39:22 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Jul 22 16:39:29 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <20080722160542.GA14592@epia-2.farid-hajji.net> References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> <20080722160542.GA14592@epia-2.farid-hajji.net> Message-ID: <48860D38.6060209@FreeBSD.org> cpghost wrote: > Yes indeed. If I understand all this correctly, it's because the > transaction ID that has to be sent back is only 2 bytes long, 2 bits, 16 bytes. > and if the query port doesn't change as well with every query, that > can be cracked in milliseconds: sending 65536 DNS queries to a > constant port is just way too easy! The namespace is way too small, > and there's no way to fix this by switching to, say, 4 bytes or > even more for the transaction ID without breaking existing > resolvers; actually without breaking the protocol itself. That's more or less accurate, yes. Doug -- This .signature sanitized for your protection From kris at FreeBSD.org Tue Jul 22 16:45:01 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Tue Jul 22 16:45:13 2008 Subject: "sleeping without queue" ? In-Reply-To: <20080722161958.GA11139@eos.sc1.parodius.com> References: <4885F2A6.5020204@aldan.algebra.com> <4885FCE5.1060507@FreeBSD.org> <48860725.9050808@aldan.algebra.com> <20080722161958.GA11139@eos.sc1.parodius.com> Message-ID: <48860E8C.6050400@FreeBSD.org> Jeremy Chadwick wrote: > On Tue, Jul 22, 2008 at 12:13:25PM -0400, Mikhail Teterin wrote: >> Kris Kennaway ???????(??): >>> Mikhail Teterin wrote: >>>> Hello! >>>> >>>> My attempt to build openoffice.org-3 seems to be hanging. Pressing >>>> Ctrl-T produces: >>>> >>>> load: 0.11 cmd: tcsh 79759 [sleeping without queue] 0.00u 0.00s >>>> 0% 0k >>>> >>>> (tcsh is used by OOo's build-script). What is this "sleeping without >>>> queue" state, and why is process in it for so long? >>>> >>>> This is an 4-CPU amd64 system with 4Gb of RAM. Only 16% of the swap >>>> is currently in use and the box seems to be perfectly fine otherwise. >>>> Uptime is 55 days, two different X-sessions are functional... The >>>> kernel is FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37. >>>> >>>> Thanks! >>> What is the process backtrace? >> Hard to say... The process ID 79759. According to ps(1), that PID exists: >> 79759 p6 DE+ 0:00,00 /bin/tcsh -fc >> /meow/ports/editors/openoffice.org-3/work/BEB300_m3/solver/300/unxfbsdx.pro/bin/makedepend >> @/tmp/mk2WUYYi > ../../../unxfbsdx.pro/misc/s_addincol.dpcc >> According to gdb, it does not: >> gdb 79759 >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and you are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for details. >> This GDB was configured as "amd64-marcel-freebsd"...79759: No such file >> or directory. > > Syntax appears wrong; "gdb [program] 79759" would be what you want. > Well, I mean kernel backtrace. Kris From mi+mill at aldan.algebra.com Tue Jul 22 16:46:50 2008 From: mi+mill at aldan.algebra.com (Mikhail Teterin) Date: Tue Jul 22 16:46:57 2008 Subject: "sleeping without queue" ? In-Reply-To: <48860E8C.6050400@FreeBSD.org> References: <4885F2A6.5020204@aldan.algebra.com> <4885FCE5.1060507@FreeBSD.org> <48860725.9050808@aldan.algebra.com> <20080722161958.GA11139@eos.sc1.parodius.com> <48860E8C.6050400@FreeBSD.org> Message-ID: <48860EF6.2040007@aldan.algebra.com> Kris Kennaway ???????(??): > Well, I mean kernel backtrace. Can I obtain that remotely and without restarting/panicking the box? Thanks, -mi From kris at FreeBSD.org Tue Jul 22 17:01:57 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Tue Jul 22 17:02:04 2008 Subject: "sleeping without queue" ? In-Reply-To: <48860EF6.2040007@aldan.algebra.com> References: <4885F2A6.5020204@aldan.algebra.com> <4885FCE5.1060507@FreeBSD.org> <48860725.9050808@aldan.algebra.com> <20080722161958.GA11139@eos.sc1.parodius.com> <48860E8C.6050400@FreeBSD.org> <48860EF6.2040007@aldan.algebra.com> Message-ID: <48861284.1050706@FreeBSD.org> Mikhail Teterin wrote: > Kris Kennaway ???????(??): >> Well, I mean kernel backtrace. > Can I obtain that remotely and without restarting/panicking the box? > Thanks, > > -mi > > kgdb on /dev/mem or procstat Kris From cliftonr at lava.net Tue Jul 22 17:03:51 2008 From: cliftonr at lava.net (Clifton Royston) Date: Tue Jul 22 17:03:58 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <48860CBA.6010903@FreeBSD.org> References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> <20080722162024.GA1279@lava.net> <48860CBA.6010903@FreeBSD.org> Message-ID: <20080722170348.GB1279@lava.net> On Tue, Jul 22, 2008 at 09:37:14AM -0700, Doug Barton wrote: > Clifton Royston wrote: > > I also think that modular design of security-sensitive tools is the > >way to go, with his DNS tools as with Postfix. > > Dan didn't write postfix, he wrote qmail. I know, but I think qmail sucks. Wietse didn't write a DNS server or I'd probably be using that. :-) > If you're interested in a resolver-only solution (and that is not a > bad way to go) then you should evaluate dns/unbound. It is a > lightweight resolver-only server that has a good security model and > already implements query port randomization. It also has the advantage > of being maintained, and compliant to 21st Century DNS standards > including DNSSEC (which, btw, is the real solution to the response > forgery problem, it just can't be deployed universally before 8/5). Sounds interesting; is it a caching resolver? I'm not totally convinced DNSSEC would solve everything (though it would solve the current vulnerability) but I'm not sure I follow the arguments pro and con. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From cliftonr at lava.net Tue Jul 22 17:07:28 2008 From: cliftonr at lava.net (Clifton Royston) Date: Tue Jul 22 17:07:35 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <48860D38.6060209@FreeBSD.org> References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> <20080722160542.GA14592@epia-2.farid-hajji.net> <48860D38.6060209@FreeBSD.org> Message-ID: <20080722170726.GC1279@lava.net> On Tue, Jul 22, 2008 at 09:39:20AM -0700, Doug Barton wrote: > cpghost wrote: > >Yes indeed. If I understand all this correctly, it's because the > >transaction ID that has to be sent back is only 2 bytes long, > > 2 bits, 16 bytes. ^^^^ ^^^^^ Think you mean those the other way! > >and if the query port doesn't change as well with every query, that > >can be cracked in milliseconds: sending 65536 DNS queries to a > >constant port is just way too easy! The namespace is way too small, > >and there's no way to fix this by switching to, say, 4 bytes or > >even more for the transaction ID without breaking existing > >resolvers; actually without breaking the protocol itself. > > That's more or less accurate, yes. > > Doug I just saw mention in Infoworld - adequate details of the exploit were guessed by another developer and then confirmed. They're now circulating, so I think we can expect engineered attacks soon. All: Upgrade your servers today, do not wait. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From mi+mill at aldan.algebra.com Tue Jul 22 17:09:30 2008 From: mi+mill at aldan.algebra.com (Mikhail Teterin) Date: Tue Jul 22 17:09:38 2008 Subject: "sleeping without queue" ? In-Reply-To: <48861284.1050706@FreeBSD.org> References: <4885F2A6.5020204@aldan.algebra.com> <4885FCE5.1060507@FreeBSD.org> <48860725.9050808@aldan.algebra.com> <20080722161958.GA11139@eos.sc1.parodius.com> <48860E8C.6050400@FreeBSD.org> <48860EF6.2040007@aldan.algebra.com> <48861284.1050706@FreeBSD.org> Message-ID: <48861448.7020708@aldan.algebra.com> Kris Kennaway ???????(??): > Mikhail Teterin wrote: >> Kris Kennaway ???????(??): >>> Well, I mean kernel backtrace. >> Can I obtain that remotely and without restarting/panicking the box? >> Thanks, > kgdb on /dev/mem or procstat root@aldan:~ (107) kgdb /boot/kernel/kernel /dev/mem [...] (kgdb) bt #0 0x0000000000000000 in ?? () Error accessing memory address 0x0: Bad address. Even less luck with procstat: root@aldan:~ (108) locate procstat root@aldan:~ (109) procstat procstat: ???????? ???????. root@aldan:~ (110) man procstat No manual entry for procstat I'm sorry, but you'll need to be more specific. What should I type? Thanks, -mi From dougb at FreeBSD.org Tue Jul 22 17:13:31 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Jul 22 17:13:37 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <20080722170726.GC1279@lava.net> References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> <20080722160542.GA14592@epia-2.farid-hajji.net> <48860D38.6060209@FreeBSD.org> <20080722170726.GC1279@lava.net> Message-ID: <48861537.6060406@FreeBSD.org> Clifton Royston wrote: > On Tue, Jul 22, 2008 at 09:39:20AM -0700, Doug Barton wrote: >> cpghost wrote: >>> Yes indeed. If I understand all this correctly, it's because the >>> transaction ID that has to be sent back is only 2 bytes long, >> 2 bits, 16 bytes. > ^^^^ ^^^^^ Think you mean those the other way! Oops, ELACKOFCAFFEINE >>> and if the query port doesn't change as well with every query, that >>> can be cracked in milliseconds: sending 65536 DNS queries to a >>> constant port is just way too easy! The namespace is way too small, >>> and there's no way to fix this by switching to, say, 4 bytes or >>> even more for the transaction ID without breaking existing >>> resolvers; actually without breaking the protocol itself. >> That's more or less accurate, yes. >> >> Doug > > I just saw mention in Infoworld - adequate details of the exploit > were guessed by another developer and then confirmed. They're now > circulating, so I think we can expect engineered attacks soon. > > All: > Upgrade your servers today, do not wait. Agreed on both counts. -- This .signature sanitized for your protection From m.seaman at infracaninophile.co.uk Tue Jul 22 17:16:57 2008 From: m.seaman at infracaninophile.co.uk (Matthew Seaman) Date: Tue Jul 22 17:17:04 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <48860CBA.6010903@FreeBSD.org> References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> <20080722162024.GA1279@lava.net> <48860CBA.6010903@FreeBSD.org> Message-ID: <488615F5.80405@infracaninophile.co.uk> Doug Barton wrote: > Clifton Royston wrote: >> I also think that modular design of security-sensitive tools is the >> way to go, with his DNS tools as with Postfix. > > Dan didn't write postfix, he wrote qmail. > > If you're interested in a resolver-only solution (and that is not a bad > way to go) then you should evaluate dns/unbound. It is a lightweight > resolver-only server that has a good security model and already > implements query port randomization. It also has the advantage of being > maintained, and compliant to 21st Century DNS standards including DNSSEC Are there any plans to enable DNSSEC capability in the resolver built into FreeBSD? > (which, btw, is the real solution to the response forgery problem, it > just can't be deployed universally before 8/5). That big announcement Dan Kaminsky was going to make at the Blackhat Conference in August? Unfortunately the cat has already been let out of the bag: http://blog.invisibledenizen.org/2008/07/kaminskys-dns-issue-accidentally-leaked.html There's no implementation of DNS that can be any /more/ proof against this than BIND+latest patches because the problem is intrinsic to the design of the DNS protocol. You'ld better be patched up or using alternative DNS implementations equally secure already. Even so that just increases the search space from about 16bits to about 30bits, which should make it not really feasible given current network and server capabilities. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080722/c34c45c4/signature.pgp From dougb at FreeBSD.org Tue Jul 22 17:27:44 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Jul 22 17:27:52 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <488615F5.80405@infracaninophile.co.uk> References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> <20080722162024.GA1279@lava.net> <48860CBA.6010903@FreeBSD.org> <488615F5.80405@infracaninophile.co.uk> Message-ID: <4886188E.6090805@FreeBSD.org> Matthew Seaman wrote: > Are there any plans to enable DNSSEC capability in the resolver built > into FreeBSD? The server is already capable of it. I'm seriously considering enabling the define to make the CLI tools (dig/host/nslookup) capable as well (there is already an OPTION for this in ports). The problem is that _using_ DNSSEC requires configuration changes in named.conf, and more importantly, configuration of "trust anchors" (even for the command line stuff) since the root is not signed. It's not hard to do that with the DLV system that ISC has in place, and I would be willing to create a conf file that shows how to do that for users to include if they choose to. I am not comfortable enabling it by default (not yet anyway), it's too big of a POLA issue. Doug -- This .signature sanitized for your protection From pschmehl_lists at tx.rr.com Tue Jul 22 17:28:13 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Tue Jul 22 17:28:25 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <48860CBA.6010903@FreeBSD.org> References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> <20080722162024.GA1279@lava.net> <48860CBA.6010903@FreeBSD.org> Message-ID: <24AEB3BFE15219E4ADA1F2E9@utd65257.utdallas.edu> --On Tuesday, July 22, 2008 09:37:14 -0700 Doug Barton wrote: > Clifton Royston wrote: >> I also think that modular design of security-sensitive tools is the >> way to go, with his DNS tools as with Postfix. > > Dan didn't write postfix, he wrote qmail. I think his point was that djbdns is modular just like Postfix is modular - not that Dan wrote both. I'm pretty sure everyone on the planet knows that Weitse wrote/maintains Postfix. If djbdns was as easy to setup as Postfix is, I'd use it too. > > If you're interested in a resolver-only solution (and that is not a bad way > to go) then you should evaluate dns/unbound. It is a lightweight > resolver-only server that has a good security model and already implements > query port randomization. It also has the advantage of being maintained, and > compliant to 21st Century DNS standards including DNSSEC (which, btw, is the > real solution to the response forgery problem, it just can't be deployed > universally before 8/5). > What happens on 8/5? -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. From ianjhart at ntlworld.com Tue Jul 22 17:47:45 2008 From: ianjhart at ntlworld.com (ian j hart) Date: Tue Jul 22 17:47:52 2008 Subject: unable to boot 7.0-RELEASE cdrom on supermicro 5015b-mt In-Reply-To: <20080722163724.GA11757@eos.sc1.parodius.com> References: <200807221727.52718.ianjhart@ntlworld.com> <20080722163724.GA11757@eos.sc1.parodius.com> Message-ID: <200807221847.34935.ianjhart@ntlworld.com> On Tuesday 22 July 2008 17:37:24 Jeremy Chadwick wrote: > On Tue, Jul 22, 2008 at 05:27:52PM +0100, ian j hart wrote: > > Same hardware as my other thread. > > http://www.supermicro.com/products/system/1U/5015/SYS-5015B-MT.cfm > > > > [using 2Gb RAM and SATA in legacy mode] > > > > I'd like to focus only on making the CDROM boot complete. > > > > Summary: hangs just after the CPUs are launched. > > > > 6.2-RELEASE works okay, no AHCI support > > 6.3-RELEASE works okay > > 7.0-RELEASE hangs > > 7.0-STABLE-200806-SNAPSHOT hangs > > 8.0-CURRENT-200806-SNAPSHOT hangs > > > > I thought I could do a binary search using the current snapshot boot-only > > CDs but they only go back to March. Are there any older ones available? > > Have you tried disabling ACPI to see if it makes any sort of difference? Yes, but I'm happy to re-try. Which method is "best"? Or is it 1 + 2 or 3? 1) BIOS 2) Beastie menu option 3) loader prompt set hint > > Also, AHCI should work just fine on those systems -- I know because I > have fairly extensive experience with Supermicro hardware, although what > you're using is newer than what I presently have. I don't know why > you're setting Compatible/Legacy mode on your controller (you mention > doing this in your other thread as well). Because I don't know what's wrong yet and AHCI support is newer than SATA support and this is a newish board? [At least 6.2 doesn't seem to support it and it has an AHCI legacy option!] I'd be happy to swap this over. Slight problem; the drives get renumbered, so I'd rather not swap back and forth. > > Below is what we use on our systems; factory defaults, then make the > following changes. (The G-LAN1 OPROM option you can do whatever you > want with -- it's specific to our environment). > > * Main > * Date > --> Set to GMT, not local time!!! > * Serial ATA > --> SATA Controller Mode --> Enhanced > --> SATA AHCI --> Enabled > > * Advanced > * Boot Features > --> Quiet Mode --> Disabled > --> Enable Multimedia Timer --> Enabled > * PCI Configuration > --> Onboard G-LAN1 OPROM --> Disabled > --> Large Disk Access Mode --> Other > * Advanced Processor Options > --> Intel(R) Virtualization Technology --> Enabled > --> C1 Enhanced Mode --> Enabled I've got as close as I can to this. This board also has an AHCI legacy option [disabled] which hides ports 5 and 6. I also disabled quickboot and POST errors. I assume multimedia timer is the same as HPET. Doesn't seem to be any disk translation option. I took the fans off 'flat out'. Thanks for your help. -- ian j hart From pschmehl_lists at tx.rr.com Tue Jul 22 17:52:16 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Tue Jul 22 17:52:22 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <4886188E.6090805@FreeBSD.org> References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> <20080722162024.GA1279@lava.net> <48860CBA.6010903@FreeBSD.org> <488615F5.80405@infracaninophile.co.uk> <4886188E.6090805@FreeBSD.org> Message-ID: <34182EE347F910EA2A64DF03@utd65257.utdallas.edu> --On Tuesday, July 22, 2008 10:27:42 -0700 Doug Barton wrote: > Matthew Seaman wrote: > >> Are there any plans to enable DNSSEC capability in the resolver built >> into FreeBSD? > > The server is already capable of it. I'm seriously considering enabling the > define to make the CLI tools (dig/host/nslookup) capable as well (there is > already an OPTION for this in ports). > > The problem is that _using_ DNSSEC requires configuration changes in > named.conf, and more importantly, configuration of "trust anchors" (even for > the command line stuff) since the root is not signed. It's not hard to do > that with the DLV system that ISC has in place, and I would be willing to > create a conf file that shows how to do that for users to include if they > choose to. I am not comfortable enabling it by default (not yet anyway), it's > too big of a POLA issue. > I just played around with it recently. It's not that easy to understand initially *and* the trust anchors thing is a royal PITA. Once you implement DNSSEC you *must* generate keys every 30 days. So, I think, if you're going to enable it by default, there needs to be a script in periodic that will do all the magic to change keys every 30 days. Maybe put vars in /etc/rc.conf to override the default key lengths and other portions of the commands that could change per installation. If I were to implement it, I'd write a shell script to turn the keys over and cron it because doing it manually every 30 days ain't gonna happen. Too many ways to forget to do it. (I did the same for the root servers so that named.ca gets updated automagically every month.) But until root is signed, it's not worth it for those of us who don't have dedicated staff doing dns only. -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. From sthaug at nethelp.no Tue Jul 22 18:34:15 2008 From: sthaug at nethelp.no (sthaug@nethelp.no) Date: Tue Jul 22 18:34:23 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <48860CBA.6010903@FreeBSD.org> References: <200807221552.m6MFqgpm009488@lurza.secnetix.de> <20080722162024.GA1279@lava.net> <48860CBA.6010903@FreeBSD.org> Message-ID: <20080722.200709.74704291.sthaug@nethelp.no> > If you're interested in a resolver-only solution (and that is not a > bad way to go) then you should evaluate dns/unbound. It is a > lightweight resolver-only server that has a good security model and > already implements query port randomization. It also has the advantage > of being maintained, and compliant to 21st Century DNS standards > including DNSSEC (which, btw, is the real solution to the response > forgery problem, it just can't be deployed universally before 8/5). I've been trying out unbound-1.0.1 on a 7.0-STABLE box (2.67 GHz i86, uniprocessor, 32 bit mode, 2 GB memory). Don't know what I'm doing wrong so far - but I've been unable to scale Unbound to more than a couple of hundred q/s. Any more than that and I get serious (several hundred ms) delays on lots of queries, including stuff which is known to be in the cache. I'll be doing some more Unbound tests the next few days. For now, both CNS and PowerDNS handle our load (around 2.5K q/s) fine. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From m.seaman at infracaninophile.co.uk Tue Jul 22 18:37:45 2008 From: m.seaman at infracaninophile.co.uk (Matthew Seaman) Date: Tue Jul 22 18:37:52 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <4886188E.6090805@FreeBSD.org> References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> <20080722162024.GA1279@lava.net> <48860CBA.6010903@FreeBSD.org> <488615F5.80405@infracaninophile.co.uk> <4886188E.6090805@FreeBSD.org> Message-ID: <488628EC.5030801@infracaninophile.co.uk> Doug Barton wrote: > Matthew Seaman wrote: > >> Are there any plans to enable DNSSEC capability in the resolver built >> into FreeBSD? > > The server is already capable of it. I'm seriously considering enabling > the define to make the CLI tools (dig/host/nslookup) capable as well > (there is already an OPTION for this in ports). Forgive me for being obtuse. What I meant was the capability to enable checking signatures on DNS RRs as a routine effect of getnameinfo() etc. by modifying resolver(3) routines or similar locally, without needing a DNSSEC enabled recursive resolver listed in resolv.conf? I've a feeling the answer is no, but I haven't been able to find anything definitive. Which I suppose simply means that if you're in the habit of, for example, taking your laptop into the coffee shop and getting on line there then you need to run your own instance of named on your laptop rather than blindly trusting whatever servers the coffee shop provides via their DHCP. > The problem is that _using_ DNSSEC requires configuration changes in > named.conf, and more importantly, configuration of "trust anchors" (even > for the command line stuff) since the root is not signed. It's not hard > to do that with the DLV system that ISC has in place, and I would be > willing to create a conf file that shows how to do that for users to > include if they choose to. I am not comfortable enabling it by default > (not yet anyway), it's too big of a POLA issue. I sense a business opportunity in providing DLV there. I'm wondering why the likes of Verisign (including Thawte and Geotrust), Comodo group and GoDaddy aren't circling like vultures over a dead wildebeest. Perhaps they are. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080722/62057fc7/signature.pgp From mi+mill at aldan.algebra.com Tue Jul 22 19:26:36 2008 From: mi+mill at aldan.algebra.com (Mikhail Teterin) Date: Tue Jul 22 19:26:48 2008 Subject: "sleeping without queue" ? In-Reply-To: <20080722192155.GC17123@deviant.kiev.zoral.com.ua> References: <4885F2A6.5020204@aldan.algebra.com> <4885FCE5.1060507@FreeBSD.org> <48860725.9050808@aldan.algebra.com> <20080722161958.GA11139@eos.sc1.parodius.com> <48860E8C.6050400@FreeBSD.org> <48860EF6.2040007@aldan.algebra.com> <48861284.1050706@FreeBSD.org> <48861448.7020708@aldan.algebra.com> <20080722192155.GC17123@deviant.kiev.zoral.com.ua> Message-ID: <48863465.8080204@aldan.algebra.com> Kostik Belousov ???????(??): > Did you switched to the process before doing backtrace (using the proc > command)? Ok, thanks. Did not know about this one. Here: ... (kgdb) proc 79759 (kgdb) bt #0 sched_switch (td=0xffffff01286dc000, newtd=0xffffff00010ce000, flags=2) at /var/src/sys/kern/sched_4bsd.c:928 #1 0x0000000000000000 in ?? () #2 0xffffffff802f1108 in mi_switch (flags=678281216, newtd=0x2) at /var/src/sys/kern/kern_synch.c:442 #3 0xffffffff80318513 in sleepq_check_timeout () at /var/src/sys/kern/subr_sleepqueue.c:519 #4 0xffffffff80318c85 in sleepq_timedwait (wchan=0xffffffff80688408) at /var/src/sys/kern/subr_sleepqueue.c:597 #5 0xffffffff802f16a2 in _sleep (ident=0xffffffff80688408, lock=0x0, priority=0, wmesg=0xffffffff804f3059 "vmo_de", timo=1) at /var/src/sys/kern/kern_synch.c:224 #6 0xffffffff8043036b in vm_object_deallocate (object=0xffffff0053024a90) at /var/src/sys/vm/vm_object.c:509 #7 0xffffffff8042920e in vm_map_delete (map=0xffffff0015ba4b60, start=18446742979242478224, end=140737488355328) at /var/src/sys/vm/vm_map.c:2315 #8 0xffffffff804293df in vm_map_remove (map=0xffffff0015ba4b60, start=0, end=140737488355328) at /var/src/sys/vm/vm_map.c:2423 #9 0xffffffff8042b813 in vmspace_exit (td=0xffffff01286dc000) at /var/src/sys/vm/vm_map.c:324 #10 0xffffffff802c8cff in exit1 (td=0xffffff01286dc000, rv=0) at /var/src/sys/kern/kern_exit.c:294 #11 0xffffffff802ca08e in sys_exit (td=Variable "td" is not available. ) at /var/src/sys/kern/kern_exit.c:98 #12 0xffffffff8045a700 in syscall (frame=0xffffffffb0d89c70) at /var/src/sys/amd64/amd64/trap.c:852 #13 0xffffffff8043f38b in Xfast_syscall () at /var/src/sys/amd64/amd64/exception.S:290 #14 0x000000080095f34c in ?? () Previous frame inner to this frame (corrupt stack?) > What is the exact version of the system ? Note that procstat > appeared in the late RELENG_7. FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37 EST 2008 > > Also, show the output of ps axl . UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 79759 79758 0 96 0 0 16 - DE+ p6 0:00,00 /bin/tcsh -fc /meow/ports/editors/openoffice.org-3/work/BEB300_m3/solver/300/unxfbsdx.pro/bin/ma Yours, -mi From kostikbel at gmail.com Tue Jul 22 19:41:22 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Tue Jul 22 19:41:28 2008 Subject: "sleeping without queue" ? In-Reply-To: <48863465.8080204@aldan.algebra.com> References: <4885F2A6.5020204@aldan.algebra.com> <4885FCE5.1060507@FreeBSD.org> <48860725.9050808@aldan.algebra.com> <20080722161958.GA11139@eos.sc1.parodius.com> <48860E8C.6050400@FreeBSD.org> <48860EF6.2040007@aldan.algebra.com> <48861284.1050706@FreeBSD.org> <48861448.7020708@aldan.algebra.com> <20080722192155.GC17123@deviant.kiev.zoral.com.ua> <48863465.8080204@aldan.algebra.com> Message-ID: <20080722194114.GE17123@deviant.kiev.zoral.com.ua> On Tue, Jul 22, 2008 at 03:26:29PM -0400, Mikhail Teterin wrote: > Kostik Belousov ???????(??): > >Did you switched to the process before doing backtrace (using the proc > > > >command)? > Ok, thanks. Did not know about this one. Here: > ... > (kgdb) proc 79759 > (kgdb) bt > #0 sched_switch (td=0xffffff01286dc000, newtd=0xffffff00010ce000, > flags=2) at /var/src/sys/kern/sched_4bsd.c:928 > #1 0x0000000000000000 in ?? () > #2 0xffffffff802f1108 in mi_switch (flags=678281216, newtd=0x2) at > /var/src/sys/kern/kern_synch.c:442 > #3 0xffffffff80318513 in sleepq_check_timeout () at > /var/src/sys/kern/subr_sleepqueue.c:519 > #4 0xffffffff80318c85 in sleepq_timedwait (wchan=0xffffffff80688408) at > /var/src/sys/kern/subr_sleepqueue.c:597 > #5 0xffffffff802f16a2 in _sleep (ident=0xffffffff80688408, lock=0x0, > priority=0, wmesg=0xffffffff804f3059 "vmo_de", timo=1) at > /var/src/sys/kern/kern_synch.c:224 > #6 0xffffffff8043036b in vm_object_deallocate > (object=0xffffff0053024a90) at /var/src/sys/vm/vm_object.c:509 From this frame, please, print the object (like p *object) and likewise, print the object that is at the head of the object->shadow_head list. Another question is what scheduler do you use ? > #7 0xffffffff8042920e in vm_map_delete (map=0xffffff0015ba4b60, > start=18446742979242478224, end=140737488355328) at > /var/src/sys/vm/vm_map.c:2315 > #8 0xffffffff804293df in vm_map_remove (map=0xffffff0015ba4b60, > start=0, end=140737488355328) at /var/src/sys/vm/vm_map.c:2423 > #9 0xffffffff8042b813 in vmspace_exit (td=0xffffff01286dc000) at > /var/src/sys/vm/vm_map.c:324 > #10 0xffffffff802c8cff in exit1 (td=0xffffff01286dc000, rv=0) at > /var/src/sys/kern/kern_exit.c:294 > #11 0xffffffff802ca08e in sys_exit (td=Variable "td" is not available. > ) at /var/src/sys/kern/kern_exit.c:98 > #12 0xffffffff8045a700 in syscall (frame=0xffffffffb0d89c70) at > /var/src/sys/amd64/amd64/trap.c:852 > #13 0xffffffff8043f38b in Xfast_syscall () at > /var/src/sys/amd64/amd64/exception.S:290 > #14 0x000000080095f34c in ?? () > Previous frame inner to this frame (corrupt stack?) > > >What is the exact version of the system ? Note that procstat > >appeared in the late RELENG_7. > FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37 EST 2008 > > > >Also, show the output of ps axl . > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND > 0 79759 79758 0 96 0 0 16 - DE+ p6 0:00,00 > /bin/tcsh -fc > /meow/ports/editors/openoffice.org-3/work/BEB300_m3/solver/300/unxfbsdx.pro/bin/ma It makes sense to show the whole ps axl output. > > Yours, > > -mi -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080722/e370549a/attachment.pgp From kostikbel at gmail.com Tue Jul 22 19:54:43 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Tue Jul 22 19:54:50 2008 Subject: "sleeping without queue" ? In-Reply-To: <48861448.7020708@aldan.algebra.com> References: <4885F2A6.5020204@aldan.algebra.com> <4885FCE5.1060507@FreeBSD.org> <48860725.9050808@aldan.algebra.com> <20080722161958.GA11139@eos.sc1.parodius.com> <48860E8C.6050400@FreeBSD.org> <48860EF6.2040007@aldan.algebra.com> <48861284.1050706@FreeBSD.org> <48861448.7020708@aldan.algebra.com> Message-ID: <20080722192155.GC17123@deviant.kiev.zoral.com.ua> On Tue, Jul 22, 2008 at 01:09:28PM -0400, Mikhail Teterin wrote: > Kris Kennaway ???????(??): > >Mikhail Teterin wrote: > >>Kris Kennaway ???????(??): > >>>Well, I mean kernel backtrace. > >>Can I obtain that remotely and without restarting/panicking the box? > >>Thanks, > >kgdb on /dev/mem or procstat > root@aldan:~ (107) kgdb /boot/kernel/kernel /dev/mem > [...] > (kgdb) bt > #0 0x0000000000000000 in ?? () > Error accessing memory address 0x0: Bad address. > > Even less luck with procstat: > > root@aldan:~ (108) locate procstat > root@aldan:~ (109) procstat > procstat: ???????? ???????. > root@aldan:~ (110) man procstat > No manual entry for procstat > > I'm sorry, but you'll need to be more specific. What should I type? Thanks, Did you switched to the process before doing backtrace (using the proc command) ? What is the exact version of the system ? Note that procstat appeared in the late RELENG_7. Also, show the output of ps axl . -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080722/7650c480/attachment-0001.pgp From mi+mill at aldan.algebra.com Tue Jul 22 20:00:00 2008 From: mi+mill at aldan.algebra.com (Mikhail Teterin) Date: Tue Jul 22 20:00:08 2008 Subject: "sleeping without queue" ? In-Reply-To: <20080722194114.GE17123@deviant.kiev.zoral.com.ua> References: <4885F2A6.5020204@aldan.algebra.com> <4885FCE5.1060507@FreeBSD.org> <48860725.9050808@aldan.algebra.com> <20080722161958.GA11139@eos.sc1.parodius.com> <48860E8C.6050400@FreeBSD.org> <48860EF6.2040007@aldan.algebra.com> <48861284.1050706@FreeBSD.org> <48861448.7020708@aldan.algebra.com> <20080722192155.GC17123@deviant.kiev.zoral.com.ua> <48863465.8080204@aldan.algebra.com> <20080722194114.GE17123@deviant.kiev.zoral.com.ua> Message-ID: <48863C3D.7090401@aldan.algebra.com> Kostik Belousov ???????(??): > On Tue, Jul 22, 2008 at 03:26:29PM -0400, Mikhail Teterin wrote: >> Kostik Belousov ???????(??): >>> Did you switched to the process before doing backtrace (using the proc >>> >>> command)? >> Ok, thanks. Did not know about this one. Here: >> ... >> (kgdb) proc 79759 >> (kgdb) bt >> #0 sched_switch (td=0xffffff01286dc000, newtd=0xffffff00010ce000, >> flags=2) at /var/src/sys/kern/sched_4bsd.c:928 >> #1 0x0000000000000000 in ?? () >> #2 0xffffffff802f1108 in mi_switch (flags=678281216, newtd=0x2) at >> /var/src/sys/kern/kern_synch.c:442 >> #3 0xffffffff80318513 in sleepq_check_timeout () at >> /var/src/sys/kern/subr_sleepqueue.c:519 >> #4 0xffffffff80318c85 in sleepq_timedwait (wchan=0xffffffff80688408) at >> /var/src/sys/kern/subr_sleepqueue.c:597 >> #5 0xffffffff802f16a2 in _sleep (ident=0xffffffff80688408, lock=0x0, >> priority=0, wmesg=0xffffffff804f3059 "vmo_de", timo=1) at >> /var/src/sys/kern/kern_synch.c:224 >> #6 0xffffffff8043036b in vm_object_deallocate >> (object=0xffffff0053024a90) at /var/src/sys/vm/vm_object.c:509 > From this frame, please, print the object (like p *object) and > likewise, print the object that is at the head of the object->shadow_head > list. kgdb /usr/obj/var/src/sys/SILVER-SMP/kernel.debug /dev/mem [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd". There is no member named pathname. Reading symbols from /opt/modules/fuse.ko...done. Loaded symbols for /opt/modules/fuse.ko Reading symbols from /opt/modules/rtc.ko...done. Loaded symbols for /opt/modules/rtc.ko Reading symbols from /boot/kernel/snd_ich.ko...Reading symbols from /boot/kernel/snd_ich.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_ich.ko Reading symbols from /boot/kernel/msdosfs.ko...Reading symbols from /boot/kernel/msdosfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/msdosfs.ko #0 0x0000000000000000 in ?? () (kgdb) frame 6 Error accessing memory address 0x0: Bad address. (kgdb) pid 79759 Undefined command: "pid". Try "help". (kgdb) proc 79759 (kgdb) frame 6 #6 0xffffffff8043036b in vm_object_deallocate (object=0xffffff0053024a90) at /var/src/sys/vm/vm_object.c:509 509 pause("vmo_de", 1); (kgdb) p *object $1 = {mtx = {lock_object = {lo_name = 0xffffffff804f21c4 "vm object", lo_type = 0xffffffff804f3018 "standard object", lo_flags = 21168128, lo_witness_data = { lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, object_list = {tqe_next = 0xffffff0005018a90, tqe_prev = 0xffffff00539a6850}, shadow_head = {lh_first = 0xffffff005d3afa90}, shadow_list = {le_next = 0x0, le_prev = 0xffffff005d2cd048}, memq = { tqh_first = 0xffffff007eb9fa58, tqh_last = 0xffffff007f864820}, root = 0xffffff007ee14d38, size = 427, generation = 66, ref_count = 2, shadow_count = 1, type = 0 '\0', flags = 256, pg_color = 0, paging_in_progress = 0, resident_page_count = 44, backing_object = 0x0, backing_object_offset = 0, pager_object_list = { tqe_next = 0x0, tqe_prev = 0x0}, cache = 0x0, handle = 0x0, un_pager = {vnp = {vnp_size = 576646}, devp = {devp_pglist = {tqh_first = 0x8cc86, tqh_last = 0x0}}, swp = {swp_bcount = 576646}}} (kgdb) p (object->shadow_head) $2 = {lh_first = 0xffffff005d3afa90} (kgdb) p *object->shadow_head.lh_first $3 = {mtx = {lock_object = {lo_name = 0xffffffff804f21c4 "vm object", lo_type = 0xffffffff804f3018 "standard object", lo_flags = 21168128, lo_witness_data = { lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, object_list = {tqe_next = 0xffffff0066c32340, tqe_prev = 0xffffff012f673ac0}, shadow_head = {lh_first = 0x0}, shadow_list = {le_next = 0x0, le_prev = 0xffffff0053024ad0}, memq = { tqh_first = 0xffffff007779f9a0, tqh_last = 0xffffff0077c04140}, root = 0xffffff0077c04130, size = 387, generation = 3, ref_count = 1, shadow_count = 0, type = 0 '\0', flags = 8452, pg_color = 0, paging_in_progress = 0, resident_page_count = 2, backing_object = 0xffffff0053024a90, backing_object_offset = 163840, pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, cache = 0x0, handle = 0x0, un_pager = {vnp = {vnp_size = 365278}, devp = {devp_pglist = { tqh_first = 0x592de, tqh_last = 0x0}}, swp = {swp_bcount = 365278}}} > > Another question is what scheduler do you use ? options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption >>> Also, show the output of ps axl . >> UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND >> 0 79759 79758 0 96 0 0 16 - DE+ p6 0:00,00 >> /bin/tcsh -fc >> /meow/ports/editors/openoffice.org-3/work/BEB300_m3/solver/300/unxfbsdx.pro/bin/ma > > It makes sense to show the whole ps axl output. See http://aldan.algebra.com/~mi/tmp/ps-axl.txt -- I edited it for privacy a little bit, but process-states are intact. The java-processes in the linuxf have remained unkillable for weeks now -- I even forgot about them. But those are linuxulator problems, whereas the tcsh is native... Yours, -mi From royce at alaska.net Tue Jul 22 20:05:20 2008 From: royce at alaska.net (Royce Williams) Date: Tue Jul 22 20:05:27 2008 Subject: 6.3-RELEASE-p3 recurring panics on multiple SM PDSMi+ Message-ID: <488638DA.7010005@alaska.net> We have 10 SuperMicro PDSMi+ 5015M-MTs that are panic'ing every few days. This started shortly after upgrade from 6.2-RELEASE to 6.3-RELEASE with freebsd-update. Other than switching to a debugging kernel, a little sysctl tuning, and patching with freebsd-update, they are stock. The debugging kernel was built from source that is also being patched with freebsd-update. These systems are running postfix and Courier imapd for an ISP with a userbase on the order of 10^4 users. They use gmirror, but the mailstore is over NFS. That NFS server is under pretty high load. All of the servers with this app and load pattern are panic'ing. I have little experience with kernel debugging, but the box in question is out of our farm and available for testing, and I am motivated to cooperate. :-) The full debugging kernel options I used are: include SMP options KDB options KDB_TRACE options DDB options BREAK_TO_DEBUGGER options WITNESS options WITNESS_SKIPSPIN db> trace Tracing pid 71182 tid 100325 td 0xcc08b180 kdb_enter(c095f294) at kdb_enter+0x2b panic(c09768ad,1000,14000000,c145bc88,1000,...) at panic+0x127 kmem_malloc(c14680c0,1000,102,eba6a8cc,c07e3fa5,...) at kmem_malloc+0x89 page_alloc(c1453780,1000,eba6a8bf,102,c06b8a84,...) at page_alloc+0x1a slab_zalloc(c1453780,102,c14537e0,c1453780,c1460d5c,...) at slab_zalloc+0xa1 uma_zone_slab(c1453780,2) at uma_zone_slab+0xf0 uma_zalloc_bucket(c1453780,2) at uma_zalloc_bucket+0x11c uma_zalloc_arg(c1453780,0,2) at uma_zalloc_arg+0x24c cache_enter(cd02c220,c9e62880,eba6a9fc) at cache_enter+0xa6 nfs_readdirplusrpc(cd02c220,eba6aa60,cc0ab880) at nfs_readdirplusrpc+0x6a6 nfs_doio(cd02c220,dce59668,cc0ab880,cc08b180,dce59668,...) at nfs_doio+0x20f nfs_bioread(cd02c220,eba6acb0,0,cc0ab880) at nfs_bioread+0xa64 nfs_readdir(eba6ac90) at nfs_readdir+0xe6 VOP_READDIR_APV(c09ebbc0,eba6ac90) at VOP_READDIR_APV+0x38 getdirentries(cc08b180,eba6ad04) at getdirentries+0x146 syscall(3b,3b,3b,9085f00,9085f00,...) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (196, FreeBSD ELF32, getdirentries), eip = 0xb825a79b, esp = 0xbfbfa1fc, ebp = 0xbfbfa228 --- Royce -- Royce D. Williams - http://royce.ws/ I don't like that man. I must get to know him better. - A. Lincoln From oberman at es.net Tue Jul 22 20:07:23 2008 From: oberman at es.net (Kevin Oberman) Date: Tue Jul 22 20:07:33 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: Your message of "Tue, 22 Jul 2008 12:52:15 CDT." <34182EE347F910EA2A64DF03@utd65257.utdallas.edu> Message-ID: <20080722200720.0540245048@ptavv.es.net> > Date: Tue, 22 Jul 2008 12:52:15 -0500 > From: Paul Schmehl > Sender: owner-freebsd-stable@freebsd.org > > --On Tuesday, July 22, 2008 10:27:42 -0700 Doug Barton > wrote: > > > Matthew Seaman wrote: > > > >> Are there any plans to enable DNSSEC capability in the resolver built > >> into FreeBSD? > > > > The server is already capable of it. I'm seriously considering enabling the > > define to make the CLI tools (dig/host/nslookup) capable as well (there is > > already an OPTION for this in ports). > > > > The problem is that _using_ DNSSEC requires configuration changes in > > named.conf, and more importantly, configuration of "trust anchors" (even for > > the command line stuff) since the root is not signed. It's not hard to do > > that with the DLV system that ISC has in place, and I would be willing to > > create a conf file that shows how to do that for users to include if they > > choose to. I am not comfortable enabling it by default (not yet anyway), it's > > too big of a POLA issue. > > > > I just played around with it recently. It's not that easy to understand > initially *and* the trust anchors thing is a royal PITA. No one is likely to argue with that statement! > Once you implement DNSSEC you *must* generate keys every 30 days. So, > I think, if you're going to enable it by default, there needs to be a > script in periodic that will do all the magic to change keys every 30 > days. Maybe put vars in /etc/rc.conf to override the default key > lengths and other portions of the commands that could change per > installation. No, you don't HAVE to generate keys every 30 days, but you should if you want real security. Still, for a while, until the infrastructure is complete enough to make DNSSEC really of value to the end user, just getting signed domains with keys published in an easily accessed place is at least getting things started and getting the infrastructure moving. Rolling keys is a rather tricky operation where mistakes, once DNSSEC makes it to the end user, would be disastrous, so it would require a couple of scripts, one to set a new key and another to remove the old one. You need both key present for a period of time. > If I were to implement it, I'd write a shell script to turn the keys > over and cron it because doing it manually every 30 days ain't gonna > happen. Too many ways to forget to do it. (I did the same for the > root servers so that named.ca gets updated automagically every month.) And that is FAR less important than the signatures. (named.ca could be updated once a year and be just fine.) > But until root is signed, it's not worth it for those of us who don't > have dedicated staff doing dns only. Work continues on getting the root signed, but it .com and .net that present the really big problems. The root delay is mostly political, not technical. .com and .net are both. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080722/0f71ae47/attachment.pgp From kris at FreeBSD.org Tue Jul 22 20:12:22 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Tue Jul 22 20:12:29 2008 Subject: 6.3-RELEASE-p3 recurring panics on multiple SM PDSMi+ In-Reply-To: <488638DA.7010005@alaska.net> References: <488638DA.7010005@alaska.net> Message-ID: <48863F23.9020504@FreeBSD.org> Royce Williams wrote: > db> trace > Tracing pid 71182 tid 100325 td 0xcc08b180 > kdb_enter(c095f294) at kdb_enter+0x2b > panic(c09768ad,1000,14000000,c145bc88,1000,...) at panic+0x127 > kmem_malloc(c14680c0,1000,102,eba6a8cc,c07e3fa5,...) at kmem_malloc+0x89 You forgot to include the panic, but this is probably the "kmem_map too small" panic. It says that your kernel ran out of memory, and the solution is to fix that situation by giving more memory to the kernel. Increase the vm.kmem_size tunable until your system stops running out of memory on your workload. Kris From pschmehl_lists at tx.rr.com Tue Jul 22 20:30:54 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Tue Jul 22 20:31:13 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <20080722200720.0540245048@ptavv.es.net> References: <20080722200720.0540245048@ptavv.es.net> Message-ID: <9C1F9AB0E0CD3034CA691A30@utd65257.utdallas.edu> --On Tuesday, July 22, 2008 13:07:20 -0700 Kevin Oberman wrote: > >> Once you implement DNSSEC you *must* generate keys every 30 days. So, >> I think, if you're going to enable it by default, there needs to be a >> script in periodic that will do all the magic to change keys every 30 >> days. Maybe put vars in /etc/rc.conf to override the default key >> lengths and other portions of the commands that could change per >> installation. > > No, you don't HAVE to generate keys every 30 days, but you should if you > want real security. For me that means must. :-) Someone needs to write a really good tutorial on dnssec. The bits and pieces are scattered about the web, but explanations of now to publish your keys, to whom they need to be published and what is involved in the ongoing maintenance are lacking. Especially a clear explanation of what is required to run both keyed and "legacy" dns at the same time. > Still, for a while, until the infrastructure is > complete enough to make DNSSEC really of value to the end user, just > getting signed domains with keys published in an easily accessed place > is at least getting things started and getting the infrastructure > moving. > Where do you publish the keys? > Rolling keys is a rather tricky operation where mistakes, once DNSSEC > makes it to the end user, would be disastrous, so it would require a > couple of scripts, one to set a new key and another to remove the old > one. You need both key present for a period of time. > I'd not read that. Can you explain? I thought you simply overwrote the existing keys with the new ones (in the zone file.) In fact I was thinking that an $INCLUDE would make a great deal more sense. I didn't realize you had to retain the old keys for a while. That complicates matters significantly. BTW, I think without those scripts (or at least examples) you'll find adoption will be a great deal slower. Many people that need to run dns are far from experts and often intimidated by its complexity - especially the complexity of dnssec. -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. From jhb at freebsd.org Tue Jul 22 21:00:43 2008 From: jhb at freebsd.org (John Baldwin) Date: Tue Jul 22 21:01:11 2008 Subject: ACPI regression on recent 7.0-STABLE: HPET stops working In-Reply-To: <20080722113751.qp8znc0duswkgs8g@webmail.opentransfer.com> References: <20080719100315.2td4dl2q5ck88wkw@webmail.opentransfer.com> <200807211800.12415.jhb@freebsd.org> <20080722113751.qp8znc0duswkgs8g@webmail.opentransfer.com> Message-ID: <200807221514.55055.jhb@freebsd.org> On Tuesday 22 July 2008 04:37:51 am Oleg V. Nauman wrote: > Quoting John Baldwin : > > > On Monday 21 July 2008 06:07:52 am Oleg V. Nauman wrote: > >> Quoting "Oleg V. Nauman" : > >> > >> > Quoting Jeremy Chadwick : > >> > > >> >> On Sat, Jul 19, 2008 at 10:03:15AM +0300, Oleg V. Nauman wrote: > >> >>> It seems to be something was changed with ACPI support on 7.0-STABLE so > >> >>> my next system upgrade ended with ACPI HPET not working anymore on my > >> >>> ASUS A9Rp laptop. > >> >>> > >> >>> Here is the part of /var/log/dmesg.today dated July 13: > >> >>> > >> >>> FreeBSD 7.0-STABLE #65: Tue Jul 8 22:05:07 EEST 2008 > >> >>> root@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2 > >> >>> [..] > >> >>> acpi0: on motherboard > >> >>> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 > >> >>> acpi0: [ITHREAD] > >> >>> acpi0: Power Button (fixed) > >> >>> acpi0: reservation of 0, a0000 (3) failed > >> >>> acpi0: reservation of 100000, 77f00000 (3) failed > >> >>> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > >> >>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > >> >>> acpi_ec0: port 0x62,0x66 on acpi0 > >> >>> acpi_hpet0: iomem > >> >>> 0xfed00000-0xfed003ff on acpi0 > >> >>> Timecounter "HPET" frequency 14318180 Hz quality 900 > >> >>> > >> >>> Here is the fresh dmesg output info: > >> >>> > >> >>> FreeBSD 7.0-STABLE #66: Tue Jul 15 22:11:27 EEST 2008 > >> >>> root@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2 > >> >>> [..] > >> >>> acpi0: on motherboard > >> >>> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 > >> >>> acpi0: [ITHREAD] > >> >>> acpi0: Power Button (fixed) > >> >>> acpi0: reservation of 0, a0000 (3) failed > >> >>> acpi0: reservation of 100000, 77f00000 (3) failed > >> >>> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > >> >>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > >> >>> [..] > >> >>> acpi_hpet0: iomem > >> >>> 0xfed00000-0xfed003ff on acpi0 > >> >>> device_attach: acpi_hpet0 attach returned 12 > >> >>> > >> >>> And the part of actual sysctl kern.timecounter output: > >> >>> > >> >>> kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) > > dummy(-1000000) > >> >>> kern.timecounter.hardware: ACPI-safe > >> >> > >> >> Seems okay here: > >> >> > >> >> FreeBSD icarus.home.lan 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat Jul > >> >> 12 10:53:08 PDT 2008 > >> >> root@icarus.home.lan:/usr/obj/usr/src/sys/PDSMI_PLUS_amd64 amd64 > >> >> > >> >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > >> >> acpi_hpet0: iomem > >> >> 0xfed00000-0xfed003ff on acpi0 > >> >> Timecounter "i8254" frequency 1193182 Hz quality 0 > >> >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > >> >> Timecounter "HPET" frequency 14318180 Hz quality 900 > >> >> Timecounters tick every 1.000 msec > >> >> > >> >> kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) > >> >> i8254(0) dummy(-1000000) > >> >> kern.timecounter.hardware: ACPI-fast > >> >> > >> >> You sure you haven't upgraded your BIOS or something and forgot to > >> >> re-enable HPET? > >> > > >> > No it was not upgraded.. Have no option to enable/disable HPET through > >> > BIOS settings though > >> > >> I was unclear a bit or so. There are no ACPI related settings in my > >> laptop's BIOS. > >> > >> Well.. Backout 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c > >> (committed to RELENG_7 at July 10 by jhb) fixes this issue for me: > >> > >> acpi_hpet0: iomem 0xfed00000-0xfed003ff on > > acpi0 > >> Timecounter "HPET" frequency 14318180 Hz quality 900 > >> > >> kern.timecounter.choice: TSC(800) HPET(900) ACPI-safe(850) i8254(0) > >> dummy(-1000000) > >> kern.timecounter.hardware: HPET > >> > >> Hopefully it helps to understand what is went wrong there. > > > > Ok, so the attempt to allocate the resource is failing for some reason. Can > > you get output from 'devinfo -r' and 'devinfo -u'? > > ... > > Will not provide with full listings but just a diff comparing two > states (this good one with HPET working and bad w/o it): > > rainhaven# diff devinfo.r.good devinfo.r.bad > 177,179d176 > < acpi_hpet0 > < I/O memory addresses: > < 0xfed00000-0xfed003ff > > rainhaven# diff devinfo.u.good devinfo.u.bad > 128c128 > < 0xfed00000-0xfed003ff (acpi_hpet0) > --- > > 0xfed00000-0xfed003ff (ichsmb0) > > So kernel with 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c > allocates the region required to ichsmb0 instead HPET (it not helps to > ichsmb0 because it never was working on my laptop but it is another > story I think). > > Thank you for looking into. Hmm, so ichsmb0 doesn't show up at all in your earlier dmesg. Try this change, it restores the probe orders to be more of what they used to be and just gives CPUs a really high probe order so that they should be after other devices. Index: acpi.c =================================================================== RCS file: /usr/cvs/src/sys/dev/acpica/acpi.c,v retrieving revision 1.248 diff -u -r1.248 acpi.c --- acpi.c 7 Apr 2008 18:35:11 -0000 1.248 +++ acpi.c 22 Jul 2008 19:12:56 -0000 @@ -1531,8 +1531,7 @@ * 1. I/O port and memory system resource holders * 2. Embedded controllers (to handle early accesses) * 3. PCI Link Devices - * ACPI_DEV_BASE_ORDER. Host-PCI bridges - * ACPI_DEV_BASE_ORDER + 10. CPUs + * 100000. CPUs */ AcpiGetType(handle, &type); if (acpi_MatchHid(handle, "PNP0C01") || acpi_MatchHid(handle, "PNP0C02")) @@ -1541,10 +1540,8 @@ *order = 2; else if (acpi_MatchHid(handle, "PNP0C0F")) *order = 3; - else if (acpi_MatchHid(handle, "PNP0A03")) - *order = ACPI_DEV_BASE_ORDER; else if (type == ACPI_TYPE_PROCESSOR) - *order = ACPI_DEV_BASE_ORDER + 10; + *order = 100000; } /* @@ -1594,10 +1591,8 @@ * placeholder so that the probe/attach passes will run * breadth-first. Orders less than ACPI_DEV_BASE_ORDER * are reserved for special objects (i.e., system - * resources). Orders between ACPI_DEV_BASE_ORDER and 100 - * are used for Host-PCI bridges (and effectively all - * their children) and CPUs. Larger values are used for - * all other devices. + * resources). CPU devices have a very high order to + * ensure they are probed after other devices. */ ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "scanning '%s'\n", handle_str)); order = level * 10 + 100; -- John Baldwin From royce at alaska.net Tue Jul 22 21:04:03 2008 From: royce at alaska.net (Royce Williams) Date: Tue Jul 22 21:04:10 2008 Subject: 6.3-RELEASE-p3 recurring panics on multiple SM PDSMi+ In-Reply-To: <48863F23.9020504@FreeBSD.org> References: <488638DA.7010005@alaska.net> <48863F23.9020504@FreeBSD.org> Message-ID: <48864B41.50300@alaska.net> Kris Kennaway wrote, on 7/22/2008 12:12 PM: > Royce Williams wrote: > >> db> trace >> Tracing pid 71182 tid 100325 td 0xcc08b180 >> kdb_enter(c095f294) at kdb_enter+0x2b >> panic(c09768ad,1000,14000000,c145bc88,1000,...) at panic+0x127 >> kmem_malloc(c14680c0,1000,102,eba6a8cc,c07e3fa5,...) at kmem_malloc+0x89 > > You forgot to include the panic Is there is a way to get the panic after dropping into the debugger? This serial console setup has no scrollback, so I couldn't see the preceding text. > but this is probably the "kmem_map too small" panic. Ah, I see this now, at faq/book.html#KMEM-MAP-TOO-SMALL: "Compile your own kernel, and add the VM_KMEM_SIZE_MAX to your kernel configuration file, increasing the maximum size to 400 MB (options VM_KMEM_SIZE_MAX=419430400). 400 MB appears to be sufficient for machines with up to 6 GB of memory." > It says that your kernel ran out of memory, and the > solution is to fix that situation by giving more memory to the kernel. > Increase the vm.kmem_size tunable until your system stops running out of > memory on your workload. Comparing the FAQ, kern_malloc.c and your mentioning it as tunable, please clarify: is the Right Thing to do to use vm.kmem_size, or vm.kmem_size_max? I tried vm.kmem_size_max, which yields: # sysctl -a | grep kmem vm.kmem_size: 419430400 vm.kmem_size_max: 419430400 vm.kmem_size_scale: 3 Should I contribute some additional language to the FAQ, saying that the vm.kmem_size[_max] tunable can be used without recompiling the kernel? Royce -- Royce D. Williams - http://royce.ws/ Reproof should not exhaust its power upon petty failings. - S. Johnson From dimitry at andric.com Tue Jul 22 21:19:51 2008 From: dimitry at andric.com (Dimitry Andric) Date: Tue Jul 22 21:19:57 2008 Subject: ACPI regression on recent 7.0-STABLE: HPET stops working In-Reply-To: <200807211800.12415.jhb@freebsd.org> References: <20080719100315.2td4dl2q5ck88wkw@webmail.opentransfer.com> <20080719111838.il32fec2880wok4g@webmail.opentransfer.com> <20080721130752.pstwcwkz88wso8cs@webmail.opentransfer.com> <200807211800.12415.jhb@freebsd.org> Message-ID: <48864EF4.3090708@andric.com> On 2008-07-22 00:00, John Baldwin wrote: > On Monday 21 July 2008 06:07:52 am Oleg V. Nauman wrote: >> Well.. Backout 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c >> (committed to RELENG_7 at July 10 by jhb) fixes this issue for me: >> >> acpi_hpet0: iomem 0xfed00000-0xfed003ff on > acpi0 >> Timecounter "HPET" frequency 14318180 Hz quality 900 >> >> kern.timecounter.choice: TSC(800) HPET(900) ACPI-safe(850) i8254(0) >> dummy(-1000000) >> kern.timecounter.hardware: HPET >> >> Hopefully it helps to understand what is went wrong there. > > Ok, so the attempt to allocate the resource is failing for some reason. Can > you get output from 'devinfo -r' and 'devinfo -u'? FWIW, I've tried acpi.c revs 1.243.2.1 through 1.243.2.3, and all give the same result: acpi_hpet0: iomem 0xfe800000-0xfe8003ff on acpi0 device_attach: acpi_hpet0 attach returned 12 E.g. it looks like bus_alloc_resource_any() in acpi_hpet_attach() fails, but no idea why? Anyway, devinfo -r and -u give: nexus0 apic0 ram0 I/O memory addresses: 0x0-0x9efff 0x100000-0x1eedffff npx0 acpi0 Interrupt request lines: 9 I/O ports: 0x10-0x1f 0x22-0x3f 0x44-0x5f 0x62-0x63 0x65-0x6f 0x74-0x7f 0x91-0x93 0xa2-0xbf 0xe0-0xef 0x290-0x297 0x400-0x47f 0x4d0-0x4d1 0x500-0x50f 0x800-0x805 I/O memory addresses: 0xf0000-0xfffff 0x1eee0000-0x1eefffff 0xfe800000-0xfe8000ff 0xfea00000-0xfea000ff 0xfec00000-0xfecfffff 0xfee00000-0xfeefffff 0xfff80000-0xfffeffff 0xffff0000-0xffffffff cpu0 ACPI I/O ports: 0x414 0x415 acpi_perf0 est0 p4tcc0 cpufreq0 acpi_button0 acpi_sysresource0 pcib0 pci0 hostb0 I/O memory addresses: 0xe8000000-0xefffffff hostb1 hostb2 hostb3 hostb4 hostb5 pcib1 pci1 vgapci0 I/O memory addresses: 0xf4000000-0xf7ffffff 0xfb000000-0xfbffffff re0 Interrupt request lines: 18 I/O ports: 0xf000-0xf0ff I/O memory addresses: 0xfdfff000-0xfdfff0ff miibus0 rgephy0 re1 Interrupt request lines: 19 I/O ports: 0xf200-0xf2ff I/O memory addresses: 0xfdffe000-0xfdffe0ff miibus1 rgephy1 atapci0 Interrupt request lines: 20 I/O ports: 0xf400-0xf4ff 0xfb00-0xfb0f 0xfc00-0xfc03 0xfd00-0xfd07 0xfe00-0xfe03 0xff00-0xff07 ata2 ad4 subdisk4 ata3 ad6 subdisk6 atapci1 I/O ports: 0x170-0x177 0x1f0-0x1f7 0x376 0x3f6 0xfa00-0xfa0f ata0 Interrupt request lines: 14 ata1 Interrupt request lines: 15 uhci0 Interrupt request lines: 21 I/O ports: 0xf900-0xf91f usb0 uhub0 uhci1 I/O ports: 0xf800-0xf81f usb1 uhub1 uhci2 I/O ports: 0xf700-0xf71f usb2 uhub2 uhci3 I/O ports: 0xf600-0xf61f usb3 uhub3 ehci0 I/O memory addresses: 0xfdffd000-0xfdffd0ff usb4 uhub4 isab0 isa0 atkbdc0 I/O ports: 0x60 0x64 atkbd0 Interrupt request lines: 1 sc0 vga0 I/O ports: 0x3c0-0x3df I/O memory addresses: 0xa0000-0xbffff orm0 I/O memory addresses: 0xc0000-0xcf7ff pmtimer0 acpi_sysresource1 acpi_sysresource2 pci_link0 pci_link1 pci_link2 pci_link3 pci_link4 pci_link5 pci_link6 pci_link7 pci_link8 pci_link9 pci_link10 pci_link11 acpi_sysresource3 atpic0 atdma0 attimer0 attimer1 npxisa0 uart0 Interrupt request lines: 4 I/O ports: 0x3f8-0x3ff uart1 Interrupt request lines: 3 I/O ports: 0x2f8-0x2ff ppc0 Interrupt request lines: 7 I/O ports: 0x378-0x37f ppbus0 plip0 lpt0 ppi0 acpi_tz0 acpi_timer0 ACPI I/O ports: 0x408-0x40b Interrupt request lines: 0 (root0) 1 (atkbd0) 3 (uart1) 4 (uart0) 5-6 (root0) 7 (ppc0) 8 (root0) 9 (acpi0) 10-13 (root0) 14 (ata0) 15 (ata1) 16-17 (root0) 18 (re0) 19 (re1) 20 (atapci0) 21 (uhci0) 22-23 (root0) DMA request lines: 0-7 (root0) I/O ports: 0x0-0xf (root0) 0x10-0x1f (acpi0) 0x20-0x21 (root0) 0x22-0x3f (acpi0) 0x40-0x43 (root0) 0x44-0x5f (acpi0) 0x60 (atkbdc0) 0x61 (root0) 0x62-0x63 (acpi0) 0x64 (atkbdc0) 0x65-0x6f (acpi0) 0x70-0x73 (root0) 0x74-0x7f (acpi0) 0x80-0x90 (root0) 0x91-0x93 (acpi0) 0x94-0xa1 (root0) 0xa2-0xbf (acpi0) 0xc0-0xdf (root0) 0xe0-0xef (acpi0) 0xf0-0x16f (root0) 0x170-0x177 (atapci1) 0x178-0x1ef (root0) 0x1f0-0x1f7 (atapci1) 0x1f8-0x28f (root0) 0x290-0x297 (acpi0) 0x298-0x2f7 (root0) 0x2f8-0x2ff (uart1) 0x300-0x375 (root0) 0x376 (atapci1) 0x377 (root0) 0x378-0x37f (ppc0) 0x380-0x3bf (root0) 0x3c0-0x3df (vga0) 0x3e0-0x3f5 (root0) 0x3f6 (atapci1) 0x3f7 (fdc0) 0x3f8-0x3ff (uart0) 0x400-0x47f (acpi0) 0x480-0x4cf (root0) 0x4d0-0x4d1 (acpi0) 0x4d2-0x4ff (root0) 0x500-0x50f (acpi0) 0x510-0x7ff (root0) 0x800-0x805 (acpi0) 0x806-0xedff (root0) 0xee00-0xeeff ---- 0xef00-0xefff (root0) 0xf000-0xf0ff (re0) 0xf100-0xf1ff (root0) 0xf200-0xf2ff (re1) 0xf300-0xf3ff (root0) 0xf400-0xf4ff (atapci0) 0xf500-0xf5ff (root0) 0xf600-0xf61f (uhci3) 0xf620-0xf6ff (root0) 0xf700-0xf71f (uhci2) 0xf720-0xf7ff (root0) 0xf800-0xf81f (uhci1) 0xf820-0xf8ff (root0) 0xf900-0xf91f (uhci0) 0xf920-0xf9ff (root0) 0xfa00-0xfa0f (atapci1) 0xfa10-0xfaff (root0) 0xfb00-0xfb0f (atapci0) 0xfb10-0xfbff (root0) 0xfc00-0xfc03 (atapci0) 0xfc04-0xfcff (root0) 0xfd00-0xfd07 (atapci0) 0xfd08-0xfdff (root0) 0xfe00-0xfe03 (atapci0) 0xfe04-0xfeff (root0) 0xff00-0xff07 (atapci0) 0xff08-0xffff (root0) I/O memory addresses: 0x0-0x9efff (ram0) 0x9f000-0x9ffff (root0) 0xa0000-0xbffff (vga0) 0xc0000-0xcf7ff (orm0) 0xcf800-0xeffff (root0) 0xf0000-0xfffff (acpi0) 0x100000-0x1eedffff (ram0) 0x1eee0000-0x1eefffff (acpi0) 0x1ef00000-0xe7ffffff (root0) 0xe8000000-0xefffffff (hostb0) 0xf0000000-0xf3ffffff (root0) 0xf4000000-0xf7ffffff (vgapci0) 0xf8000000-0xfaffffff (root0) 0xfb000000-0xfbffffff (vgapci0) 0xfc000000-0xfdffcfff (root0) 0xfdffd000-0xfdffd0ff (ehci0) 0xfdffd100-0xfdffdfff (root0) 0xfdffe000-0xfdffe0ff (re1) 0xfdffe100-0xfdffefff (root0) 0xfdfff000-0xfdfff0ff (re0) 0xfdfff100-0xfe7fffff (root0) 0xfe800000-0xfe8000ff (acpi0) 0xfe800100-0xfe9fffff (root0) 0xfea00000-0xfea000ff (acpi0) 0xfea00100-0xfebfffff (root0) 0xfec00000-0xfecfffff (acpi0) 0xfed00000-0xfedfffff (root0) 0xfee00000-0xfeefffff (acpi0) 0xfef00000-0xfff7ffff (root0) 0xfff80000-0xfffeffff (acpi0) 0xffff0000-0xffffffff (acpi0) ACPI I/O ports: 0x10-0x1f (root0) 0x22-0x3f (root0) 0x44-0x5f (root0) 0x62-0x63 (root0) 0x65-0x6f (root0) 0x74-0x7f (root0) 0x91-0x93 (root0) 0xa2-0xbf (root0) 0xe0-0xef (root0) 0x290-0x297 (root0) 0x400-0x407 (root0) 0x408-0x40b (acpi_timer0) 0x40c-0x413 (root0) 0x414 (cpu0) 0x415 (cpu0) 0x416-0x47f (root0) 0x4d0-0x4d1 (root0) 0x500-0x50f (root0) 0x800-0x805 (root0) ACPI I/O memory addresses: 0xf0000-0xfffff (root0) 0x1eee0000-0x1eefffff (root0) 0xfe800000-0xfe8000ff (root0) 0xfea00000-0xfea000ff (root0) 0xfec00000-0xfecfffff (root0) 0xfee00000-0xfeefffff (root0) 0xfff80000-0xfffeffff (root0) 0xffff0000-0xffffffff (root0) From oberman at es.net Tue Jul 22 21:49:27 2008 From: oberman at es.net (Kevin Oberman) Date: Tue Jul 22 21:49:35 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: Your message of "Tue, 22 Jul 2008 15:30:53 CDT." <9C1F9AB0E0CD3034CA691A30@utd65257.utdallas.edu> Message-ID: <20080722214925.390584500E@ptavv.es.net> > Date: Tue, 22 Jul 2008 15:30:53 -0500 > From: Paul Schmehl > > --On Tuesday, July 22, 2008 13:07:20 -0700 Kevin Oberman wrote: > > > >> Once you implement DNSSEC you *must* generate keys every 30 days. So, > >> I think, if you're going to enable it by default, there needs to be a > >> script in periodic that will do all the magic to change keys every 30 > >> days. Maybe put vars in /etc/rc.conf to override the default key > >> lengths and other portions of the commands that could change per > >> installation. > > > > No, you don't HAVE to generate keys every 30 days, but you should if you > > want real security. > > For me that means must. :-) > > Someone needs to write a really good tutorial on dnssec. The bits and > pieces are scattered about the web, but explanations of now to publish > your keys, to whom they need to be published and what is involved in > the ongoing maintenance are lacking. Especially a clear explanation > of what is required to run both keyed and "legacy" dns at the same > time. I can't imagine why anyone would want to run both. Resolvers which don't know how to check signatures simple don't do so and everything still works. A pretty good, though somewhat outdated tutorial can be found in NIST SP800-81. It's pretty readable and tells you how to generate keys and sign a zone properly. http://csrc.nist.gov/publications/nistpubs/800-81/SP800-81.pdf > > Still, for a while, until the infrastructure is > > complete enough to make DNSSEC really of value to the end user, just > > getting signed domains with keys published in an easily accessed place > > is at least getting things started and getting the infrastructure > > moving. > > > > Where do you publish the keys? I have not done so at this time. We have a DNS system that does not quite support DNSSEC, although that should be resolved shortly. NIST simply puts theirs on a web page. This is not a good long-term answer, but is adequate for growing the infrastructure and letting people play with it. DNSSEC really needs to be ready now, but it's simply not, so we need to get some sort of start and more experience in using it. I have a test server that is signed and that I am playing with and I hope that I will be able to sign our production zones in the next few months. Our plan is to buy a network appliance to do the key generation, signing and key rolls. > > Rolling keys is a rather tricky operation where mistakes, once DNSSEC > > makes it to the end user, would be disastrous, so it would require a > > couple of scripts, one to set a new key and another to remove the old > > one. You need both key present for a period of time. > > > > I'd not read that. Can you explain? I thought you simply overwrote > the existing keys with the new ones (in the zone file.) In fact I was > thinking that an $INCLUDE would make a great deal more sense. I > didn't realize you had to retain the old keys for a while. That > complicates matters significantly. Since data in cached, you can't simply replace the key and not have failures when the cached old keys are used to try to verify newly received data. You need to have the old key remain valid for the length of your longest TTL. Note: I am not a DNSSEC expert at all. I have been "playing" with it for over a year, but have been unable to actually use it in production because of our DNS management software which does not support DNSSEC. Hopefully everything I said is correct, but it would be best to verify things before basing much on it. > BTW, I think without those scripts (or at least examples) you'll find > adoption will be a great deal slower. Many people that need to run > dns are far from experts and often intimidated by its complexity - > especially the complexity of dnssec. I completely agree that you are right. DNSSEC is not trivial to manage and, while managing it does not require any detailed knowledge of how it works, it does take careful planning and some education for those who will be working with it. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080722/512d94a0/attachment.pgp From kris at FreeBSD.org Tue Jul 22 21:56:49 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Tue Jul 22 21:56:56 2008 Subject: 6.3-RELEASE-p3 recurring panics on multiple SM PDSMi+ In-Reply-To: <48864B41.50300@alaska.net> References: <488638DA.7010005@alaska.net> <48863F23.9020504@FreeBSD.org> <48864B41.50300@alaska.net> Message-ID: <488657A0.9000501@FreeBSD.org> Royce Williams wrote: > Kris Kennaway wrote, on 7/22/2008 12:12 PM: >> Royce Williams wrote: >> >>> db> trace >>> Tracing pid 71182 tid 100325 td 0xcc08b180 >>> kdb_enter(c095f294) at kdb_enter+0x2b >>> panic(c09768ad,1000,14000000,c145bc88,1000,...) at panic+0x127 >>> kmem_malloc(c14680c0,1000,102,eba6a8cc,c07e3fa5,...) at kmem_malloc+0x89 >> You forgot to include the panic > > Is there is a way to get the panic after dropping into the debugger? > This serial console setup has no scrollback, so I couldn't see the > preceding text. You can either "show msgbuf", or "x/x panicstr" and then "x/s 0x...." where that is the hex value from the previous step. The latter only diplays the format string and not the arguments, but on i386 you can read them off from the panic() line in the stack trace. Actually on i386 the panicstr is the first argument (0xc09768ad here). >> but this is probably the "kmem_map too small" panic. > > Ah, I see this now, at faq/book.html#KMEM-MAP-TOO-SMALL: > > "Compile your own kernel, and add the VM_KMEM_SIZE_MAX to your kernel > configuration file, increasing the maximum size to 400 MB (options > VM_KMEM_SIZE_MAX=419430400). 400 MB appears to be sufficient for > machines with up to 6 GB of memory." > > >> It says that your kernel ran out of memory, and the >> solution is to fix that situation by giving more memory to the kernel. >> Increase the vm.kmem_size tunable until your system stops running out of >> memory on your workload. > > Comparing the FAQ, kern_malloc.c and your mentioning it as tunable, > please clarify: is the Right Thing to do to use vm.kmem_size, or > vm.kmem_size_max? kmem_size_max is used for automatically tuning based on RAM size. To increase the actual value explicitly you just need to tune vm.kmem_size. > I tried vm.kmem_size_max, which yields: > > # sysctl -a | grep kmem > vm.kmem_size: 419430400 > vm.kmem_size_max: 419430400 > vm.kmem_size_scale: 3 > > > Should I contribute some additional language to the FAQ, saying that > the vm.kmem_size[_max] tunable can be used without recompiling the kernel? Yes, that would be fantastic! I would also note that the loader tunable is usually more convenient since it doesn't require a kernel recompile, and probably reword the claim about 400MB: the memory needed depends very much on the workload you are giving your kernel, so the best advice is to increase the value until you determine empirically how much you need (i.e. the memory exhaustion stops). You can also use "400M" notation for loader tunables which is often more convenient. Thanks, Kris Kris From koitsu at FreeBSD.org Wed Jul 23 00:18:41 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Jul 23 00:18:48 2008 Subject: unable to boot 7.0-RELEASE cdrom on supermicro 5015b-mt In-Reply-To: <200807221847.34935.ianjhart@ntlworld.com> References: <200807221727.52718.ianjhart@ntlworld.com> <20080722163724.GA11757@eos.sc1.parodius.com> <200807221847.34935.ianjhart@ntlworld.com> Message-ID: <20080723001835.GA33136@eos.sc1.parodius.com> On Tue, Jul 22, 2008 at 06:47:34PM +0100, ian j hart wrote: > On Tuesday 22 July 2008 17:37:24 Jeremy Chadwick wrote: > > On Tue, Jul 22, 2008 at 05:27:52PM +0100, ian j hart wrote: > > > Same hardware as my other thread. > > > http://www.supermicro.com/products/system/1U/5015/SYS-5015B-MT.cfm > > > > > > [using 2Gb RAM and SATA in legacy mode] > > > > > > I'd like to focus only on making the CDROM boot complete. > > > > > > Summary: hangs just after the CPUs are launched. > > > > > > 6.2-RELEASE works okay, no AHCI support > > > 6.3-RELEASE works okay > > > 7.0-RELEASE hangs > > > 7.0-STABLE-200806-SNAPSHOT hangs > > > 8.0-CURRENT-200806-SNAPSHOT hangs > > > > > > I thought I could do a binary search using the current snapshot boot-only > > > CDs but they only go back to March. Are there any older ones available? > > > > Have you tried disabling ACPI to see if it makes any sort of difference? > > Yes, but I'm happy to re-try. > > Which method is "best"? Or is it 1 + 2 or 3? > > 1) BIOS > 2) Beastie menu option > 3) loader prompt set hint Item #2 is the easiest. You should really be able to leave the BIOS settings at their defaults (Factory Defaults) and have this system work on FreeBSD. Items #2 and #3 are the same. The loader menu option for disabling ACPI simply sets the hint. > > Also, AHCI should work just fine on those systems -- I know because I > > have fairly extensive experience with Supermicro hardware, although what > > you're using is newer than what I presently have. I don't know why > > you're setting Compatible/Legacy mode on your controller (you mention > > doing this in your other thread as well). > > Because I don't know what's wrong yet and AHCI support is newer than SATA > support and this is a newish board? [At least 6.2 doesn't seem to support it > and it has an AHCI legacy option!] > > I'd be happy to swap this over. Slight problem; the drives get renumbered, so > I'd rather not swap back and forth. You *absolutely* should have AHCI enabled. There's a lot of reasons why, too. I highly recommend avoiding the "SATA Compatible" mode. AHCI should work fine on FreeBSD 6.3 as well as 7.0 -- I know, because we have many Supermicro boards running those versions which do have AHCI enabled. Please use it, and stick with it. Here's added proof that AHCI works fine on 6.3: $ dmesg -a | grep -i ahci atapci1: port 0x30e8-0x30ef,0x30dc-0x30df,0x30e0-0x30e7,0x30d8-0x30db,0x30b0-0x30bf mem 0xe0000400-0xe00007ff irq 19 at device 31.2 on pci0 atapci1: AHCI Version 01.10 controller with 4 ports detected $ uname -r -s FreeBSD 6.3-PRERELEASE The adX device renumbering is expected. There are workarounds for this, but I recommend you simply enable AHCI. Do not keep toggling it on/off. > > Below is what we use on our systems; factory defaults, then make the > > following changes. (The G-LAN1 OPROM option you can do whatever you > > want with -- it's specific to our environment). > > > > * Main > > * Date > > --> Set to GMT, not local time!!! > > * Serial ATA > > --> SATA Controller Mode --> Enhanced > > --> SATA AHCI --> Enabled > > > > * Advanced > > * Boot Features > > --> Quiet Mode --> Disabled > > --> Enable Multimedia Timer --> Enabled > > * PCI Configuration > > --> Onboard G-LAN1 OPROM --> Disabled > > --> Large Disk Access Mode --> Other > > * Advanced Processor Options > > --> Intel(R) Virtualization Technology --> Enabled > > --> C1 Enhanced Mode --> Enabled > > I've got as close as I can to this. > > This board also has an AHCI legacy option [disabled] which hides ports 5 and > 6. I also disabled quickboot and POST errors. I assume multimedia timer is > the same as HPET. Doesn't seem to be any disk translation option. I took the > fans off 'flat out'. Okay, I've had a chance to review the board manual that comes with the X7SBi. You should set the following: Serial ATA: Enabled Native Mode Operation: Serial ATA SATA AHCI: Enabled SATA AHCI Legacy: Disabled The name "SATA AHCI Legacy" a horrible name for what it does. The ICH9 itself has support for 6 SATA ports, but (if I remember correctly, based on reading some Intel design documents) there are extra registers you have to tweak to get those ports to work, and the OS has to be fully aware of how to do that. The BIOS option simply disables SATA ports 5 and 6 altogether; the underlying OS never sees them. I'd recommend keeping that setting Disabled (the default) unless you have disks on those ports (I don't see how, since it's a 4-disk system!). I don't think this option is what's causing you problems, though. "Multimedia Timer" is indeed HPET. Looks like they changed the name to be more reflective of what it actually is. The "Large Disk Access" mode does appear to be missing from that BIOS, probably for a good reason. I can enable/disable it on our boards with no repercussions (the options are "DOS" and "Other", which is why I choose "Other"). I'm not entirely sure what it does. As for your problem... If the CDROM is the problem (which would be odd, since the disc does boot and load the kernel successfully), can you try going into the BIOS and setting IDE Channel 0 Master (which I think is the CDROM -- I could be wrong here) and set "Transfer Mode" to PIO1 and "Ultra DMA Mode" to Disabled? I have a feeling the problem isn't related to the CDROM, but I'm not entirely sure how to debug it. There are other users using the X7SBi with success: http://groups.google.com/group/mailing.freebsd.current/browse_thread/thread/d0a2d20f8965361a http://www.webhostingtalk.com/showthread.php?t=666686 Also, can you make sure your BIOS revision is 1.1a, just to rule out any BIOS-related issues? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From Mark_Andrews at isc.org Wed Jul 23 00:46:48 2008 From: Mark_Andrews at isc.org (Mark Andrews) Date: Wed Jul 23 00:46:55 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: Your message of "Tue, 22 Jul 2008 12:52:15 EST." <34182EE347F910EA2A64DF03@utd65257.utdallas.edu> Message-ID: <200807230046.m6N0khvt008606@drugs.dv.isc.org> > --On Tuesday, July 22, 2008 10:27:42 -0700 Doug Barton > wrote: > > > Matthew Seaman wrote: > > > >> Are there any plans to enable DNSSEC capability in the resolver built > >> into FreeBSD? > > > > The server is already capable of it. I'm seriously considering enabling the > > define to make the CLI tools (dig/host/nslookup) capable as well (there is > > already an OPTION for this in ports). > > > > The problem is that _using_ DNSSEC requires configuration changes in > > named.conf, and more importantly, configuration of "trust anchors" (even fo > r > > the command line stuff) since the root is not signed. It's not hard to do > > that with the DLV system that ISC has in place, and I would be willing to > > create a conf file that shows how to do that for users to include if they > > choose to. I am not comfortable enabling it by default (not yet anyway), it > 's > > too big of a POLA issue. > > > > I just played around with it recently. It's not that easy to understand > initially *and* the trust anchors thing is a royal PITA. > > Once you implement DNSSEC you *must* generate keys every 30 days. So, I thin > k, > if you're going to enable it by default, there needs to be a script in period > ic > that will do all the magic to change keys every 30 days. Maybe put vars in > /etc/rc.conf to override the default key lengths and other portions of the > commands that could change per installation. WRONG. You need to re-sign the zone an expire period before the signatures expire. You need to generate new keys periodically but no where near every 30 days. KSKs annually. This is what the TLD's are doing and that is a very conservative exposure period. In practice it could be multiple years between key rollovers. The reason it is done this frequently is so humans don't forget what they need to do. ZSKs are generally weaker than KSKs but again they don't need to be done monthly. > If I were to implement it, I'd write a shell script to turn the keys over and > cron it because doing it manually every 30 days ain't gonna happen. Too many > ways to forget to do it. (I did the same for the root servers so that named. > ca > gets updated automagically every month.) > > But until root is signed, it's not worth it for those of us who don't have > dedicated staff doing dns only. There are solutions to the root not being signed. If all the TLD were signed the trust anchor work load would not be too great to managed by hand. For those that want a single trust anchor solution there is DLV. Sign your zone. Add it to a DLV. Ask you parent to sign their zone. If you don't sign you parent has no insentive to sign. This can be driven bottom up. That is one of the reasons why DLV was invented to provide incentive for the parent zones to sign. Mark > -- > Paul Schmehl > As if it wasn't already obvious, > my opinions are my own and not > those of my employer. > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From Mark_Andrews at isc.org Wed Jul 23 00:54:35 2008 From: Mark_Andrews at isc.org (Mark Andrews) Date: Wed Jul 23 00:54:43 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: Your message of "Tue, 22 Jul 2008 19:37:32 +0100." <488628EC.5030801@infracaninophile.co.uk> Message-ID: <200807230054.m6N0sYKi008687@drugs.dv.isc.org> > This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > --------------enig5488BAD5E4511AF4D0C2864A > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: quoted-printable > > Doug Barton wrote: > > Matthew Seaman wrote: > >=20 > >> Are there any plans to enable DNSSEC capability in the resolver built = > > >> into FreeBSD? > >=20 > > The server is already capable of it. I'm seriously considering enabling= > =20 > > the define to make the CLI tools (dig/host/nslookup) capable as well=20 > > (there is already an OPTION for this in ports). > > Forgive me for being obtuse. What I meant was the capability to enable c= > hecking signatures on DNS RRs as a routine effect of getnameinfo() etc. > by modifying resolver(3) routines or similar locally, without needing a > DNSSEC enabled recursive resolver listed in resolv.conf? I've a feeling > the answer is no, but I haven't been able to find anything definitive. > > Which I suppose simply means that if you're in the habit of, for example,= > =20 > taking your laptop into the coffee shop and getting on line there then yo= > u=20 > need to run your own instance of named on your laptop rather than blindly= > =20 > trusting whatever servers the coffee shop provides via their DHCP. Use a local (on machine) validating caching nameserver. > > The problem is that _using_ DNSSEC requires configuration changes in=20 > > named.conf, and more importantly, configuration of "trust anchors" (eve= > n=20 > > for the command line stuff) since the root is not signed. It's not hard= > =20 > > to do that with the DLV system that ISC has in place, and I would be=20 > > willing to create a conf file that shows how to do that for users to=20 > > include if they choose to. I am not comfortable enabling it by default = > > > (not yet anyway), it's too big of a POLA issue. > > I sense a business opportunity in providing DLV there. I'm wondering why= > > the likes of Verisign (including Thawte and Geotrust), Comodo group and=20 > GoDaddy aren't circling like vultures over a dead wildebeest. Perhaps th= > ey=20 > are. You only need one DLV. ISC is offering the service for free. Donations welcome as it does cost to run the service. > Cheers, > > Matthew > > --=20 > Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard > Flat 3 > PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate > Kent, CT11 9PW > > > --------------enig5488BAD5E4511AF4D0C2864A > Content-Type: application/pgp-signature; name="signature.asc" > Content-Description: OpenPGP digital signature > Content-Disposition: attachment; filename="signature.asc" > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (FreeBSD) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEAREIAAYFAkiGKPIACgkQ8Mjk52CukIxbWACfTVCDPVViUJ0NTd5GLMMVU8bD > xXkAniwbkPNqgVZYLi4a/5aQHYFxBHSo > =T6Z8 > -----END PGP SIGNATURE----- > > --------------enig5488BAD5E4511AF4D0C2864A-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From Mark_Andrews at isc.org Wed Jul 23 01:58:10 2008 From: Mark_Andrews at isc.org (Mark Andrews) Date: Wed Jul 23 01:58:17 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: Your message of "Tue, 22 Jul 2008 06:20:25 -1000." <20080722162024.GA1279@lava.net> Message-ID: <200807230158.m6N1w6BR015766@drugs.dv.isc.org> > On Tue, Jul 22, 2008 at 05:52:42PM +0200, Oliver Fromme wrote: > > Brett Glass wrote: > > > At 02:24 PM 7/21/2008, Kevin Oberman wrote: > > > > > > > Don't forget that ANY server that caches data, including an end system > > > > running a caching only server is vulnerable. > > > > > > Actually, there is an exception to this. A "forward only" > > > cache/resolver is only as vulnerable as its forwarder(s). This is a > > > workaround for the vulnerability for folks who have systems that they > > > cannot easily upgrade: point at a trusted forwarder that's patched. > > > > > > We're also looking at using dnscache from the djbdns package. > > > > I'm curious, is djbdns exploitable, too? Does it randomize > > the source ports of UDP queries? > > AFAIK Dan Bernstein first spelled out the fundamental problems with > DNS response forgery in 2001. He implemented dnscache to randomize > source ports and IDs from the beginning, via a cryptographic quality > RNG. See for instance this page, much of it written in 2003: > > And the IETF was working on a solution well before that. One that addressed not only off path attacks but also addressed on path attacks. One that worked with kernels that only supported limited numbers of file desriptors. One that worked regardless on the number of concurrent outstanding queries. That solution is called DNSSEC. We looked at what Dan did and said it didn't go far enough and that it has implementation issues at high query rates that can't be solved just by throwing more cpu at the problem. The problems are inherent to how UDP works. > He rubs a lot of people the wrong way, but I think he has usually > proved to be right on security issues. Dan is often right. However a different, more encompassing, solution was choosen. > I also think that modular design of security-sensitive tools is the > way to go, with his DNS tools as with Postfix. > -- Clifton > > -- > Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net > President - I and I Computing * http://www.iandicomputing.com/ > Custom programming, network design, systems and network consulting services > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From koitsu at FreeBSD.org Wed Jul 23 01:58:55 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Jul 23 01:59:04 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <34182EE347F910EA2A64DF03@utd65257.utdallas.edu> References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> <20080722162024.GA1279@lava.net> <48860CBA.6010903@FreeBSD.org> <488615F5.80405@infracaninophile.co.uk> <4886188E.6090805@FreeBSD.org> <34182EE347F910EA2A64DF03@utd65257.utdallas.edu> Message-ID: <20080723015855.GA36829@eos.sc1.parodius.com> On Tue, Jul 22, 2008 at 12:52:15PM -0500, Paul Schmehl wrote: > --On Tuesday, July 22, 2008 10:27:42 -0700 Doug Barton > wrote: > >> Matthew Seaman wrote: >> >>> Are there any plans to enable DNSSEC capability in the resolver built >>> into FreeBSD? >> >> The server is already capable of it. I'm seriously considering enabling the >> define to make the CLI tools (dig/host/nslookup) capable as well (there is >> already an OPTION for this in ports). >> >> The problem is that _using_ DNSSEC requires configuration changes in >> named.conf, and more importantly, configuration of "trust anchors" (even for >> the command line stuff) since the root is not signed. It's not hard to do >> that with the DLV system that ISC has in place, and I would be willing to >> create a conf file that shows how to do that for users to include if they >> choose to. I am not comfortable enabling it by default (not yet anyway), it's >> too big of a POLA issue. >> > > I just played around with it recently. It's not that easy to understand > initially *and* the trust anchors thing is a royal PITA. I completely agree on both points. To give you some idea of how much of an annoyance DNSSEC is, a friend of mine who used to work at Nominum stated that one of their software engineers, when signing, on had a clause appended to his employee agreement stating he would not be required to work on DNSSEC code, due to the absurd complexity of it all. For what it's worth, I went looking into DNSSEC last week, and after a few hours of skimming then reading, I concluded it's over-engineered and adds too much hassle for it to be considered a worthwhile "upgrade". In no way am I putting down the need for security, but the added complexity is what's going to turn people off to this, and because of such, very likely ignore it. You can call me ignorant/lazy -- I welcome such -- but I guarantee others feel the same way. DNS, for most people, is expected to be a "simple thing". They like it to be simple, and it's generally not rocket science. People have come to expect that, and while I think most are willing to accept change (take TSIG for example), it has to be easy to set up, simple to maintain, troubleshooting outlined step-by-step with easy-to-follow output, and in the case of a hard failure, the documentation easy to understand. This is not the case with DNSSEC; I feel like I'm setting up a bloody IPsec VPN. IPsec: AH or ESP across tunnel/transport using AES or 3DES with IKE/ISAKMP or static secrets, and don't forget GRE. DNSSEC: trust anchors with lookaside validation, SEP, DNSKEY, DLV, RRSIG, ZSK and its phases, KSK and its phases, etc... There's the "how to make it work in 6 minutes" PDF by the ISC, which appears to have been made/used for/as presentation material -- meaning you're missing the verbal explanations that go along with each item. There's also inconsistencies in configuration syntax within the PDF, making you wonder how much time someone put into it. There also appears to be an assumption made throughout all of the documentation that I've read: that your recursive and non-recursive DNS servers are separate. I'm still trying to understand why that assumption is made; sure, the majority of the "enterprise-class" world has segregated DNS servers (public authoritative vs. internal recursive resolvers), but the runner-up would be administrators who simply run BIND on their servers and use two simple configuration lines: acl "trusted" { my.net.block/cidr; 127.0.0.1; }; options { allow-recursion { trusted; } }; If DNSSEC really requires that your recursive and non-recursive servers be separate, then it will fail. And I still cannot get over the fact that this "HOWTO" is 47 pages long: http://www.nlnetlabs.nl/dnssec_howto/ Let's not forget this packet flow diagram, which is quite legible and easy to understand: http://www.nlnetlabs.nl/dnssec_howto/dnspktdemo.png > Once you implement DNSSEC you *must* generate keys every 30 days. So, I > think, if you're going to enable it by default, there needs to be a > script in periodic that will do all the magic to change keys every 30 > days. Maybe put vars in /etc/rc.conf to override the default key lengths > and other portions of the commands that could change per installation. I believe you're talking about re-signing the zones. The duration is adjustable, but 30 days appears to be what the documentation and howto site defaults to/recommends using: http://www.isc.org/sw/bind/arm95/man.dnssec-signzone.html http://www.nlnetlabs.nl/dnssec_howto/#x1-240002.4 > But until root is signed, it's not worth it for those of us who don't > have dedicated staff doing dns only. Bingo. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From alfred at freebsd.org Wed Jul 23 02:30:50 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Wed Jul 23 02:30:57 2008 Subject: FreeBSD 7.1 and BIND exploit In-Reply-To: <20080723015855.GA36829@eos.sc1.parodius.com> References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> <20080722162024.GA1279@lava.net> <48860CBA.6010903@FreeBSD.org> <488615F5.80405@infracaninophile.co.uk> <4886188E.6090805@FreeBSD.org> <34182EE347F910EA2A64DF03@utd65257.utdallas.edu> <20080723015855.GA36829@eos.sc1.parodius.com> Message-ID: <20080723021146.GO76659@elvis.mu.org> Jeremy, I can't agree with you more, for some reason crypto people seem to believe that in order to drive a car you should have to know how to rebuild a carb. Makes no sense. The funny part is that your comparison with setting up IPsec is the same thing that I compare these things to. Back in 2003 I tried to set up a "shared key" IPSEC dhcp at home, basically I'd just make a key and sneaker-net it to the hosts that wanted to connect, after about 6 hours I just gave up and used "wep". *sigh* -Alfred * Jeremy Chadwick [080722 18:59] wrote: > On Tue, Jul 22, 2008 at 12:52:15PM -0500, Paul Schmehl wrote: > > --On Tuesday, July 22, 2008 10:27:42 -0700 Doug Barton > > wrote: > > > >> Matthew Seaman wrote: > >> > >>> Are there any plans to enable DNSSEC capability in the resolver built > >>> into FreeBSD? > >> > >> The server is already capable of it. I'm seriously considering enabling the > >> define to make the CLI tools (dig/host/nslookup) capable as well (there is > >> already an OPTION for this in ports). > >> > >> The problem is that _using_ DNSSEC requires configuration changes in > >> named.conf, and more importantly, configuration of "trust anchors" (even for > >> the command line stuff) since the root is not signed. It's not hard to do > >> that with the DLV system that ISC has in place, and I would be willing to > >> create a conf file that shows how to do that for users to include if they > >> choose to. I am not comfortable enabling it by default (not yet anyway), it's > >> too big of a POLA issue. > >> > > > > I just played around with it recently. It's not that easy to understand > > initially *and* the trust anchors thing is a royal PITA. > > I completely agree on both points. To give you some idea of how much of > an annoyance DNSSEC is, a friend of mine who used to work at Nominum > stated that one of their software engineers, when signing, on had a > clause appended to his employee agreement stating he would not be > required to work on DNSSEC code, due to the absurd complexity of it all. > > For what it's worth, I went looking into DNSSEC last week, and after a > few hours of skimming then reading, I concluded it's over-engineered and > adds too much hassle for it to be considered a worthwhile "upgrade". In > no way am I putting down the need for security, but the added complexity > is what's going to turn people off to this, and because of such, very > likely ignore it. You can call me ignorant/lazy -- I welcome such -- > but I guarantee others feel the same way. > > DNS, for most people, is expected to be a "simple thing". They like it > to be simple, and it's generally not rocket science. People have come > to expect that, and while I think most are willing to accept change > (take TSIG for example), it has to be easy to set up, simple to > maintain, troubleshooting outlined step-by-step with easy-to-follow > output, and in the case of a hard failure, the documentation easy to > understand. > > This is not the case with DNSSEC; I feel like I'm setting up a bloody > IPsec VPN. IPsec: AH or ESP across tunnel/transport using AES or 3DES > with IKE/ISAKMP or static secrets, and don't forget GRE. DNSSEC: trust > anchors with lookaside validation, SEP, DNSKEY, DLV, RRSIG, ZSK and its > phases, KSK and its phases, etc... > > There's the "how to make it work in 6 minutes" PDF by the ISC, which > appears to have been made/used for/as presentation material -- meaning > you're missing the verbal explanations that go along with each item. > There's also inconsistencies in configuration syntax within the PDF, > making you wonder how much time someone put into it. > > There also appears to be an assumption made throughout all of the > documentation that I've read: that your recursive and non-recursive DNS > servers are separate. I'm still trying to understand why that > assumption is made; sure, the majority of the "enterprise-class" world > has segregated DNS servers (public authoritative vs. internal recursive > resolvers), but the runner-up would be administrators who simply run > BIND on their servers and use two simple configuration lines: > > acl "trusted" { my.net.block/cidr; 127.0.0.1; }; > options { > allow-recursion { trusted; } > }; > > If DNSSEC really requires that your recursive and non-recursive servers > be separate, then it will fail. > > And I still cannot get over the fact that this "HOWTO" is 47 pages long: > http://www.nlnetlabs.nl/dnssec_howto/ > > Let's not forget this packet flow diagram, which is quite legible and > easy to understand: > http://www.nlnetlabs.nl/dnssec_howto/dnspktdemo.png > > > Once you implement DNSSEC you *must* generate keys every 30 days. So, I > > think, if you're going to enable it by default, there needs to be a > > script in periodic that will do all the magic to change keys every 30 > > days. Maybe put vars in /etc/rc.conf to override the default key lengths > > and other portions of the commands that could change per installation. > > I believe you're talking about re-signing the zones. The duration is > adjustable, but 30 days appears to be what the documentation and howto > site defaults to/recommends using: > > http://www.isc.org/sw/bind/arm95/man.dnssec-signzone.html > http://www.nlnetlabs.nl/dnssec_howto/#x1-240002.4 > > > But until root is signed, it's not worth it for those of us who don't > > have dedicated staff doing dns only. > > Bingo. > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking