Re: interrupt storm
Daniel Gerzo wrote: Hello Marat, Dan, I suppose you guys are running amd64? Could you try i386? AFAIR the interrupt storms have gone away after I moved my MSI machine to i386 on an affected box. Yes, amd64. unfortunately, moving to i386 is not an option. at least for me. I have 4 GBytes of memory and I'm planning to install another 4 GBytes asap. -- SY, Marat ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
How to get djbdns to start early enough to satisfy ntpd at boot?
Hi there, I've been a happy djbdns+tinydns user for many, many years. I want to keep using it, so answers of the form bletch! Use ISC BIND the way BSD intended will be ignored :-) Having said that, one annoying consequence of my transition some time ago to using ntpd, rather than just setting the clock once-off with ntpdate as I used to, is that the /etc/rc.d mechanism starts ntpd before /usr/local/etc/rc.d/svscan.sh starts svscan, which starts /services/dnscache. That wouldn't matter if ntpd was a bit sensible and just kept trying to find its nomminated servers, but it gives up and just sits there not synchronising time from any reference. So I have to remember to manually /etc/rc.d/ntpd restart every time I reboot. So: does anyone know how to modify the boot-time order so that svscan starts at (or before) the point in the boot cycle where BIND would, on other systems? I suspect that it should be possible by changing the PROVIDE: in svscan.sh to include one of the things REQUIRE:'d by ntpd. Or perhaps the REQUIRE: LOGIN in svscan.sh is incompatible with the BEFORE: LOGIN in ntpd? Has any other user of dnscache encountered and solved this problem? Cheers, Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: lenovo t400 does not start 7.1
On Thu, Jan 15, 2009 at 8:28 AM, Ganbold ganb...@micom.mng.net wrote: Harald Servat wrote: However, let me tell you what I've found now (I tried these options in the following order). ** a) I've started with option 2 (ACPI disabled) because I read somewhere that FreeBSD did not support Lenovo T400's ACPI. The system boots and freezes after showing (something related with Timecounters) md0: Preloaded image /boot/mfsroot 4194304 bytes at some address Trying to mount root from ufs:/dev/md0 b) When I chose option Safe mode (3, IIRC) Happens the same as a) c) I've tried with verbose logging (option 5, I think) The initialization dumps a lot of debugging information and after some time, it brings me the Choosing region screen. I didn't get further because I will not install the system right now (I have to prepare the backups first ;) ) I tried to use ScrollLock + RePag to look for the conflicting line found in a) or any suspicious message but it didn't work. I also tried with an holographic shell and the livefs without luck. d) I also tried option 1 (default boot) -- just in order to check. It also worked. Like c) but without debugging information. ** So, right now, it seems that the system allows me to begin the installation of FreeBSD 7.1 amd64 on the T400 but I'm scared due to the lack of functionality of options 2 and 3. This behavior is not normal, is it? Any thoughts about this? I'm using Integrated graphics right now, didn't try option 2,3. I have to find firewire cable to check whether there is something going on when booting with Discrete graphics. You can install FreeBSD with integrated graphics and configure network, ssh etc. and then later try to boot with Discrete graphics. As boot screen stops with |, and as kib@ suggests some time later you can check the machine from the network whether you can login to it via ssh. Also you can try to ping at that time. You can also observe hard disk activity light. If you can ping or ssh then I guess it means boot works and it loads kernel, but something is not allowing to display on the screen. Ganbold -- BACHELOR: A guy who is footloose and fiancee-free. I don't remember if the HD led shows activity when booting from the DVD, but it's worth to try once the system has been installed. I'll keep you informed once I install the system. Thank you Ganbold et altri. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: kernel panics when connected through wpi to apple extreme ap
On 1/15/09, Marc Peters m...@sanity.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hello list, i have a lenovo t60 with an integrated intel 3945ABG wireless chipset. when i was running 7.1-PRERELEASE i realised that the network connection of my wpi died after some time when connected to the mention apple access point. i had to restart the card and everything went fine, for some time (about half an hour). since 7.1-RELEASE and now with 7.1-STABLE the kernel panics with a fatal trap and dumps it's core after some minutes (this output ist from -RELEASE-p1, but it's identical to the one i got from -STABLE): Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x fault code= supervisor read, page not present instruction pointer = 0x20:0xc0deadfc stack pointer = 0x28:0xe58bbbe0 frame pointer = 0x28:0xe58bbc9c code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 25 (wpi0 taskq) trap number = 12 panic: page fault cpuid = 0 Uptime: 6m 14s Physical memory: 2034 MB Dumping 149 MB: 134 118 192 86 70 65 38 22 6 Dump complete Automatic reboot in 15 seconds - press a key on the console to abort when i run this box connected to a netgear-ap i have at home, everything is fine (and was before, no panics, no connection dropping). i have the dump at hand, but since it's 150 MB i won't send it around via mail. if anyone is interested, i can upload it somewhere and send the link. anyone any ideas? Enable textdump(8) and post bt output from debuger once panic happen. (I'm not going to download 150MB) marc dmesg: Copyright (c) 1992-2009 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.1-STABLE #0: Wed Jan 14 13:23:00 CET 2009 r...@lappi.agentur.local:/usr/obj/usr/src/sys/GENERIC_DRM Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz (1995.02-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6f6 Stepping = 6 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x2010NX,LM AMD Features2=0x1LAHF Cores per package: 2 real memory = 2146238464 (2046 MB) avail memory = 2090221568 (1993 MB) ACPI APIC Table: LENOVO TP-79 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI Warning (tbfadt-0505): Optional field Gpe1Block has zero address or length:0102C/0 [20070320] ioapic0: Changing APIC ID to 1 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: LENOVO TP-79 on motherboard acpi0: [ITHREAD] acpi_ec0: Embedded Controller: GPE 0x1c, ECDT port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 7ff0 (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900 acpi_lid0: Control Method Lid Switch on acpi0 acpi_button0: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display port 0x2000-0x20ff mem 0xd800-0xdfff,0xee10-0xee10 irq 16 at device 0.0 on pci1 drm0: ATI Mobility Radeon X1400 on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.29.0 20080613 hdac0: Intel 82801G High Definition Audio Controller mem 0xee40-0xee403fff irq 17 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20090110_0123 hdac0: [ITHREAD] pcib2: ACPI PCI-PCI bridge irq 20 at device 28.0 on pci0 pci2: ACPI PCI bus on pcib2 em0: Intel(R) PRO/1000 Network Connection 6.9.6 port 0x3000-0x301f mem 0xee00-0xee01 irq 16 at device 0.0 on pci2 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:16:41:e3:4a:ff pcib3: ACPI PCI-PCI bridge irq 21 at device 28.1 on pci0 pci3: ACPI PCI bus on pcib3 wpi0: Intel(R) PRO/Wireless 3945ABG mem 0xedf0-0xedf00fff irq 17 at device 0.0 on pci3 wpi0: Ethernet address: 00:19:d2:07:cf:36 wpi0: [ITHREAD] pcib4: ACPI PCI-PCI bridge irq 22 at device 28.2 on pci0 pci4: ACPI PCI bus on pcib4 pcib5: ACPI
kernel panics when connected through wpi to apple extreme ap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hello list, i have a lenovo t60 with an integrated intel 3945ABG wireless chipset. when i was running 7.1-PRERELEASE i realised that the network connection of my wpi died after some time when connected to the mention apple access point. i had to restart the card and everything went fine, for some time (about half an hour). since 7.1-RELEASE and now with 7.1-STABLE the kernel panics with a fatal trap and dumps it's core after some minutes (this output ist from -RELEASE-p1, but it's identical to the one i got from -STABLE): Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x fault code = supervisor read, page not present instruction pointer = 0x20:0xc0deadfc stack pointer = 0x28:0xe58bbbe0 frame pointer = 0x28:0xe58bbc9c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 25 (wpi0 taskq) trap number = 12 panic: page fault cpuid = 0 Uptime: 6m 14s Physical memory: 2034 MB Dumping 149 MB: 134 118 192 86 70 65 38 22 6 Dump complete Automatic reboot in 15 seconds - press a key on the console to abort when i run this box connected to a netgear-ap i have at home, everything is fine (and was before, no panics, no connection dropping). i have the dump at hand, but since it's 150 MB i won't send it around via mail. if anyone is interested, i can upload it somewhere and send the link. anyone any ideas? marc dmesg: Copyright (c) 1992-2009 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.1-STABLE #0: Wed Jan 14 13:23:00 CET 2009 r...@lappi.agentur.local:/usr/obj/usr/src/sys/GENERIC_DRM Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz (1995.02-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6f6 Stepping = 6 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x2010NX,LM AMD Features2=0x1LAHF Cores per package: 2 real memory = 2146238464 (2046 MB) avail memory = 2090221568 (1993 MB) ACPI APIC Table: LENOVO TP-79 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI Warning (tbfadt-0505): Optional field Gpe1Block has zero address or length:0102C/0 [20070320] ioapic0: Changing APIC ID to 1 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: LENOVO TP-79 on motherboard acpi0: [ITHREAD] acpi_ec0: Embedded Controller: GPE 0x1c, ECDT port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 7ff0 (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900 acpi_lid0: Control Method Lid Switch on acpi0 acpi_button0: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display port 0x2000-0x20ff mem 0xd800-0xdfff,0xee10-0xee10 irq 16 at device 0.0 on pci1 drm0: ATI Mobility Radeon X1400 on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.29.0 20080613 hdac0: Intel 82801G High Definition Audio Controller mem 0xee40-0xee403fff irq 17 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20090110_0123 hdac0: [ITHREAD] pcib2: ACPI PCI-PCI bridge irq 20 at device 28.0 on pci0 pci2: ACPI PCI bus on pcib2 em0: Intel(R) PRO/1000 Network Connection 6.9.6 port 0x3000-0x301f mem 0xee00-0xee01 irq 16 at device 0.0 on pci2 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:16:41:e3:4a:ff pcib3: ACPI PCI-PCI bridge irq 21 at device 28.1 on pci0 pci3: ACPI PCI bus on pcib3 wpi0: Intel(R) PRO/Wireless 3945ABG mem 0xedf0-0xedf00fff irq 17 at device 0.0 on pci3 wpi0: Ethernet address: 00:19:d2:07:cf:36 wpi0: [ITHREAD] pcib4: ACPI PCI-PCI bridge irq 22 at device 28.2 on pci0 pci4: ACPI PCI bus on pcib4 pcib5: ACPI PCI-PCI bridge irq 23 at device 28.3 on pci0 pci12: ACPI PCI bus on pcib5 uhci0: UHCI (generic) USB controller port 0x1800-0x181f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: UHCI (generic) USB controller on uhci0
Re: How to get djbdns to start early enough to satisfy ntpd at boot?
Andrew Reilly wrote: So: does anyone know how to modify the boot-time order so that svscan starts at (or before) the point in the boot cycle where BIND would, on other systems? I suspect that it should be possible by changing the PROVIDE: in svscan.sh to include one of the things REQUIRE:'d by ntpd. Or perhaps the REQUIRE: LOGIN in svscan.sh is incompatible with the BEFORE: LOGIN in ntpd? I think BEFORE: ntpd should be sufficient. 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 Unix gives you just enough rope to hang yourself -- and then a couple of more feet, just to be sure. -- Eric Allman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: How to get djbdns to start early enough to satisfy ntpd at boot?
Quoth Andrew Reilly andrew-free...@areilly.bpc-users.org:
So: does anyone know how to modify the boot-time order so that
svscan starts at (or before) the point in the boot cycle where
BIND would, on other systems? I suspect that it should be
possible by changing the PROVIDE: in svscan.sh to include one of
the things REQUIRE:'d by ntpd. Or perhaps the REQUIRE: LOGIN in
svscan.sh is incompatible with the BEFORE: LOGIN in ntpd?
Has any other user of dnscache encountered and solved this
problem?
I have, in my svscan.sh,
# PROVIDE: svscan
# REQUIRE: SERVERS cleanvar
and I also have a /usr/local/etc/rc.d/dnscache which looks like
#!/bin/sh
# PROVIDE: named
# REQUIRE: svscan
. /etc/rc.subr
. /usr/local/etc/svc.subr
name=dnscache
rcvar=`set_rcvar`
: ${dnscache_enable:=NO}
load_rc_config $name
load_svc_subr_config
run_rc_command $1
and a /usr/local/etc/svc.subr as attached. It's somewhat more general
than is needed for dnscache, as I also use it to start qmail.
Basically: the PROVIDE: named line is needed to get dnscache up before
ntpd, and the REQUIRE: LOGIN line needs to be changed.
Ben
#
# Subroutines for handling services under the control of svscan(8).
# Requires rc.subr is loaded first.
#
load_svc_subr_config () {
load_rc_config_var svscan svscan_servicedir
: ${svscan_servicedir:=/var/service}
: ${svc:=/usr/local/bin/svc}
: ${svok:=/usr/local/bin/svok}
: ${svstat:=/usr/local/bin/svstat}
: ${svcname:=${name}}
: ${service_dir:=${svscan_servicedir}/${svcname}}
: ${svok_timeout:=30}
: ${svstat_timeout:=30}
: ${start_cmd:=svc_subr_start}
: ${stop_cmd:=svc_subr_stop}
: ${restart_cmd:=svc_subr_restart}
: ${extra_commands:=status reload flush}
: ${status_cmd:=svc_subr_status}
: ${reload_cmd:=svc_subr_reload}
: ${flush_cmd:=svc_subr_flush}
}
svc_subr_isup () {
$svstat $1 | grep -q : up
}
svc_subr_isdown () {
$svstat $1 | grep -q : down
}
svc_subr_waitfor () {
local n check timeout err
check=$1
timeout=$2
err=$3
n=0
while [ $n -lt $timeout ] ! $check $service_dir
do
sleep 1
n=$(( n + 1 ))
done
if ! $check $service_dir
then
echo $err 2
exit 1
fi
}
svc_subr_start () {
echo -n Checking ${name} is up
svc_subr_waitfor $svok $svok_timeout \
supervise is not running in ${service_dir}!
$svc -u $service_dir
svc_subr_waitfor svc_subr_isup $svstat_timeout \
${service_dir} won't come up!
echo .
}
svc_subr_stop () {
echo -n Bringing ${name} down
$svc -d $service_dir
svc_subr_waitfor svc_subr_isdown $svstat_timeout \
${service_dir} won't come down, trying SIGKILL
svc -k $service_dir
svc_subr_waitfor svc_subr_isdown $svstat_timeout \
${service_dir} won't come down!
echo .
}
svc_subr_restart () {
echo -n Sending ${name} a SIGTERM
$svc -t $service_dir
echo .
}
svc_subr_reload () {
echo -n Sending ${name} a SIGHUP
$svc -h $service_dir
echo .
}
svc_subr_flush () {
echo -n Sending ${name} a SIGALRM
$svc -a $service_dir
echo .
}
svc_subr_status () {
$svstat $service_dir
}
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: interrupt storm
Marat N.Afanasyev wrote: Daniel Gerzo wrote: Hello Marat, Dan, I suppose you guys are running amd64? Could you try i386? AFAIR the interrupt storms have gone away after I moved my MSI machine to i386 on an affected box. Yes, amd64. unfortunately, moving to i386 is not an option. at least for me. I have 4 GBytes of memory and I'm planning to install another 4 GBytes asap. FWIW, I also have 4GB RAM. This box is destined to be a jail server for running regression testing of various projects (e.g Bacula). -- Dan Langille BSDCan - The Technical BSD Conference : http://www.bsdcan.org/ PGCon - The PostgreSQL Conference: http://www.pgcon.org/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: interrupt storm
kernel: interrupt storm detected on irq22:; throttling interrupt source Opening the case, reading the m/b: K9A2 Platinum MSI I hadnt been paying much attention to this thread, but just to let you know that I also saw the same thing on this machine which has an MSI 790FX Platinum motherboard. It was also irq22, and I am also running amd64. In my case I simply disabled the onboard ethernet (which I wasnt using) and the problem went away - but then I only saw the problem once, it wasnt a regular occurrance. If you have an alternative ether card you can drop in thn you could try that... I've never had any problem running FreeBSD on MSI boards, but I recently purchased a new 790GX board, and that will not boot 7.1. Will oput in a PR about that when I have sorted my other 7.1 woes though :-) -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: How to get djbdns to start early enough to satisfy ntpd at boot?
On Thu, Jan 15, 2009 at 12:14 AM, Andrew Reilly andrew-free...@areilly.bpc-users.org wrote: Hi there, I've been a happy djbdns+tinydns user for many, many years. I want to keep using it, so answers of the form bletch! Use ISC BIND the way BSD intended will be ignored :-) Having said that, one annoying consequence of my transition some time ago to using ntpd, rather than just setting the clock once-off with ntpdate as I used to, is that the /etc/rc.d mechanism starts ntpd before /usr/local/etc/rc.d/svscan.sh starts svscan, which starts /services/dnscache. That wouldn't matter if ntpd was a bit sensible and just kept trying to find its nomminated servers, but it gives up and just sits there not synchronising time from any reference. So I have to remember to manually /etc/rc.d/ntpd restart every time I reboot. So: does anyone know how to modify the boot-time order so that svscan starts at (or before) the point in the boot cycle where BIND would, on other systems? I suspect that it should be possible by changing the PROVIDE: in svscan.sh to include one of the things REQUIRE:'d by ntpd. Or perhaps the REQUIRE: LOGIN in svscan.sh is incompatible with the BEFORE: LOGIN in ntpd? Has any other user of dnscache encountered and solved this problem? I use the following in svscan.sh, no problems with ntpdate or any other service: # PROVIDE: svscan # REQUIRE: FILESYSTEMS netif pf # BEFORE: routing - Max ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: How to get djbdns to start early enough to satisfy ntpd at boot?
On Thu, Jan 15, 2009 at 07:22:39AM -0500, Maxim Khitrov wrote: On Thu, Jan 15, 2009 at 12:14 AM, Andrew Reilly andrew-free...@areilly.bpc-users.org wrote: [snip] So: does anyone know how to modify the boot-time order so that svscan starts at (or before) the point in the boot cycle where BIND would, on other systems? I suspect that it should be possible by changing the PROVIDE: in svscan.sh to include one of the things REQUIRE:'d by ntpd. Or perhaps the REQUIRE: LOGIN in svscan.sh is incompatible with the BEFORE: LOGIN in ntpd? Has any other user of dnscache encountered and solved this problem? I use the following in svscan.sh, no problems with ntpdate or any other service: # PROVIDE: svscan # REQUIRE: FILESYSTEMS netif pf # BEFORE: routing Thanks a lot for that! I'll test it on one of my own machines[1] and I'll incorporate it into the port's options in a couple of days. G'luck, Peter [1] Yes, Andrew, I have the same problem on one machine which is only restarted very rarely, so I just drop a curse and restart ntpd and I couldn't be bothered to actually automate it... sorry for that! -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 The rest of this sentence is written in Thailand, on pgpEivyOr2aKU.pgp Description: PGP signature
Re: named won't start
Thanks for getting back to me... I guess I was a little panicy when I entered my note, I didn't explain much about what I'd already done. There was no named running, 'ps ax | grep named' showed only my grep and syslog. 'rndc' simply returns a connection refused error, I assume this is a poor excuse for an error mesage that really indicates that there is no named running to talk to. I believe the 'in use' message is an artifact of the first failure as there is definately no named running. I've just tried named-checkconf (I didn't know about that one -- thank you!) it says nothing, returns zero. Didn't help -- but thanks for trying! Doug Barton wrote: Mike Lempriere wrote: loading configuration: address in use This error generally means that the old named is still running. Try 'rndc stop', and then do 'ps -ax | grep named'. If you still see something running do '/etc/rc.d/named stop' check ps again, then when you're sure no other named is running do '/etc/rc.d/named start' I believe I did an accurate merge of my named.conf file. run named-checkconf to be sure that's not your problem. hope this helps, Doug -- Mike Lempriere- Home: m...@vintners.net Phone: 206-780-2146 Cellphone: 206-200-5902; text pager: mikel...@tmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: named won't start
I'm not real clear on what item 6 means. However all of my specified zones have at least one NS and one A record. Does this mean I'm Ok? Sergey N. Voronkov wrote: On Wed, Jan 14, 2009 at 08:11:27PM -0800, Mike Lempriere wrote: From /var/log/messages: starting BIND 9.4.3-P1 -t /var/named -u bind could not get query source dispatcher (0.0.0.0#53) loading configuration: address in use exiting (due to fatal error) I had just updated from 5-stable (at 5.5) to 6-stable (at 6.4). Upon today's upgrade I got to 7.1. Everything else seems to be be working (the machine is basically a webserver), except named. apache is serving up pages, but only until my TTL times out... I so no errors in the builds or installs. I foolwed the instructions in UPDATING. I believe I did an accurate merge of my named.conf file. This is a production machine, with paying customers -- please help! Thank you! http://www.fiveanddime.net/bind-9/bind-9.3.1/doc/misc/migration..html 6. No Information Leakage between Zones Sites that were relying on this BIND 8 behaviour need to add any omitted glue NS records, and any necessary glue A records, to the parent zone. Did You insert NS and A records into parent zone files? Serg N. Voronkov, Sibitex Ltd. -- Mike Lempriere- Home: m...@vintners.net Phone: 206-780-2146 Cellphone: 206-200-5902; text pager: mikel...@tmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: named won't start -- solved
Got it! Thanks Sergey, the migration doc you pinted out below showed me to the real problem. I had an old directive: query-source address * port 53; Commenting this out now allows named to start. I'm getting a working directory is not writable error now, but that's something I should be able to figure out myself! Interestingly enough, I have this same declaration on my secondary machine. That machine just went through the same process, and it did not have this problem... Thanks for all the help guys -- much appreciated! Sergey N. Voronkov wrote: On Wed, Jan 14, 2009 at 08:11:27PM -0800, Mike Lempriere wrote: From /var/log/messages: starting BIND 9.4.3-P1 -t /var/named -u bind could not get query source dispatcher (0.0.0.0#53) loading configuration: address in use exiting (due to fatal error) I had just updated from 5-stable (at 5.5) to 6-stable (at 6.4). Upon today's upgrade I got to 7.1. Everything else seems to be be working (the machine is basically a webserver), except named. apache is serving up pages, but only until my TTL times out... I so no errors in the builds or installs. I foolwed the instructions in UPDATING. I believe I did an accurate merge of my named.conf file. This is a production machine, with paying customers -- please help! Thank you! http://www.fiveanddime.net/bind-9/bind-9.3.1/doc/misc/migration..html 6. No Information Leakage between Zones Sites that were relying on this BIND 8 behaviour need to add any omitted glue NS records, and any necessary glue A records, to the parent zone. Did You insert NS and A records into parent zone files? Serg N. Voronkov, Sibitex Ltd. -- Mike Lempriere- Home: m...@vintners.net Phone: 206-780-2146 Cellphone: 206-200-5902; text pager: mikel...@tmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: How to get djbdns to start early enough to satisfy ntpd at boot?
Hi, Andrew Reilly wrote: I've been a happy djbdns+tinydns user for many, many years. I want to keep using it, so answers of the form bletch! Use ISC BIND the way BSD intended will be ignored :-) ... Well, the other alternative is to ditch ntpd and go to clockspeed the way djb intended ... Regards, Jan :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: kernel panics when connected through wpi to apple extreme ap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi paul, msgbuf.txt: [snipping dmesg and startup-messages] Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x fault code = supervisor read, page not present instruction pointer = 0x20:0xc0e70dfc stack pointer = 0x28:0xe58bbbe0 frame pointer = 0x28:0xe58bbc9c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 25 (wpi0 taskq) ddb.txt (just bt output here): db bt Tracing pid 25 tid 100024 td 0xc5189af0 wpi_ops(c52c5000,1,c0b7cf36,0,0,...) at wpi_ops+0x89c taskqueue_run(c52ab200,c52ab21c,0,c0b7cf36,0,...) at taskqueue_run+0x175 taskqueue_thread_loop(c52c69b4,e58bbd38,0,0,0,...) at taskqueue_thread_loop+0xbb fork_exit(c07fb2b0,c52c69b4,e58bbd38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 - --- trap 0, eip = 0, esp = 0xe58bbd70, ebp = 0 --- version.txt: FreeBSD 7.1-STABLE #0: Thu Jan 15 13:51:12 CET 2009 r...@lappi.agentur.local:/usr/obj/usr/src/sys/DEBUG_DRM if you need more information, i will provide it. it took wpi some time to crash, so i stressed it a little bit with an ftp download and a buildworld through an ssh-screen. marc Paul B. Mahol schrieb: On 1/15/09, Marc Peters m...@sanity.de wrote: hello list, i have a lenovo t60 with an integrated intel 3945ABG wireless chipset. when i was running 7.1-PRERELEASE i realised that the network connection of my wpi died after some time when connected to the mention apple access point. i had to restart the card and everything went fine, for some time (about half an hour). since 7.1-RELEASE and now with 7.1-STABLE the kernel panics with a fatal trap and dumps it's core after some minutes (this output ist from -RELEASE-p1, but it's identical to the one i got from -STABLE): Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x fault code= supervisor read, page not present instruction pointer = 0x20:0xc0deadfc stack pointer = 0x28:0xe58bbbe0 frame pointer = 0x28:0xe58bbc9c code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 25 (wpi0 taskq) trap number = 12 panic: page fault cpuid = 0 Uptime: 6m 14s Physical memory: 2034 MB Dumping 149 MB: 134 118 192 86 70 65 38 22 6 Dump complete Automatic reboot in 15 seconds - press a key on the console to abort when i run this box connected to a netgear-ap i have at home, everything is fine (and was before, no panics, no connection dropping). i have the dump at hand, but since it's 150 MB i won't send it around via mail. if anyone is interested, i can upload it somewhere and send the link. anyone any ideas? Enable textdump(8) and post bt output from debuger once panic happen. (I'm not going to download 150MB) marc dmesg: Copyright (c) 1992-2009 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.1-STABLE #0: Wed Jan 14 13:23:00 CET 2009 r...@lappi.agentur.local:/usr/obj/usr/src/sys/GENERIC_DRM Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz (1995.02-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6f6 Stepping = 6 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x2010NX,LM AMD Features2=0x1LAHF Cores per package: 2 real memory = 2146238464 (2046 MB) avail memory = 2090221568 (1993 MB) ACPI APIC Table: LENOVO TP-79 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI Warning (tbfadt-0505): Optional field Gpe1Block has zero address or length:0102C/0 [20070320] ioapic0: Changing APIC ID to 1 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: LENOVO TP-79 on motherboard acpi0: [ITHREAD] acpi_ec0: Embedded Controller: GPE 0x1c, ECDT port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 7ff0 (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz
Re: more marvell marvels
On Fri, Jan 9, 2009 at 1:19 PM, Pyun YongHyeon pyu...@gmail.com wrote: On Fri, Jan 09, 2009 at 01:48:24PM +0200, Danny Braniss wrote: hi, the mb is asus P5K-VM, the onboard nic is, acccording to pciconf: ms...@pci0:1:0:0: class=0x02 card=0x81f81043 chip=0x436411ab rev=0x12 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = '88E8056 Yukon PCI-E Gigabit Ethernet Controller' class = network subclass = ethernet cap 01[48] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 03[50] = VPD cap 05[5c] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 legacy endpoint nothing new here, problems have been reported before, but: my very first attempt - after a very long time - of booting 7.1-stable, produced a panic because msk could not find its physio, by the time i had the serial console attached and working, that problem disappeared :-( now, after reboot, it sometimes hangs - because the net is not working, and only if I unplug the ethernet, (no signs of the driver seeing this), and replug things begin to work. btw, i had to set hw.msk.legacy_intr=1 to get things working. any patches for 7.1-stable to test? If memory serve me right you have Yukon EC Ultra with 88E1149 PHY, right? CURRENT has some stability fixes but the source wouldn't be compiled on stable/7 yet due to KPI differences. I have plan to add some features in next week which make it possible to use HEAD version on stable/7. I'm not sure the patch for 88E8040 could be applied to stable/7 but the patch has some fixes for link state handling. Would you give it try? http://people.freebsd.org/~yongari/msk/msk.88E8040.patch14 Note, the 88E8040 patch is not complete yet and may cause other problems too. -- 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-unsubscr...@freebsd.org Hi Pyun, are if_msk.c and if_mskreg.h from http://people.freebsd.org/~yongari/msk/ the patched version? With this files I get an error Message regarding MEXTADD(m, buf, MSK_JLEN, msk_jfree, buf, (struct msk_if_softc *)sc_if, 0, EXT_NET_DRV); Is there a buf, too much? I deleted the second buf, and I was able to compile the Kernel. But I can't assign an IP with dhcp because msk0 always goes up and down. This is my nic: pci3: domain=0, physical bus=3 found- vendor=0x11ab, dev=0x4354, revid=0x13 domain=0, bus=3, 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=5 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf020, size 14, enabled no...@pci0:3:0:0: class=0x02 card=0xca00144d chip=0x435411ab rev=0x13 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' class = network subclass = ethernet cap 01[48] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[5c] = MSI supports 1 message, 64 bit cap 10[c0] = PCI-Express 2 legacy endpoint Regards, ~ vb ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Big problems with 7.1 locking up :-(
Just an update on this - I tried the various kernels, but now the machine is not locking up at all. As I havent actually chnaged anything then this does not make me as happy as you might expect. I don;t know what to do now - I daare not upgrade the machines to an OS that I know locks, but if I cant make it lock then it is impossible to get any useful debugging info out of. maybe waiting for 7.2 is the best move... -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Big problems with 7.1 locking up :-(
On Thu, 15 Jan 2009, Pete French wrote: Just an update on this - I tried the various kernels, but now the machine is not locking up at all. As I havent actually chnaged anything then this does not make me as happy as you might expect. I don;t know what to do now - I daare not upgrade the machines to an OS that I know locks, but if I cant make it lock then it is impossible to get any useful debugging info out of. maybe waiting for 7.2 is the best move... Well, one slightly pessimistic (or realistic) view says that all software contains bugs, it's just a question of whether or not your workload and environment trigger those bugs in a noticeable way. Given the inconsistency of the symptoms, I wouldn't preclude something environmental: could it be that it was the bottom, or more likely, top box in a rack and that your air conditioning isn't quite as effective there when the outside temperature is above/below some threshold? Alternatively, could it be that the workload changed very slightly -- you're doing less DNS queries, or the network latency to the DNS server changed? Certainly, whoever gave the advise on checking BIOS revisions is right: you can spend a lot of time tracking down a bug to realize that one box has a slightly different BIOS rev and therefore does/doesn't suffer from an obscure SMI bug. In any case, if it starts to reproduceably recur, send out mail and we can see if we can track it down some more. BTW, did you establish if the version of iLo you have has a remote NMI? I seem to recall that some do, and being able to deliver an NMI is really quite valuable. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Big problems with 7.1 locking up :-(
Given the inconsistency of the symptoms, I wouldn't preclude something environmental: could it be that it was the bottom, or more likely, top box in a rack and that your air conditioning isn't quite as effective there when the outside temperature is above/below some threshold? It's a possibility - but the two machines which were exhibiting the fault are in Slough and Baton Rouge respectively, so under very diferent cliatic conditions. Howevere, something, has chhnaged to make it stop locking up! The USA one was doing it every couple of hours at the start of the week, and the UK on wouldnt last more than half an hour at one point. Alternatively, could it be that the workload changed very slightly -- you're doing less DNS queries, or the network latency to the DNS server changed? Also a possibility - that workload is entirely dependent on customer behaviour which is an unpredictable beast! Certainly, whoever gave the advise on checking BIOS revisions is right: you can spend a lot of time tracking down a bug to realize that one box has a slightly different BIOS rev and therefore does/doesn't suffer from an obscure SMI bug. Yes, thats next on my list - make sure they are all on the same version. In any case, if it starts to reproduceably recur, send out mail and we can see if we can track it down some more. BTW, did you establish if the version of iLo you have has a remote NMI? I seem to recall that some do, and being able to deliver an NMI is really quite valuable. OK, thanks. My iiLO2 appears to have the ability to generate an NMI oon demand, so that could be used if/whhen the fault crops up again. thanks, will let this lie for now and resurrect the thread when I can get some more useful data. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Big problems with 7.1 locking up :-(
On Thu, 15 Jan 2009, Pete French wrote: In any case, if it starts to reproduceably recur, send out mail and we can see if we can track it down some more. BTW, did you establish if the version of iLo you have has a remote NMI? I seem to recall that some do, and being able to deliver an NMI is really quite valuable. OK, thanks. My iiLO2 appears to have the ability to generate an NMI oon demand, so that could be used if/whhen the fault crops up again. thanks, will let this lie for now and resurrect the thread when I can get some more useful data. Excellent WRT NMI. As long as you have DDB, KDB, and BREAK_TO_DEBUGGER compiled into the kernel, generating that should reliably get you into the debugger. If it's possible to keep running with INVARIANTS and WITNESS, or just INVARIANTS if WITNESS slows things down too much, that would be desirable. You might want to give the NMI a test run just to make sure it behaves as you think it should, though -- be aware that if DDB/KDB aren't compiled into the kernel, then an NMI will panic the box. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Big problems with 7.1 locking up :-(
desirable. You might want to give the NMI a test run just to make sure it behaves as you think it should, though -- be aware that if DDB/KDB aren't compiled into the kernel, then an NMI will panic the box. Unfortunately it does this... http://toybox.twisted.org.uk/~pete/71_nmi1.png That is locked up too - hitting return does nothing. I was hoping it was just garbled output but had actually gone to the debugger. Apparently not. Thats with a config file containing KDB, DDB and BREAK_TO_DEBUGGER, which does work as I have tested it with CTRL_ALT_ESC. M -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Big problems with 7.1 locking up :-(
On Thu, 15 Jan 2009, Pete French wrote: desirable. You might want to give the NMI a test run just to make sure it behaves as you think it should, though -- be aware that if DDB/KDB aren't compiled into the kernel, then an NMI will panic the box. Unfortunately it does this... http://toybox.twisted.org.uk/~pete/71_nmi1.png That is locked up too - hitting return does nothing. I was hoping it was just garbled output but had actually gone to the debugger. Apparently not. Thats with a config file containing KDB, DDB and BREAK_TO_DEBUGGER, which does work as I have tested it with CTRL_ALT_ESC. Er, that's rather upsetting. John, do you have any ideas about this? Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
On 2009-01-14 00:05, Jung-uk Kim wrote: Can you try one of the following patches? -CURRENT: http://people.freebsd.org/~jkim/re/re.current.diff -STABLE: http://people.freebsd.org/~jkim/re/re.stable.diff These patches contain all patches suggested by me and yongari and an additional patch, which may (or may not) decrease the initial setup time. I have applied the -STABLE patch, and while this doesn't have much influence on the initial setup time, it does seem to solve the problem of not being able to send any packets. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
zfs drive keeps failing between export and import
I have a zpool that consists for a two-drive mirror. The two times I took the zpool offline, I had to resilver one of the drives (the same drive both times) when I imported it back. All drives in the pool show no read, write, or checksum errors and are new, so I'm looking to a software problem before hardware. Both drives are encrypted geli devices. I tried to reproduce the error with 1GB disk images (vs 1TB), mdconfig, geli, and zpool, but no luck; importing and exporting work fine. Here's the history of the pool: History for 'tank': 2009-01-07.19:06:53 zpool create tank mirror /dev/ad8.eli /dev/ad10.eli 2009-01-12.12:34:20 zpool export -f tank 2009-01-12.12:38:12 zpool import tank 2009-01-12.12:41:43 zpool replace tank 5217673744218787970 /dev/ad10.eli 2009-01-12.21:48:12 zpool export tank 2009-01-13.20:20:27 zpool import tank 2009-01-13.20:22:18 zpool replace tank 2270010454322471606 /dev/ad10.eli 2009-01-14.08:04:52 zpool scrub tank 2009-01-14.08:08:38 zpool scrub -s tank When I do zdb tank, I get zdb: can't open tank: No such file or directory. Somehow, I did the same command earlier and got pointed to http://www.sun.com/msg/ZFS-8000-EY There's a chance this drive (ad10 or ad10.eli) was in a zpool before this one that never got destroyed. Ideas? Any more information I should provide? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Big problems with 7.1 locking up :-(
On Thursday 15 January 2009 12:49:11 pm Robert Watson wrote: On Thu, 15 Jan 2009, Pete French wrote: desirable. You might want to give the NMI a test run just to make sure it behaves as you think it should, though -- be aware that if DDB/KDB aren't compiled into the kernel, then an NMI will panic the box. Unfortunately it does this... http://toybox.twisted.org.uk/~pete/71_nmi1.png That is locked up too - hitting return does nothing. I was hoping it was just garbled output but had actually gone to the debugger. Apparently not. Thats with a config file containing KDB, DDB and BREAK_TO_DEBUGGER, which does work as I have tested it with CTRL_ALT_ESC. Er, that's rather upsetting. John, do you have any ideas about this? The rest of the thread I have no context on still. The garbage is due to competing panics I think. The problem is we don't single thread the printf's in 'trap_fatal()'. We should probably have some sort of simple spin lock thing in the x86 code to only allow 1 CPU at a time to run through that routine. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: zfs drive keeps failing between export and import
On Thu, 15 Jan 2009, David Ehrmann wrote: I have a zpool that consists for a two-drive mirror. The two times I took the zpool offline, I had to resilver one of the drives (the same drive both times) when I imported it back. All drives in the pool show no read, write, or checksum errors and are new, so I'm looking to a software problem before hardware. Both drives are encrypted geli devices. I tried to reproduce the error with 1GB disk images (vs 1TB), mdconfig, geli, and zpool, but no luck; importing and exporting work fine. Here's the history of the pool: History for 'tank': 2009-01-07.19:06:53 zpool create tank mirror /dev/ad8.eli /dev/ad10.eli 2009-01-12.12:34:20 zpool export -f tank 2009-01-12.12:38:12 zpool import tank 2009-01-12.12:41:43 zpool replace tank 5217673744218787970 /dev/ad10.eli 2009-01-12.21:48:12 zpool export tank 2009-01-13.20:20:27 zpool import tank 2009-01-13.20:22:18 zpool replace tank 2270010454322471606 /dev/ad10.eli 2009-01-14.08:04:52 zpool scrub tank 2009-01-14.08:08:38 zpool scrub -s tank When I do zdb tank, I get zdb: can't open tank: No such file or directory. Somehow, I did the same command earlier and got pointed to http://www.sun.com/msg/ZFS-8000-EY There's a chance this drive (ad10 or ad10.eli) was in a zpool before this one that never got destroyed. Ideas? Any more information I should provide? What does zdb /dev/ad10.eli show? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: How to get djbdns to start early enough to satisfy ntpd at boot?
On Thu, Jan 15, 2009 at 12:00:01PM +, Ben Morrow wrote: Quoth Andrew Reilly andrew-free...@areilly.bpc-users.org: So: does anyone know how to modify the boot-time order so that svscan starts at (or before) the point in the boot cycle where BIND would, on other systems? I suspect that it should be I have, in my svscan.sh, # PROVIDE: svscan # REQUIRE: SERVERS cleanvar and I also have a /usr/local/etc/rc.d/dnscache which looks like [snip] and a /usr/local/etc/svc.subr as attached. It's somewhat more general than is needed for dnscache, as I also use it to start qmail. Basically: the PROVIDE: named line is needed to get dnscache up before ntpd, and the REQUIRE: LOGIN line needs to be changed. Wow, those scripts are an extremely cool integration of the rcorder framework and the svscan framework. Could these be incorporated into the daemontools and djbdns ports as permanent goodness? I'll give them a try-out myself, pronto. (Might also investigate clockspeed, per Jan's suggestiong, too.) Cheers, Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Using FreeBSD Update to deploy system updates from custom builds
Daniel Bond wrote: Hi Tom, I don't know how much documentation there is on this, but if you are investigating this issue, maybe you would like to contribute/update some documentation on it? Royce gave me a link to the tools, http://www.freebsd.org/cgi/cvsweb.cgi/projects/freebsd-update-server/ reading through some of the scripts might give some clues. Regards, Daniel Bond. Thanks for the info, I will look into this over the next few weeks and see what I can come up with. Regards Tom Judge On Jan 14, 2009, at 6:05 AM, Tom Judge wrote: Hi, I was wondering if anyone was using freebsd-update to manage deployment of custom FreeBSD builds to there systems. Here is the scenario, I have 2 binary build servers at the moment (one for i386 and one for amd64) and currently we stage the deployments of updates on NFS servers at each site. We use make installworld/kernel to update the servers from read only src and obj NFS mounts. I'm now looking to remove the src trees from the NFS servers and possibly the obj trees and use freebsd-update to deploy and maintain the custom build installation and updates. So I have 2 questions: 1) Does this seem sensible? It seems within scope of what freebsd-update was designed to do. 2) How does one go about building the binary distributions that freebsd-update expects to be on the update server? Thanks Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: interrupt storm
Pete French wrote: kernel: interrupt storm detected on irq22:; throttling interrupt source Opening the case, reading the m/b: K9A2 Platinum MSI I hadnt been paying much attention to this thread, but just to let you know that I also saw the same thing on this machine which has an MSI 790FX Platinum motherboard. It was also irq22, and I am also running amd64. In my case I simply disabled the onboard ethernet (which I wasnt using) and the problem went away - but then I only saw the problem once, it wasnt a regular occurrance. If you have an alternative ether card you can drop in thn you could try that... FYI, this box has always run off an ethernet card (fxp). The on-board NIC (re) was enabled. After disabling, the ethernet storms persisted. -- Dan Langille BSDCan - The Technical BSD Conference : http://www.bsdcan.org/ PGCon - The PostgreSQL Conference: http://www.pgcon.org/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: named won't start
On Thu, Jan 15, 2009 at 05:30:23AM -0800, Mike Lempriere wrote: I'm not real clear on what item 6 means. However all of my specified zones have at least one NS and one A record. Does this mean I'm Ok? Sites that were relying on this BIND 8 behaviour need to add any omitted glue NS records, and any necessary glue A records, to the parent zone. Exactly as: domain.com.zone: [...] sec IN NS ns.sec.domain.com. ns.sec IN A 1.2.3.4 [...] sec.domain.com.zone: @ IN SOA [...] Nothing more. But I'v miss Your real problem below. Sergey N. Voronkov wrote: On Wed, Jan 14, 2009 at 08:11:27PM -0800, Mike Lempriere wrote: From /var/log/messages: starting BIND 9.4.3-P1 -t /var/named -u bind could not get query source dispatcher (0.0.0.0#53) loading configuration: address in use exiting (due to fatal error) So, the EXACT problem is a double start of the daemon. Please double check merge of rc files after upgrade. I had just updated from 5-stable (at 5.5) to 6-stable (at 6.4). Upon today's upgrade I got to 7.1. Everything else seems to be be working (the machine is basically a webserver), except named. apache is serving up pages, but only until my TTL times out... I so no errors in the builds or installs. I foolwed the instructions in UPDATING. I believe I did an accurate merge of my named.conf file. [skip] Sergey N. Voronkov, Sibitex Ltd. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: interrupt storm on MSI IXP600 based motherboards
Dan Langille wrote: Pete French wrote: kernel: interrupt storm detected on irq22:; throttling interrupt source Opening the case, reading the m/b: K9A2 Platinum MSI I hadnt been paying much attention to this thread, but just to let you know that I also saw the same thing on this machine which has an MSI 790FX Platinum motherboard. It was also irq22, and I am also running amd64. In my case I simply disabled the onboard ethernet (which I wasnt using) and the problem went away - but then I only saw the problem once, it wasnt a regular occurrance. If you have an alternative ether card you can drop in thn you could try that... FYI, this box has always run off an ethernet card (fxp). The on-board NIC (re) was enabled. After disabling, the ethernet storms persisted. trouble with onboard re(4) was resolved in -CURRENT and -STABLE, but storms are not bound to ethernet only. storm may appear on any device. if any device generates enough interrupts rate, storm will arrive. I've written about it in http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047644.html so far i can say that this issue is related on MSI IXP600 based motherboards only. well, we should try to find out what we can do to resolve it. -- SY, Marat ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: interrupt storm on MSI IXP600 based motherboards
Marat N.Afanasyev wrote: Dan Langille wrote: Pete French wrote: kernel: interrupt storm detected on irq22:; throttling interrupt source Opening the case, reading the m/b: K9A2 Platinum MSI I hadnt been paying much attention to this thread, but just to let you know that I also saw the same thing on this machine which has an MSI 790FX Platinum motherboard. It was also irq22, and I am also running amd64. In my case I simply disabled the onboard ethernet (which I wasnt using) and the problem went away - but then I only saw the problem once, it wasnt a regular occurrance. If you have an alternative ether card you can drop in thn you could try that... FYI, this box has always run off an ethernet card (fxp). The on-board NIC (re) was enabled. After disabling, the ethernet storms persisted. trouble with onboard re(4) was resolved in -CURRENT and -STABLE, but storms are not bound to ethernet only. storm may appear on any device. if any device generates enough interrupts rate, storm will arrive. I've written about it in http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047644.html so far i can say that this issue is related on MSI IXP600 based motherboards only. well, we should try to find out what we can do to resolve it. Any committer that would like ssh access to this box in order to fix the problem, mail me your public-ssh key. :) -- Dan Langille BSDCan - The Technical BSD Conference : http://www.bsdcan.org/ PGCon - The PostgreSQL Conference: http://www.pgcon.org/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: interrupt storm
On 2009-Jan-14 22:57:46 -0500, Dan Langille d...@langille.org wrote: Opening the case, reading the m/b: K9A2 Platinum MSI Tangentially related: For any decent M/B, kenv(8) should tell you this without needing to open the box. -- 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. pgpv26XRlNxyx.pgp Description: PGP signature
Re: zfs drive keeps failing between export and import
Wes Morgan wrote: What does zdb /dev/ad10.eli show? First, a quick update: removing the drive without ANY unmounts (I accidentally pulled it from the backplane) didn't cause any problems. I plugged it back in, reset the atachannel (there's a bug somewhere related to that, but I can live with atacontroll detach/attach), reattached with geli, ran the above command (it was identical the same as before), and within a minute, it showed up in zpool status as ONLINE (it was offline and in a degraded state, earlier). Anyway, the dump: LABEL 0 version=6 name='tank' state=0 txg=289956 pool_guid=6825823102095709452 hostid=2180312168 hostname='share2.lan' top_guid=5286005479160756084 guid=2749356003825630058 vdev_tree type='mirror' id=0 guid=5286005479160756084 metaslab_array=14 metaslab_shift=30 ashift=9 asize=1000199946240 children[0] type='disk' id=0 guid=1472646983867204022 path='/dev/ad8.eli' devid='ad:WD-WCASJ2219110' whole_disk=0 DTL=626 children[1] type='disk' id=1 guid=2749356003825630058 path='/dev/ad10.eli' devid='ad:WD-WCAU44729718' whole_disk=0 DTL=625 LABEL 1 version=6 name='tank' state=0 txg=289956 pool_guid=6825823102095709452 hostid=2180312168 hostname='share2.lan' top_guid=5286005479160756084 guid=2749356003825630058 vdev_tree type='mirror' id=0 guid=5286005479160756084 metaslab_array=14 metaslab_shift=30 ashift=9 asize=1000199946240 children[0] type='disk' id=0 guid=1472646983867204022 path='/dev/ad8.eli' devid='ad:WD-WCASJ2219110' whole_disk=0 DTL=626 children[1] type='disk' id=1 guid=2749356003825630058 path='/dev/ad10.eli' devid='ad:WD-WCAU44729718' whole_disk=0 DTL=625 LABEL 2 version=6 name='tank' state=0 txg=289956 pool_guid=6825823102095709452 hostid=2180312168 hostname='share2.lan' top_guid=5286005479160756084 guid=2749356003825630058 vdev_tree type='mirror' id=0 guid=5286005479160756084 metaslab_array=14 metaslab_shift=30 ashift=9 asize=1000199946240 children[0] type='disk' id=0 guid=1472646983867204022 path='/dev/ad8.eli' devid='ad:WD-WCASJ2219110' whole_disk=0 DTL=626 children[1] type='disk' id=1 guid=2749356003825630058 path='/dev/ad10.eli' devid='ad:WD-WCAU44729718' whole_disk=0 DTL=625 LABEL 3 version=6 name='tank' state=0 txg=289956 pool_guid=6825823102095709452 hostid=2180312168 hostname='share2.lan' top_guid=5286005479160756084 guid=2749356003825630058 vdev_tree type='mirror' id=0 guid=5286005479160756084 metaslab_array=14 metaslab_shift=30 ashift=9 asize=1000199946240 children[0] type='disk' id=0 guid=1472646983867204022 path='/dev/ad8.eli' devid='ad:WD-WCASJ2219110' whole_disk=0 DTL=626 children[1] type='disk' id=1 guid=2749356003825630058 path='/dev/ad10.eli' devid='ad:WD-WCAU44729718' whole_disk=0 DTL=625 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
