Re: dump never ending?

2008-04-24 Thread Brian McCann
Upgrading to 7-STABLE seems to have fixed the problem.  Thanks Kris!

--Brian

On Wed, Apr 23, 2008 at 1:51 PM, Kris Kennaway [EMAIL PROTECTED] wrote:
 Brian McCann wrote:


  On Wed, Apr 23, 2008 at 12:58 PM, Brian McCann [EMAIL PROTECTED] wrote:
 
   I've got an issue on a new 7.0 amd64 box (first one I've setup with
amd64).  When I dump tiny file systems (24M and 12K for example), dump
runs file.  When I dump something larger (202M and 2G for example), it
hangs and stops writing.  The command I'm running is:
  
dump -0uan -L -f /mnt/tiw.root.dump /
  
It hangs weather I put in -L or not, and if I try going to a local
file system or one over NFS.  I do see the following in ps:
  
dump: /dev/amrd0s1a: pass 4: 80.10% done, finished in 0:00 at Wed Apr
23 11:48:28 2008 (
  
along with 3 other dump processes.
  
There's no verbose option for dump...so I can't quite see what's
going on.  Does anyone have any ideas on this, or has anyone seen this
before?
  
 

  What is the wait channel in which the dump process is stuck (press ^T).  It
 sounds like a kernel bug that was recently fixed, so you could just try
 updating to 7.0-STABLE.  I believe it is scheduled for release as an errata
 patch against 7.0-RELEASE too.

  Kris





-- 
_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_
Brian McCann

I don't have to take this abuse from you -- I've got hundreds of
people waiting to abuse me.
 -- Bill Murray, Ghostbusters
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dump never ending?

2008-04-24 Thread Kris Kennaway

Brian McCann wrote:

Upgrading to 7-STABLE seems to have fixed the problem.  Thanks Kris!


Great!

Kris


--Brian

On Wed, Apr 23, 2008 at 1:51 PM, Kris Kennaway [EMAIL PROTECTED] wrote:

Brian McCann wrote:



On Wed, Apr 23, 2008 at 12:58 PM, Brian McCann [EMAIL PROTECTED] wrote:


I've got an issue on a new 7.0 amd64 box (first one I've setup with
 amd64).  When I dump tiny file systems (24M and 12K for example), dump
 runs file.  When I dump something larger (202M and 2G for example), it
 hangs and stops writing.  The command I'm running is:

 dump -0uan -L -f /mnt/tiw.root.dump /

 It hangs weather I put in -L or not, and if I try going to a local
 file system or one over NFS.  I do see the following in ps:

 dump: /dev/amrd0s1a: pass 4: 80.10% done, finished in 0:00 at Wed Apr
 23 11:48:28 2008 (

 along with 3 other dump processes.

 There's no verbose option for dump...so I can't quite see what's
 going on.  Does anyone have any ideas on this, or has anyone seen this
 before?


 What is the wait channel in which the dump process is stuck (press ^T).  It
sounds like a kernel bug that was recently fixed, so you could just try
updating to 7.0-STABLE.  I believe it is scheduled for release as an errata
patch against 7.0-RELEASE too.

 Kris








___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


dump never ending?

2008-04-23 Thread Brian McCann
I've got an issue on a new 7.0 amd64 box (first one I've setup with
amd64).  When I dump tiny file systems (24M and 12K for example), dump
runs file.  When I dump something larger (202M and 2G for example), it
hangs and stops writing.  The command I'm running is:

dump -0uan -L -f /mnt/tiw.root.dump /

It hangs weather I put in -L or not, and if I try going to a local
file system or one over NFS.  I do see the following in ps:

dump: /dev/amrd0s1a: pass 4: 80.10% done, finished in 0:00 at Wed Apr
23 11:48:28 2008 (

along with 3 other dump processes.

There's no verbose option for dump...so I can't quite see what's
going on.  Does anyone have any ideas on this, or has anyone seen this
before?

Thanks!
--Brian
-- 
_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_
Brian McCann

I don't have to take this abuse from you -- I've got hundreds of
people waiting to abuse me.
 -- Bill Murray, Ghostbusters
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dump never ending?

2008-04-23 Thread Brian McCann
Here's dmesg from my system...it's a Dell PowerEdge 2850

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 #0: Sun Feb 24 10:35:36 UTC 2008
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.20-MHz K8-class CPU)
  Origin = GenuineIntel  Id = 0xf41  Stepping = 1
  
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  Features2=0x641dSSE3,RSVD2,MON,DS_CPL,CNXT-ID,CX16,xTPR
  AMD Features=0x20100800SYSCALL,NX,LM
  Logical CPUs per core: 2
usable memory = 4281946112 (4083 MB)
avail memory  = 4128460800 (3937 MB)
ACPI APIC Table: DELL   PE BKC  
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
 cpu2 (AP): APIC ID:  6
 cpu3 (AP): APIC ID:  7
ioapic0: Changing APIC ID to 8
ioapic1: Changing APIC ID to 9
ioapic2: Changing APIC ID to 10
ioapic3: Changing APIC ID to 11
ioapic0 Version 2.0 irqs 0-23 on motherboard
ioapic1 Version 2.0 irqs 32-55 on motherboard
ioapic2 Version 2.0 irqs 64-87 on motherboard
ioapic3 Version 2.0 irqs 96-119 on motherboard
kbd1 at kbdmux0
ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
hptrr: HPT RocketRAID controller driver v1.1 (Feb 24 2008 10:34:18)
acpi0: DELL PE BKC on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
Timecounter ACPI-fast frequency 3579545 Hz quality 1000
acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0
acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0
Timecounter HPET frequency 14318180 Hz quality 900
cpu0: ACPI CPU on acpi0
p4tcc0: CPU Frequency Thermal Control on cpu0
cpu1: ACPI CPU on acpi0
p4tcc1: CPU Frequency Thermal Control on cpu1
cpu2: ACPI CPU on acpi0
p4tcc2: CPU Frequency Thermal Control on cpu2
cpu3: ACPI CPU on acpi0
p4tcc3: CPU Frequency Thermal Control on cpu3
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pcib1: ACPI PCI-PCI bridge at device 2.0 on pci0
pci1: ACPI PCI bus on pcib1
pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1
pci2: ACPI PCI bus on pcib2
amr0: LSILogic MegaRAID 1.53 mem
0xf80f-0xf80f,0xfe9c-0xfe9f irq 46 at device 14.0 on
pci2
amr0: Using 64-bit DMA
amr0: [ITHREAD]
amr0: delete logical drives supported by controller
amr0: LSILogic PERC 4e/Di Firmware 5A2D, BIOS H433, 256MB RAM
pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1
pci3: ACPI PCI bus on pcib3
pcib4: ACPI PCI-PCI bridge at device 4.0 on pci0
pci4: ACPI PCI bus on pcib4
pcib5: ACPI PCI-PCI bridge at device 5.0 on pci0
pci5: ACPI PCI bus on pcib5
pcib6: ACPI PCI-PCI bridge at device 0.0 on pci5
pci6: ACPI PCI bus on pcib6
em0: Intel(R) PRO/1000 Network Connection Version - 6.7.3 port
0xecc0-0xecff mem 0xfe6e-0xfe6f irq 64 at device 7.0 on pci6
em0: Ethernet address: 00:14:22:1d:dd:50
em0: [FILTER]
pcib7: ACPI PCI-PCI bridge at device 0.2 on pci5
pci7: ACPI PCI bus on pcib7
em1: Intel(R) PRO/1000 Network Connection Version - 6.7.3 port
0xdcc0-0xdcff mem 0xfe4e-0xfe4f irq 65 at device 8.0 on pci7
em1: Ethernet address: 00:14:22:1d:dd:51
em1: [FILTER]
pcib8: ACPI PCI-PCI bridge at device 6.0 on pci0
pci8: ACPI PCI bus on pcib8
pcib9: ACPI PCI-PCI bridge at device 0.0 on pci8
pci9: ACPI PCI bus on pcib9
pcib10: ACPI PCI-PCI bridge at device 0.2 on pci8
pci10: ACPI PCI bus on pcib10
uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0xbce0-0xbcff
irq 16 at device 29.0 on pci0
uhci0: [GIANT-LOCKED]
uhci0: [ITHREAD]
usb0: Intel 82801EB (ICH5) USB controller USB-A on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb0
uhub0: 2 ports with 2 removable, self powered
uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0xbcc0-0xbcdf
irq 19 at device 29.1 on pci0
uhci1: [GIANT-LOCKED]
uhci1: [ITHREAD]
usb1: Intel 82801EB (ICH5) USB controller USB-B on uhci1
usb1: USB revision 1.0
uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb1
uhub1: 2 ports with 2 removable, self powered
uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0xbca0-0xbcbf
irq 18 at device 29.2 on pci0
uhci2: [GIANT-LOCKED]
uhci2: [ITHREAD]
usb2: Intel 82801EB (ICH5) USB controller USB-C on uhci2
usb2: USB revision 1.0
uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb2
uhub2: 2 ports with 2 removable, self powered
ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem
0xfeb0-0xfeb003ff irq 23 at device 29.7 on pci0
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb3: EHCI version 1.0
usb3: companion controllers, 2 ports each: usb0 usb1 usb2
usb3: Intel 82801EB/R (ICH5) USB 2.0 controller on ehci0
usb3: USB revision 2.0
uhub3: Intel EHCI root hub, 

Re: dump never ending?

2008-04-23 Thread Kris Kennaway

Brian McCann wrote:


On Wed, Apr 23, 2008 at 12:58 PM, Brian McCann [EMAIL PROTECTED] wrote:

I've got an issue on a new 7.0 amd64 box (first one I've setup with
 amd64).  When I dump tiny file systems (24M and 12K for example), dump
 runs file.  When I dump something larger (202M and 2G for example), it
 hangs and stops writing.  The command I'm running is:

 dump -0uan -L -f /mnt/tiw.root.dump /

 It hangs weather I put in -L or not, and if I try going to a local
 file system or one over NFS.  I do see the following in ps:

 dump: /dev/amrd0s1a: pass 4: 80.10% done, finished in 0:00 at Wed Apr
 23 11:48:28 2008 (

 along with 3 other dump processes.

 There's no verbose option for dump...so I can't quite see what's
 going on.  Does anyone have any ideas on this, or has anyone seen this
 before?


What is the wait channel in which the dump process is stuck (press ^T). 
 It sounds like a kernel bug that was recently fixed, so you could just 
try updating to 7.0-STABLE.  I believe it is scheduled for release as an 
errata patch against 7.0-RELEASE too.


Kris

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]