Re: 13.0-BETA3 frequent file system (UFS) hangs

[Jack L.]

I'm also having the same exact issues across several systems on
13-BETA3 and 14-CURRENT as of last week.

I recently upgraded everything to the latest 13-STABLE and 14-CURRENT
but uptime is only a day or so and not sure if it's still a problem.


On Mon, Feb 22, 2021 at 12:07 PM Florian Smeets via freebsd-stable
 wrote:
>
> Hi,
>
> on Sunday I upgraded a lightly loaded web server (Nginx+PHP-FPM+MariaDB)
> from 12.2-RELEASE-p3 to 13.0-BETA3. The server has been hanging every
> few hours (between 2-12). Until now the only remedy I found was a reboot.
>
> When the issue appears I can still read from the file system, I was able
> to touch a (new) file, but not delete it.
>
> load: 0.49  cmd: rm 78200 [biowr] 7.31r 0.00u 0.28s 1% 2192k
> mi_switch+0xc1 _sleep+0x1cb bwait+0x6e bufwrite+0x206 ffs_update+0x2d0
> ffs_syncvnode+0x552 softdep_prelink+0x14b ufs_remove+0x85
> VOP_REMOVE_APV+0x27 kern_funlinkat+0x2d5 sys_unlink+0x28
> amd64_syscall+0x10c fast_syscall_common+0xf8
>
> The system is UFS only.
>
> /dev/da0s1a on / (ufs, local, noatime, journaled soft-updates, writes:
> sync 19483 async 3361, reads: sync 24501 async 4191, fsid 374666591e63cded)
>
> For some of the reboots I see the following in the log before rebooting:
>
> Feb 21 15:21:57 web01 kernel: Waiting (max 60 seconds) for system
> process `vnlru' to stop... done
> Feb 21 15:21:57 web01 kernel: Waiting (max 60 seconds) for system
> process `syncer' to stop...
> Feb 21 15:21:57 web01 kernel: Syncing disks, vnodes remaining... 20
> fsync: giving up on dirty (error = 35) 0xf80003815b70: type VCHR
> Feb 21 15:21:57 web01 kernel: usecount 1, writecount 0, refcount
> 1074 seqc users 0 rdev 0xf80004c3f000
> Feb 21 15:21:57 web01 kernel: hold count flags ()
> Feb 21 15:21:57 web01 kernel: flags ()
> Feb 21 15:21:57 web01 kernel: v_object 0xf800030d0c60 ref 0
> pages 45500 cleanbuf 1071 dirtybuf 1
> Feb 21 15:21:57 web01 kernel: lock type mntfs: EXCL by thread
> 0xfe00c33fc000 (pid 24, syncer, tid 100097)
> Feb 21 15:21:57 web01 kernel: 9 5 0 0 done
>
> Is this related to the thread "FreeBSD 13.0-BETA2 and slow IO" ?
>
> I have a stable/13 kernel on there now, but that also hung once already.
>
> Do I need to disable SU/SUJ or put a main kernel on there to get it stable?
>
> Thanks,
> Florian
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: est and turbo boost

[Jack L.]

I've noticed for Dells, you have to set the performance setting to
"Custom" and OS Control to be able to change the EST.

On Tue, Feb 16, 2021 at 7:12 PM Eugene Grosbein  wrote:
>
> Hi!
>
> We use leased server Dell PowerEdge R640 with latest firmware (BIOS/UEFI)
> that does not export ACPI _PSS table, so FreeBSD 12.2-RELEASE/amd64 (GENERIC)
> est(4) driver does not attach:
>
> est0:  numa-domain 0 on cpu0
> est: CPU supports Enhanced Speedstep, but is not recognized.
> est: cpu_vendor GenuineIntel, msr 1bc41c00
> device_attach: est0 attach returned 6
>
> Hence, no CPU frequency control and no TurboBoost for the CPU:
>
> CPU: Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz (2294.68-MHz K8-class CPU)
>   Origin="GenuineIntel"  Id=0x50657  Family=0x6  Model=0x55  Stepping=7
>   
> Features=0xbfebfbff   
> Features2=0x7ffefbff   AMD Features=0x2c100800
>   AMD Features2=0x121
>   Structured Extended 
> Features=0xd39b   Structured Extended Features2=0x808
>   Structured Extended 
> Features3=0xbc000400
>   XSAVE Features=0xf
>   IA32_ARCH_CAPS=0xab
>   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr
>   TSC: P-state invariant, performance statistics
> ACPI APIC Table: 
> FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs
> FreeBSD/SMP: 2 package(s) x 16 core(s)
>
> Logical processors (hyperthreading) disabled in server's SETUP.
>
> I've tried to use loader prompt to set hw.est.msr_info=1
> but then is panices early at boot time with "integer divide fault".
> No crashdump generated but a screenshot is available:
>
> http://www.grosbein.net/freebsd/est-panic.jpg
>
> What are options to enable est/TurboBoost in this case?
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Anyone else seeing hangs at "Trying to mount root" after recent commits?

[Jack L.]

Yes, I upgraded 2 systems and both experience the same behavior

Dell R610 and Dell 7010 here. Afraid to upgrade any others

On Tue, Sep 10, 2019 at 8:25 PM Terry Kennedy  wrote:
>
>   I have a system I updated from r352025 (which worked fine) to r352200.
> Any attempt to boot r352200 results in the system just sitting there after
> displaying the normal "Trying to mount root from ufs:/dev/da0p3 [rw]..."
> message. Nothing further, not even after a half hour. The console is non-
> responsive (not that I'd really expect anything, but...).
>
>   This persists across multiple resets, power cycles, etc. Booting the
> previous r352025 works fine, as expected.
>
>   Before I start trying to bisect this, is anyone else seeing this? amd64
> on a standard Dell PowerEdge R730 if that matters.
>
> Terry Kennedy http://www.glaver.org  New York, NY USA
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Notification for GMirror failures

[Jack L.]

I use crontab @daily (/sbin/gmirror status | grep -q COMPLETE) || mail
-s "gmirror failure" email addy

On Tue, May 8, 2018 at 4:41 PM, Vincent Hoffman-Kazlauskas
 wrote:
>
>
> On 08/05/2018 08:28, Andrea Brancatelli wrote:
>> Hi,
>>
>> out of curiosity, does any kind of GMirror-failure notification tools
>> exist?
>>
>> Either native... SNMP... external ports... whatever?
>>
> If you use nagios (or compatible) net-mgmt/nagios-geom in ports works
>
> root@banshee # /usr/local/libexec/nagios/check_geom mirror gm0
> OK mirror/gm0 COMPLETE { ada0s1 (ACTIVE) , ada1s1 (ACTIVE)
> }|geom_mirror=2;;;0;
> ($00:41:05 $) 0
>
>
> Vince
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 9.3 to 11.1 upgrade

[Jack L.]

I went from 9 to 11 without issue with the make work/kernel method and
rebuilt all the ports.

On Tue, Jun 20, 2017 at 10:31 AM, Miroslav Lachman <000.f...@quip.cz> wrote:
> Zoran Kolic wrote on 2017/06/20 17:12:
>>>
>>> Generally (and previously) the advice is to go via the next major version
>>> so
>>> you should go:
>>>
>>> 9.3 -> 10.x -> 11.x not 9.3 -> 11.x
>>
>>
>> Exactelly what I want to avoid.
>> People successfuly upgraded, without branch 10.
>
>
> In the past I did 8.4 to 10.3, but not by freebsd-update. We are using make
> installkernel + make installworld method. 9.3 to 11.1 can work similarly.
>
> Miroslav Lachman
>
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Opteron 6100-series "Magny-Cours"

[Jack L.]

I have a few still sitting in a corner with FreeBSD 7 or 8 on them. Someday i 
might put them back on with FreeBSD but not anytime soon

Sent from far away...

> On Mar 25, 2017, at 11:02 AM, Andriy Gapon  wrote:
> 
> 
> Does anyone [still] use Opteron 6100-series / "Magny-Cours" processors with 
> FreeBSD?
> 
> 
> -- 
> Andriy Gapon
> ___
> freebsd-curr...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Old laptop not able to get enough entropy in FreeBSD 11

[Jack L.]

Adding FreeBSD stable to see if they can provide some insight on this since
it affects everything from 11 and beyond

>
> On Sat, Nov 26, 2016 at 7:01 AM, Bertram Scharpf <li...@bertram-scharpf.de
> > wrote:
>
>> On Friday, 25. Nov 2016, 20:06:55 -0800, Jack L. wrote:
>> > On Fri, Nov 25, 2016 at 7:32 PM, Bertram Scharpf <
>> li...@bertram-scharpf.de>
>> > wrote:
>> >
>> > > On Friday, 25. Nov 2016, 18:31:24 -0800, Jack L. wrote:
>> > > > >> > I have an old single core AMD Turion ML-37 laptop that has
>> nothing
>> > > > >> > installed. When I boot it up, the moment it displays login:,
>> it hangs
>> > > > >> > until i press some random keys. At shutdown, it will hang
>> until I
>> > > > >> > press keys and it will not move onto the next line of shutdown
>> until
>> > > > >> > I keep pressing keys.
>> > > > >> >
>> > > > >> > If I cat /dev/random > ./dev/null while using the laptop, it
>> works
>> > > > >> > fine but when nothing is happening, the laptop hangs. Any
>> ideas? It's
>> > > > >> > running 11.0-STABLE
>> > > > >
>> > > > > Any ideas on why the laptop would have that behavior in 11? It
>> didn't hang
>> > > > > at all in 10.3-STABLE
>> > > > >
>> > > > I just installed 12-CURRENT on the laptop and it also hangs even at
>> > > > install/boot/shutdown until I hit keys, then it will move as long
>> as I
>> > > > continue to hit keys. I also found that if I ping the laptop, it
>> will
>> > > > respond but in between pings, it will hang. Using FreeBSD 10.3, it
>> works
>> > > > perfectly fine without any random keypresses. Any ideas?
>> > >
>> > > I'm convinced this behaviour it worth being analysed.
>> > >
>> > > Can you gain any knowlegde by calling cat through truss?
>> >
>> > How should I run that?
>>
>> Sorry, that was probably too fast.
>>
>> You could run one of those:
>>
>>   # truss cat /dev/random >/dev/null
>>   # truss dd if=/dev/random of=/dev/null bs=512 count=3
>>
>> But they will show just a series of read-write calls until a
>> read will hang. The detain presumably occurs in the random
>> device. That's kernel stuff. Does anybody have a hint how to
>> debug that without influencing the behaviour in question?
>>
>
> So truss cat /dev/random >/dev/null
> will keep going and going and going and going
> truss dd if=/dev/random of=/dev/null bs=512 count=3
> sits there and hangs with no activity until i hit a key, then the dd
> happens.
>
>
>> Bertram
>>
>>
>> --
>> Bertram Scharpf
>> Stuttgart, Deutschland/Germany
>> http://www.bertram-scharpf.de
>> ___
>> freebsd-questi...@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-questions
>> To unsubscribe, send any mail to "freebsd-questions-unsubscribe
>> @freebsd.org"
>>
>
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: siisch1: Error while READ LOG EXT

[Jack L.]

the drive has reallocated some sectors and normally drives should never
reallocate sectors unless it has trouble reading/writing to them. also,
that drive has known firmware problems so it sounds like the drive needs
replacing
On Feb 9, 2012 10:38 AM, Mike Tancsa m...@sentex.net wrote:

 On 2/9/2012 11:34 AM, Jeremy Chadwick wrote:
 
  You will probably need to track these drives on a regular basis.  That
  is to say, set up some cronjob or similar that logs the above output to
  a file (appends data to it), specifically output from smartctl -A (not
  -a and not -x) and smartctl -l sataphy on a per-disk basis.  smartd can
  track SMART attribute changes, but does not track GPLog changes.  Make
  sure to put timestamps in your logs.

 Thanks very much for having a look, and the suggestions. It think this
 is the way to go to see which drive my have errors incrementing.
 Alexander, is there a better way you can suggest ?

 
  As for fixing the problem: I have no idea how you would go about this.
  Use of port multipliers involves additional cables, possibly of shoddy
  quality, or other components which may not be decent/reliable.


 Possibly.  Cables are one of those things I am happy to pay extra for
 better quality but how does one assess quality of such parts.

 
  Overall, this is just one of the many reasons why I avoid PMs, as well
  as avoid eSATA (especially eSATA).

 Yeah, at some point it doesnt really work with too many PMs, especially
 if you cant query the thing to find out where things are bad.  I think
 for the next version of this box I will use the newer generation 3ware
 SAS/SATA controller

---Mike



 --
 ---
 Mike Tancsa, tel +1 519 651 3400
 Sentex Communications, m...@sentex.net
 Providing Internet services since 1994 www.sentex.net
 Cambridge, Ontario Canada   http://www.tancsa.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

___
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: CPU0: local APIC error 0x40 CPU1: local APIC error 0x40

[Jack L.]

I just got the error just now. I'm keeping the machine booted for a
little longer in case someone wants to ask any questions. If I simple
reboot the machine, it will just hang forever and eventually need to
power cycle it.

Mar  9 04:58:51 jpr1 kernel:
j...@jpr1.prdhost.com:/usr/obj/usr/src/sys/JPR1 amd64
Mar  9 04:58:51 jpr1 kernel: Timecounter i8254 frequency 1193182 Hz quality 0
Mar  9 04:58:51 jpr1 kernel: CPU: AMD Athlon(tm) 64 X2 Dual Core
Processor 6400+ (3214.84-MHz K8-class CPU)
Mar  9 04:58:51 jpr1 kernel: Origin = AuthenticAMD  Id = 0x40f33
Family = f  Model = 43  Stepping = 3
Mar  9 04:58:51 jpr1 kernel:
Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT
Mar  9 04:58:51 jpr1 kernel: Features2=0x2001SSE3,CX16
Mar  9 04:58:51 jpr1 kernel: AMD
Features=0xea500800SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow!
Mar  9 04:58:51 jpr1 kernel: AMD Features2=0x1fLAHF,CMP,SVM,ExtAPIC,CR8
Mar  9 04:58:51 jpr1 kernel: real memory  = 8589934592 (8192 MB)
Mar  9 04:58:51 jpr1 kernel: avail memory = 8228098048 (7846 MB)
Mar  9 04:58:51 jpr1 kernel: ACPI APIC Table: Nvidia ASUSACPI
Mar  9 04:58:51 jpr1 kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
Mar  9 04:58:51 jpr1 kernel: FreeBSD/SMP: 1 package(s) x 2 core(s)
Mar  9 04:58:51 jpr1 kernel: cpu0 (BSP): APIC ID:  0
Mar  9 04:58:51 jpr1 kernel: cpu1 (AP): APIC ID:  1
Mar  9 04:58:51 jpr1 kernel: ioapic0: Changing APIC ID to 4
Mar  9 04:58:51 jpr1 kernel: ioapic0 Version 1.1 irqs 0-23 on motherboard
Mar  9 04:58:51 jpr1 kernel: kbd1 at kbdmux0
Mar  9 04:58:51 jpr1 kernel: acpi0: Nvidia ASUSACPI on motherboard
Mar  9 04:58:51 jpr1 kernel: acpi0: [ITHREAD]
Mar  9 04:58:51 jpr1 kernel: acpi0: Power Button (fixed)
Mar  9 04:58:51 jpr1 kernel: acpi0: reservation of 0, a (3) failed
Mar  9 04:58:51 jpr1 kernel: acpi0: reservation of 10, cedf (3) failed
Mar  9 04:58:51 jpr1 kernel: Timecounter ACPI-fast frequency 3579545
Hz quality 1000
Mar  9 04:58:51 jpr1 kernel: acpi_timer0: 24-bit timer at
3.579545MHz port 0x4008-0x400b on acpi0
Mar  9 04:58:51 jpr1 kernel: cpu0: ACPI CPU on acpi0
Mar  9 04:58:51 jpr1 kernel: cpu1: ACPI CPU on acpi0
Mar  9 04:58:51 jpr1 kernel: acpi_button0: Power Button on acpi0
Mar  9 04:58:51 jpr1 kernel: pcib0: ACPI Host-PCI bridge port
0xcf8-0xcff on acpi0
Mar  9 04:58:51 jpr1 kernel: pci0: ACPI PCI bus on pcib0
Mar  9 04:58:51 jpr1 kernel: pci0: memory, RAM at device 0.0 (no
driver attached)
Mar  9 04:58:51 jpr1 kernel: pci0: memory, RAM at device 0.1 (no
driver attached)
Mar  9 04:58:51 jpr1 kernel: pci0: memory, RAM at device 0.2 (no
driver attached)
Mar  9 04:58:51 jpr1 kernel: pci0: memory, RAM at device 0.3 (no
driver attached)
Mar  9 04:58:51 jpr1 kernel: pci0: memory, RAM at device 0.4 (no
driver attached)
Mar  9 04:58:51 jpr1 kernel: pci0: memory, RAM at device 0.5 (no
driver attached)
Mar  9 04:58:51 jpr1 kernel: pci0: memory, RAM at device 0.6 (no
driver attached)
Mar  9 04:58:51 jpr1 kernel: pci0: memory, RAM at device 0.7 (no
driver attached)
Mar  9 04:58:51 jpr1 kernel: vgapci0: VGA-compatible display mem
0xfc00-0xfcff,0xd000-0xdfff,0xfb00-0xfbff irq
16 at device 5.0 on pci0
Mar  9 04:58:51 jpr1 kernel: pci0: memory, RAM at device 9.0 (no
driver attached)
Mar  9 04:58:51 jpr1 kernel: isab0: PCI-ISA bridge at device 10.0 on pci0
Mar  9 04:58:51 jpr1 kernel: isa0: ISA bus on isab0
Mar  9 04:58:51 jpr1 kernel: nfsmb0: nForce2/3/4 MCP SMBus
Controller port 0x4c00-0x4c3f,0x4c40-0x4c7f at device 10.1 on pci0
Mar  9 04:58:51 jpr1 kernel: smbus0: System Management Bus on nfsmb0
Mar  9 04:58:51 jpr1 kernel: smb0: SMBus generic I/O on smbus0
Mar  9 04:58:51 jpr1 kernel: nfsmb1: nForce2/3/4 MCP SMBus
Controller on nfsmb0
Mar  9 04:58:51 jpr1 kernel: smbus1: System Management Bus on nfsmb1
Mar  9 04:58:51 jpr1 kernel: smb1: SMBus generic I/O on smbus1
Mar  9 04:58:51 jpr1 kernel: pci0: memory, RAM at device 10.2 (no
driver attached)
Mar  9 04:58:51 jpr1 kernel: ohci0: OHCI (generic) USB controller
mem 0xfe02f000-0xfe02 at device 11.0 on pci0
Mar  9 04:58:51 jpr1 kernel: ohci0: [ITHREAD]
Mar  9 04:58:51 jpr1 kernel: usbus0: OHCI (generic) USB controller on ohci0
Mar  9 04:58:51 jpr1 kernel: ehci0: EHCI (generic) USB 2.0
controller mem 0xfe02e000-0xfe02e0ff at device 11.1 on pci0
Mar  9 04:58:51 jpr1 kernel: ehci0: [ITHREAD]
Mar  9 04:58:51 jpr1 kernel: usbus1: EHCI version 1.0
Mar  9 04:58:51 jpr1 kernel: usbus1: EHCI (generic) USB 2.0
controller on ehci0
Mar  9 04:58:51 jpr1 kernel: atapci0: nVidia nForce MCP51 UDMA133
controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfd00-0xfd0f at
device 13.0 on pci0
Mar  9 04:58:51 jpr1 kernel: ata0: ATA channel 0 on atapci0
Mar  9 04:58:51 jpr1 kernel: ata0: [ITHREAD]
Mar  9 04:58:51 jpr1 kernel: ata1: ATA channel 1 on atapci0
Mar  9 04:58:51 jpr1 kernel: ata1: [ITHREAD]
Mar  9 04:58:51 jpr1 kernel: atapci1: nVidia nForce MCP51 SATA300
controller port

Re: CPU0: local APIC error 0x40 CPU1: local APIC error 0x40

[Jack L.]

Here's what happened when i did a ctrl+alt+del on the console.

Mar 10 03:10:23 jpr1 rc.shutdown: 30 second watchdog timeout expired.
Shutdown terminated.
Mar 10 03:10:23 jpr1 init: /bin/sh on /etc/rc.shutdown terminated
abnormally, going to single user mode
Mar 10 03:10:23 jpr1 syslogd: exiting on signal 15
Mar 10 03:13:26 jpr1 syslogd: kernel boot file is /boot/kernel/kernel
Mar 10 03:13:26 jpr1 kernel: Waiting (max 60 seconds) for system
process `vnlru' to stop...done
Mar 10 03:13:26 jpr1 kernel: Waiting (max 60 seconds) for system
process `bufdaemon' to stop...timed out
Mar 10 03:13:26 jpr1 kernel: Waiting (max 60 seconds) for system
process `syncer' to stop...
Mar 10 03:13:26 jpr1 kernel: Syncing disks, vnodes remaining...0 timed out
Mar 10 03:13:26 jpr1 kernel: All buffers synced.


On Thu, Mar 10, 2011 at 1:50 AM, Jack L. xxjack1...@gmail.com wrote:
 I just got the error just now. I'm keeping the machine booted for a
 little longer in case someone wants to ask any questions. If I simple
 reboot the machine, it will just hang forever and eventually need to
 power cycle it.

 Mar  9 04:58:51 jpr1 kernel:
 j...@jpr1.prdhost.com:/usr/obj/usr/src/sys/JPR1 amd64
 Mar  9 04:58:51 jpr1 kernel: Timecounter i8254 frequency 1193182 Hz quality  0
 Mar  9 04:58:51 jpr1 kernel: CPU: AMD Athlon(tm) 64 X2 Dual Core
 Processor 6400+ (3214.84-MHz K8-class CPU)
 Mar  9 04:58:51 jpr1 kernel: Origin = AuthenticAMD  Id = 0x40f33
 Family = f  Model = 43  Stepping = 3
 Mar  9 04:58:51 jpr1 kernel:
 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT
 Mar  9 04:58:51 jpr1 kernel: Features2=0x2001SSE3,CX16
 Mar  9 04:58:51 jpr1 kernel: AMD
 Features=0xea500800SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow!
 Mar  9 04:58:51 jpr1 kernel: AMD Features2=0x1fLAHF,CMP,SVM,ExtAPIC,CR8
 Mar  9 04:58:51 jpr1 kernel: real memory  = 8589934592 (8192 MB)
 Mar  9 04:58:51 jpr1 kernel: avail memory = 8228098048 (7846 MB)
 Mar  9 04:58:51 jpr1 kernel: ACPI APIC Table: Nvidia ASUSACPI
 Mar  9 04:58:51 jpr1 kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 
 CPUs
 Mar  9 04:58:51 jpr1 kernel: FreeBSD/SMP: 1 package(s) x 2 core(s)
 Mar  9 04:58:51 jpr1 kernel: cpu0 (BSP): APIC ID:  0
 Mar  9 04:58:51 jpr1 kernel: cpu1 (AP): APIC ID:  1
 Mar  9 04:58:51 jpr1 kernel: ioapic0: Changing APIC ID to 4
 Mar  9 04:58:51 jpr1 kernel: ioapic0 Version 1.1 irqs 0-23 on motherboard
 Mar  9 04:58:51 jpr1 kernel: kbd1 at kbdmux0
 Mar  9 04:58:51 jpr1 kernel: acpi0: Nvidia ASUSACPI on motherboard
 Mar  9 04:58:51 jpr1 kernel: acpi0: [ITHREAD]
 Mar  9 04:58:51 jpr1 kernel: acpi0: Power Button (fixed)
 Mar  9 04:58:51 jpr1 kernel: acpi0: reservation of 0, a (3) failed
 Mar  9 04:58:51 jpr1 kernel: acpi0: reservation of 10, cedf (3) failed
 Mar  9 04:58:51 jpr1 kernel: Timecounter ACPI-fast frequency 3579545
 Hz quality 1000
 Mar  9 04:58:51 jpr1 kernel: acpi_timer0: 24-bit timer at
 3.579545MHz port 0x4008-0x400b on acpi0
 Mar  9 04:58:51 jpr1 kernel: cpu0: ACPI CPU on acpi0
 Mar  9 04:58:51 jpr1 kernel: cpu1: ACPI CPU on acpi0
 Mar  9 04:58:51 jpr1 kernel: acpi_button0: Power Button on acpi0
 Mar  9 04:58:51 jpr1 kernel: pcib0: ACPI Host-PCI bridge port
 0xcf8-0xcff on acpi0
 Mar  9 04:58:51 jpr1 kernel: pci0: ACPI PCI bus on pcib0
 Mar  9 04:58:51 jpr1 kernel: pci0: memory, RAM at device 0.0 (no
 driver attached)
 Mar  9 04:58:51 jpr1 kernel: pci0: memory, RAM at device 0.1 (no
 driver attached)
 Mar  9 04:58:51 jpr1 kernel: pci0: memory, RAM at device 0.2 (no
 driver attached)
 Mar  9 04:58:51 jpr1 kernel: pci0: memory, RAM at device 0.3 (no
 driver attached)
 Mar  9 04:58:51 jpr1 kernel: pci0: memory, RAM at device 0.4 (no
 driver attached)
 Mar  9 04:58:51 jpr1 kernel: pci0: memory, RAM at device 0.5 (no
 driver attached)
 Mar  9 04:58:51 jpr1 kernel: pci0: memory, RAM at device 0.6 (no
 driver attached)
 Mar  9 04:58:51 jpr1 kernel: pci0: memory, RAM at device 0.7 (no
 driver attached)
 Mar  9 04:58:51 jpr1 kernel: vgapci0: VGA-compatible display mem
 0xfc00-0xfcff,0xd000-0xdfff,0xfb00-0xfbff irq
 16 at device 5.0 on pci0
 Mar  9 04:58:51 jpr1 kernel: pci0: memory, RAM at device 9.0 (no
 driver attached)
 Mar  9 04:58:51 jpr1 kernel: isab0: PCI-ISA bridge at device 10.0 on pci0
 Mar  9 04:58:51 jpr1 kernel: isa0: ISA bus on isab0
 Mar  9 04:58:51 jpr1 kernel: nfsmb0: nForce2/3/4 MCP SMBus
 Controller port 0x4c00-0x4c3f,0x4c40-0x4c7f at device 10.1 on pci0
 Mar  9 04:58:51 jpr1 kernel: smbus0: System Management Bus on nfsmb0
 Mar  9 04:58:51 jpr1 kernel: smb0: SMBus generic I/O on smbus0
 Mar  9 04:58:51 jpr1 kernel: nfsmb1: nForce2/3/4 MCP SMBus
 Controller on nfsmb0
 Mar  9 04:58:51 jpr1 kernel: smbus1: System Management Bus on nfsmb1
 Mar  9 04:58:51 jpr1 kernel: smb1: SMBus generic I/O on smbus1
 Mar  9 04:58:51 jpr1 kernel: pci0: memory, RAM at device 10.2 (no
 driver attached)
 Mar  9 04:58:51 jpr1 kernel: ohci0: OHCI (generic) USB

Re: CPU0: local APIC error 0x40 CPU1: local APIC error 0x40

[Jack L.]

On Tue, Mar 1, 2011 at 5:50 PM, Mike Tancsa m...@sentex.net wrote:
 I had a machine deadlock just now and the only thing on the serial
 console was

 CPU0: local APIC error 0x40
 CPU1: local APIC error 0x40

 prior to it hanging.  Anyone know what that error is ? Googling didnt
 really show much definitive.  Someone suggested bad hardware ? Is there
 a way to narrow that down ?

I too get this error all the time on my AMD 6400+ Dual Core with an
ASUS motherboard. I'll post some feedback when it happens again.
Problem is everytime it happens, the system completely locks up and a
power cycle is needed.
___
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: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)

[Jack L. Stone]

At 09:45 AM 3.25.2009 -0500, Peggy Wilkins wrote:
  Jack L Stone ja...@sage-american.com writes:

 I've been watching this thread with some interest since we've had some
 similar problems with dump/restore which we use every morning via cron
 scripts on a number of servers to produce bootable clones as part
of our
 backup program. Have been doing this for years and also never saw a
problem
 as most of you say. We prefer dump/restore for backups.

 However, last month upon upon upgrading those servers from FBSD-6.3px
 (RELEASE) to 7.0px (RELEASE) we found that about one-half of the
servers
 had a similar problem as the original poster while the other half
did not.
 All of the servers (rackmounts) use the same (type) hardware. We
spent many
 hours trying to solve the problem with those that failed to
dump/restore.
 Also, searched for any others with the problem and only found a
very few,
 but without solutions to this issue. (Indeed, the only one was a
reference
 to any efforts to restore an older OS version which didn't apply
here).
  [snip]
 SOLUTION
 The clones are a very important pasrt of our backup program.
Since the
 dump side of the problems simply stuck and provided no error
message at all
 and the errors from any restores were not useful, our only solution
was to
 revert back to FBSD-6.3 on those servers with this issue and
dump/restore
 went back to working again. We left those that were working on
FBSD-7.0-R
 and they continue to work okay.

I was seeing this same problem on all my 64-bit systems: FreeBSD-7
dump would hang at a random point.  Dump continues to work flawlessly
for me on FreeBSD-7/i386.

I ran across this which includes a patch:

http://www.freebsd.org/cgi/query-pr.cgi?pr=121684

The kernel patch linked to there solved the problem for me, but I am
running many production systems and am unwilling to apply this patch
to -RELEASE every time there is a kernel update (I just use the
standard GENERIC kernel which I get via freebsd-update).  I now live
without dump on amd64.  Apparently this fix is waiting on some related
issue; and I will be very happy when it makes it to the officially
released kernel.

plw


Thanks for the reply. Forgot to mention, our machines are all i386 with the
problem -- so are the ones without the problem.

Yes, I found that patch too and tried it on one of the servers -- no joy.

Guess we'll continue to wait also for now. Maybe 7.2/i386or, until
someone finds the solution since we're out of ideas and stuck with 6.3 in
order to use dump that we have trusted.

Jack

(^_^)
Happy trails,
Jack L. Stone

System Admin
Sage-american
___
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: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)

[Jack L. Stone]

At 07:57 AM 3.26.2009 -0400, Mike Tancsa wrote:

Thanks for the reply. Forgot to mention, our machines are all i386 with the
problem -- so are the ones without the problem.

Yes, I found that patch too and tried it on one of the servers -- no joy.

Guess we'll continue to wait also for now. Maybe 7.2/i386or, until
someone finds the solution since we're out of ideas and stuck with 6.3 in
order to use dump that we have trusted.


Hi,
 I didnt see it in the thread clearly, but did you try 
creating a dump without the -L... i.e. without snapshots enabled ?

 ---Mike 


Yes, but it's for running a dump on a (L)ive FS and just spits out warnings
to that effect and has no effect on solving the problem(s).

Jack

(^_^)
Happy trails,
Jack L. Stone

System Admin
Sage-american
___
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: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)

[Jack L. Stone]

At 09:32 AM 3.26.2009 -0400, Mike Tancsa wrote:
At 08:08 AM 3/26/2009, Jack L. Stone wrote:

Yes, but it's for running a dump on a (L)ive FS and just spits out warnings
to that effect and has no effect on solving the problem(s).

Unless the filesystem is very busy, you will get your data backed up. 
If you have things like databases, I still would not trust 
snapshots.  Better to use pg_dump or mysqldump or the app that comes 
with whatever DB you are using... When backing up things like / and 
/usr, I would hazard a guess that most things are not changing while 
the backup is running, at least they dont in my environments.  I have 
never had a problem with things like /home and even /var or /mail 
which are changing quite a bit.  We dont restore much in the course 
of our daily routine, but we have always been able to restore 
people's Maildir when they accidentally have deleted stuff and it all 
worked without issue over the years.

 ---Mike 

Yes, we have been using the L switch for as long as it has existed
because we have and always before that, backed up live FSes. And, as said
before, we do a dump/restore dump every morning to produce a bootable
clone. The clones have always worked for the many years we have done this.

Indeed, we have always used the MySQL's own dump separately to backup DBs.
But, that's OT.

Jack

(^_^)
Happy trails,
Jack L. Stone

System Admin
Sage-american
___
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: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)

[Jack L. Stone]

At 10:15 AM 3.26.2009 -0400, Mike Tancsa wrote:
At 10:01 AM 3/26/2009, Peter Schuller wrote:
 
  Unless the filesystem is very busy, you will get your data backed up.
  If you have things like databases, I still would not trust
  snapshots.

Uh. If backuping up a live database from a snapshot is not
trustworthy, either the snapshot facility is broken or the database is
broken (i.e., not crash-safe to begin with).

... or the database is configured in a risky way... But judging by 
this thread, it seems dump with -L is indeed broken for some 
people.  Hence, I suggested dumping the database using the database's 
backup tools and trying dump without -L

 ---Mike 

Mike: The L for dumping is definitely NOT the problem.

Jack

(^_^)
Happy trails,
Jack L. Stone

System Admin
Sage-american
___
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: support quality (Re: dump | restore fails: unknown tapeheadertype 1853384566)

[Jack L. Stone]

At 03:49 PM 3.26.2009 +0100, Peter Schuller wrote:
 ... or the database is configured in a risky way... But judging by 
 this thread, it seems dump with -L is indeed broken for some 
 people.  Hence, I suggested dumping the database using the database's 
 backup tools and trying dump without -L

Well, if dump -L is really broken I'd recommend just not using dump
unless you absolutely have to. That is assuming snapshots are not
broken so that you can still use mksnap_ffs with your favorite backup
tool.

-- 
/ Peter Schuller


No one has said the dump L is broken -- and is NOT but now may mislead
others just tuning into this thread.

Jack

(^_^)
Happy trails,
Jack L. Stone

System Admin
Sage-american
___
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: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)

[Jack L. Stone]

At 10:46 AM 3.26.2009 -0500, Karl Denninger wrote:
Jake Scott wrote:

 That said there are plenty of other reasos to use proper dump tools
 (data portability, confirming the ability to actually read all rows
 from a table, using a more often exercised code path and perhaps less
 likely to have edge case bugs, etc).


This thread has drifted off the main issue of using the FS dump/restore
problem.

Although, the DBs may be included as a part of this dump, it should NOT be
relied upon as a backup/restore of DBs. We use MySQL's dump/backup tools
strictly for the DBs. The dumps of the DBs (using MySQL's own dump tool)
here are run by cron jobs every hour or few hours at most. That keeps our
DB backups very recent and near current as possible is a restore is needed.

Jack

(^_^)
Happy trails,
Jack L. Stone

System Admin
Sage-american
___
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: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)

[Jack L. Stone]

At 07:25 PM 3.25.2009 +1030, Daniel O'Connor wrote:
On Wednesday 25 March 2009 18:37:17 Bartosz Stec wrote:
  Yes, dump is broken for you, deal with it. It is quite possible your FS
  is corrupt, and/or your disk is damaged.

 ..and/or it is some other hardware problem, maybe you also should test
 your memory with memtest or something similiar? I'm using dump/restore
 very frequently and I had never seen such problem. Neither on -RELAESE,
 -STABLE, nor -CURRENT.
 So I think you should make sure that your problem is not
 hardware/filesystem dependent before you point dump/restore as a couse
 of the problem. Peter Jeremy already gives you good hints to do that.

One other thing would be to make absolutely sure that your version of dump  
restore are in sync, the are very machine/version dependent.

-- 

I've been watching this thread with some interest since we've had some
similar problems with dump/restore which we use every morning via cron
scripts on a number of servers to produce bootable clones as part of our
backup program. Have been doing this for years and also never saw a problem
as most of you say. We prefer dump/restore for backups.

However, last month upon upon upgrading those servers from FBSD-6.3px
(RELEASE) to 7.0px (RELEASE) we found that about one-half of the servers
had a similar problem as the original poster while the other half did not.
All of the servers (rackmounts) use the same (type) hardware. We spent many
hours trying to solve the problem with those that failed to dump/restore.
Also, searched for any others with the problem and only found a very few,
but without solutions to this issue. (Indeed, the only one was a reference
to any efforts to restore an older OS version which didn't apply here).

And, indeed we tried everything suggested here to fix the proble without
success. Sometimes the problem was dump which would reach 99% and never
finish -- it would stick there and would overlap with another cron start
the next day, and the next day, and the next day. (The servers that did
work fooled us and we found out about this issue on the others when the
overlaps appeared and drew our attention). That's when our work to try and
solve the issues started and went on for days.

Our script that has always worked contained this (after scraping and making
fresh FS):
/sbin/dump -D /root/dumpdates -0auL -f - / | /sbin/restore -rf -

Indeed, the first thing we did was to remove the pipe and tried to restore
from a file. However, because the dumps would not go past the 99%, no file
to restore from! There were some exceptions when the dump would complete,
but was not reliable. When these reached the restore level, restore would
go crazy with errors.

SOLUTION
The clones are a very important pasrt of our backup program. Since the
dump side of the problems simply stuck and provided no error message at all
and the errors from any restores were not useful, our only solution was to
revert back to FBSD-6.3 on those servers with this issue and dump/restore
went back to working again. We left those that were working on FBSD-7.0-R
and they continue to work okay.

We could only conclude that the problem was perhaps something with
hardeware, perhaps the way memory was handled in 7.0, but that is only a
guess.

Once again, every suggestion on this thread was tried during our long
efforts to fix the issue. Perhaps there is yet another suggestion? In the
meantime, we've decided to wait for 7.2R (7.1 did not fix the problems
either).

/Jack

(^_^)
Happy trails,
Jack L. Stone

System Admin
Sage-american
___
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: System borked: loader stack overflow.

[Jack L.]

I got the same thing. I put only the options I needed into loader.conf
and it booted fine.

On Sun, Jan 18, 2009 at 1:33 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
 On Sat, Jan 17, 2009 at 10:09:52PM -0500, Andrew Lankford wrote:
 After rebuilding world from 7-stable after cvsup, I can no longer boot.
 The loader tries to load the kernel but instead locks up  with a stack
 overflow.  Wish I could send more details, but I'll have to find another
 way to boot up my system first.

 just to identify the problem - what was the version of your
 previous loader, and what kind of CPU do you have (Intel or AMD,
 single or multi core) etc.

 (to boot again you can replace /boot/loader with one taken from
 an older 6.3 or 7.0 CD)

 cheers
 luigi
 ___
 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: Recent libxine update seems to cause ICE on 6-STABLE/amd64

[Jack L.]

It fails to compile with the gcc version that comes with FreeBSD 6 and
7, but it compiles fine on gcc 4.1 when I tried. It's probably a
compiler bug that's been fixed on the 4.x series.

On 2/17/07, Andy Fawcett [EMAIL PROTECTED] wrote:

On Thursday, libxine was updated in the ports collection to version 1.1.4

Unfortunately, this seems to cause some kind of compiler-suite error on
6.2-STABLE/amd64.

dsputil.c:3826: error: unrecognizable insn:
(insn 62 10 12 0 (set (reg:SI 0 ax [61])
(subreg:SI (plus:DI (subreg:DI (reg:SI 7 sp) 0)
(const_int -4 [0xfffc])) 0)) -1 (nil)
(nil))
dsputil.c:3826: internal compiler error: in extract_insn, at recog.c:2083
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
gmake[5]: *** [dsputil.lo] Error 1
gmake[5]: Leaving directory
`/usr/ports/multimedia/libxine/work/xine-lib-1.1.4/src/libffmpeg/libavcodec'

Please see PR ports/109213 (raised by another person) for slightly more
context to the error. It's bitten two of us so far, apparently in identical
way.

I'm not sure this should be a ports PR, maybe it should go to the compiler
suite?

Andy

--
Andy Fawcett | [EMAIL PROTECTED]
 | [EMAIL PROTECTED]
In an open world without walls and fences,  | [EMAIL PROTECTED]
  we wouldn't need Windows and Gates.  -- anon  | [EMAIL PROTECTED]
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]


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

Re: [HEADS UP] perl symlinks in /usr/bin will be gone

[Jack L. Stone]

At 06:46 PM 1.30.2005 -0500, Parv wrote:
in message [EMAIL PROTECTED],
wrote Anton Berezin thusly...

 Unless I hear too many cries don't do that (with justification), I
 plan to not create any perl symlinks in /usr/bin in the forthcoming
 upgrade of both lang/perl5.8 (to 5.8.6) and lang/perl5 (to 5.6.2).
 This will ONLY be true for FreeBSD 5.X and FreeBSD CURRENT

I am for it.

Please do do that.

Thanks.
  - Parv

Please don't do it

If this were a mere vote of the respondents, the NAYs have it by far.


Best regards,
Jack L. Stone,
Administrator

SageOne Net
http://www.sage-one.net
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Losing schg flags on tar/un-tar

[Jack L. Stone]

At 02:49 PM 12.23.2002 +0100, Erminio Baranzini wrote:
You should try star, which preserves schg flags.

Erminio Baranzini


Plus, won't the -p switch with tar do it.??? man tar(1)

Best regards,
Jack L. Stone,
Administrator

SageOne Net
http://www.sage-one.net
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message

Re: Poor Mans Software raid 1 on root partition?

[Jack L. Stone]

At 06:03 PM 7.16.2002 +1200, Tortise@Paradise wrote:
  You can get a 3ware 7210 for $120: http://newegg.com
 
  it'll save you a lOT of time and heartache, and it's not that much $$...

 True, but if that 3ware quits making those cards and your card goes, your
 data is completely lost.  And what if you choose not to upgrade each time
 3ware spins the cards?  How much testing does 3ware do against say the
 6000 series?  Can I take my drives on my 68XX card and plug them into a
 78XX card and have them work?  What about if 3ware creates an 88XX series?

 One significant advantage to software RAID is the fact that you can still
 extract your data from the disk even if you have to completely transplant
 the disks to different hardware.



I think what I want to achieve is a second SCSI disc, which is regularly
backed up to in some fashion, although in less than real time be OK. (vis
a vis RAID) so long as it is a bootable reliable backup with a
controllable interval backup.   (Also avoids the hardware reliance.  I have
one machine (W2000) which has a backup RAID card so it can be got running
again quickly..without worrying about sourcing another card. Clearly
this is undesirable...)

Does anyone do this?

Regards
David Hingston MB ChB MBA
_
[EMAIL PROTECTED]
http://hingston.yi.org/
http://pcmc.yi.org/
If you seek a digitally signed response please advise.
If you received a warning on reading this e-mail, please go to
http://www.baycorpid.com/settings/email.asp?CA=healthcert to update your
settings



Please don't take this wrong, but on all OS lists, the emphasis always
seems to be on the backup and very little on the restore -- and I'm
speaking more from the disaster recovery -- to get back up and running
within minutes. In raising the question about that, I have noticed few have
ever tested any sort of backup plans to see if they really can restore,
or how quickly they can restore.

I for one would sure like to hear more about recovery plans. mine is to
use two identical HDs on each server and run DD frequently, with tars for
incremental. Thus, I have found it very simple to shut down, pull the bad
HD, move HD #2 up and re cable it -- then boot and voila! I'm back up.
THEN, add back any incremental while running in the meantime

Yes, critical files are backed up over NFS to other machines and other
types of backups used too, but I 'm only referring to getting up  running
as fast as possible. Tape restore is too slow for me please don't jump
on me about tapes... I use them too but HDs are cheap and I use lost of
them for fast backups and restores.

Just for the sake of discussion. I'd be interested in hearing about
more restores... successful ones... not plans to restore.

Best regards,
Jack L. Stone,
Administrator

SageOne Net
http://www.sage-one.net
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message

Re: Tar broken for large files?

[Jack L. Stone]

At 12:21 PM 5.17.2002 +1000, Andy Farkas wrote:
 Obviousls, tar is not copying things correctly. Is this a known bug?
 # tar --version
 GNU tar version 1.11.2

Our tar is broken for files  2g :(

Install gtar from ports.


I've incurred aborted backups with tar (+ gzip) lately too. What is
superior about gtar...???

 our website: http://www.sage-one.net/

Best regards,

Jack L. Stone
Server Admin

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message