Re: SCSI tape error using Amanda/dump
FWIW, anybody know of a way to rejuvinate corrupted, but otherwise little used tapes? Have you tried a large magnet? Sounds like a joke, but it works on other magnetic media. I used to see these commercial sold to clear VHS tapes. If the tape is otherwise un-usable, give it a try. -- Jim It needs to be a moving magnetic field to wipe a tape, a fixed magnet won't do it, not even a huge one. (I tested once using the 22lb magnets on my 17 woofers, and they wouldn't wipe a floppy or a DAT tape.) A tape head demagnetizer, a transformer, or anything really that generates a good strong magnetic field using alternating current will wipe the media nicely. On the other hand, I've never heard of a DAT tape that you couldn't overwrite following an error, in the 10 years I've been using DAT. I've had a few tapes become so error-prone I've thrown them away, but they're not like pre-formatted with hard sectors or anything. Try using dd to copy from /dev/zero to the tape and if it dies in the same spot every time I'd say the tape is physically bad at that spot. I've had no problems wuth Fuji tapes. (I once read there are really only 3 manufacturers of magnetic tape in the world, and brand name makes little difference. That was about 8-10 years ago though.) -- Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Panic on 'kldunload snd'
Hi Folks! I just started playing with all those modules that are compiled during buildkernel, and was very pleased to see my SoundBlaster AWE64 correctly probed and configured when I did a 'kldload snd'. However, I was (slightly) less pleased to discover that a consequent 'kldunload snd' paniced the kernel. This is on a (cvsuped last night) -STABLE box. I did a bit of a dig around in the PR database and also in the mailing list archives and I _think_ this type of thing is a known problem with the modules system. If this is the case, apologies for the waste of bandwith, but I thought I had better mention it. If anyone is interested however, I do have dump from the panic. Which is good actually because I had enabled crash dumps, but -stable has been so bloody stable I'd never had a dump to play with in kgdb before :-) Thanks Andrew. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: natd
On Tue, 2002-04-02 at 19:47, Tomasz Paszkowski wrote: I'am running a preety big network (about 2k users) with a private addresses. I've been using natd + ipfw for ages and I really like it. But I've run into performance problems. Machine with PIV 1.7Ghz can't afford translating such a pig pool of connections (huge slow down of transfer). Does any one have seen any patches improving natd performacne ? Isn't the correct answer to this ipf + ipnat? You'll never be able to get rid of the performance hit from all the context switching for NATted packets when using natd. -- brandon s allbery [openafs/solaris/japh/freebsd] [EMAIL PROTECTED] system administrator [linux/heimdal/too many hats] [EMAIL PROTECTED] electrical and computer engineering KF8NH carnegie mellon university [better check the oblivious first -ke6sls] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
(hardware?) trouble with make buildworld on 4.5
Hi there, I've been running FreeBSD (mostly 4.2) on multiple systems for over a year and I absolutely love it. Recently I installed 4.5 (from the retail CD set) on a new machine and I'm having difficulty upgrading to stable. My make buildworld dies in seemingly random places. The hardware was newly assembled by me. I suspect that I did something wrong with the hardware; I mean, what are the odds that RELENG_4 is busted only for me? However I lack the skills to trace the root cause of the problem given the following compile failures. Education would be greatly appreciated. My current theory on the failure places blame on the CPU; I think, it is either busted (I broke it) or it is not supported by FreeBSD. The hardware is a Shuttle SV24 (those cute mini-systems everybody raves about) and the CPU is a Via C3 866 (Ezra core or later.) I have a friend who has the same system and a slightly older/slower Via C3 (Samuel core). He upgraded to 4.5-STABLE last night without any problems. Here is the relevant snippet from his dmesg output: CPU: VIA C3 Samuel 2 (751.71-MHz 686-class CPU) Origin = CentaurHauls Id = 0x671 Stepping = 1 Features=0x803035FPU,DE,TSC,MSR,MTRR,PGE,MMX ...Here is mine, note the unrecognized CPU: CPU: IDT Unknown (864.47-MHz 686-class CPU) Origin = CentaurHauls Id = 0x678 Stepping = 8 Features=0x803035FPU,DE,TSC,MSR,MTRR,PGE,MMX In the sys source code, I didn't see the Ezra core mentioned in identcpu.c in the switch statement for CenterHauls CPUs. Should that concern me? Could it be that I broke the motherboard instead? Here are the last 50 lines of two separate make buildworld attempts. Both of which were done last night, after deleting all of /usr/src and /usr/obj, and grabbing fresh from cvsup7.freebsd.org. Thanks in advance for any guidance you can provide. alex -- Alex Edelman [EMAIL PROTECTED] --- cc -O -pipe -I. -I/usr/src/lib/libncurses -I/usr/src/lib/libncurses/../../contrib/ncurses/ncurses -I/usr/src/lib/libncurses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE -DNDEBUG -DHAVE_CONFIG_H -DTERMIOS -c /usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_flash.c -o lib_flash.o cc -O -pipe -I. -I/usr/src/lib/libncurses -I/usr/src/lib/libncurses/../../contrib/ncurses/ncurses -I/usr/src/lib/libncurses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE -DNDEBUG -DHAVE_CONFIG_H -DTERMIOS -c /usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_freeall.c -o lib_freeall.o cc -O -pipe -I. -I/usr/src/lib/libncurses -I/usr/src/lib/libncurses/../../contrib/ncurses/ncurses -I/usr/src/lib/libncurses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE -DNDEBUG -DHAVE_CONFIG_H -DTERMIOS -c /usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_getch.c -o lib_getch.o cc -O -pipe -I. -I/usr/src/lib/libncurses -I/usr/src/lib/libncurses/../../contrib/ncurses/ncurses -I/usr/src/lib/libncurses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE -DNDEBUG -DHAVE_CONFIG_H -DTERMIOS -c /usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_getstr.c -o lib_getstr.o cc -O -pipe -I. -I/usr/src/lib/libncurses -I/usr/src/lib/libncurses/../../contrib/ncurses/ncurses -I/usr/src/lib/libncurses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE -DNDEBUG -DHAVE_CONFIG_H -DTERMIOS -c /usr/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/lib_has_cap.c -o lib_has_cap.o cc -O -pipe -I. -I/usr/src/lib/libncurses -I/usr/src/lib/libncurses/../../contrib/ncurses/ncurses -I/usr/src/lib/libncurses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE -DNDEBUG -DHAVE_CONFIG_H -DTERMIOS -c /usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_hline.c -o lib_hline.o cc -O -pipe -I. -I/usr/src/lib/libncurses -I/usr/src/lib/libncurses/../../contrib/ncurses/ncurses -I/usr/src/lib/libncurses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE -DNDEBUG -DHAVE_CONFIG_H -DTERMIOS -c /usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_immedok.c -o lib_immedok.o cc -O -pipe -I. -I/usr/src/lib/libncurses -I/usr/src/lib/libncurses/../../contrib/ncurses/ncurses -I/usr/src/lib/libncurses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE -DNDEBUG -DHAVE_CONFIG_H -DTERMIOS -c /usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_inchstr.c -o lib_inchstr.o cc -O -pipe -I. -I/usr/src/lib/libncurses -I/usr/src/lib/libncurses/../../contrib/ncurses/ncurses -I/usr/src/lib/libncurses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE -DNDEBUG -DHAVE_CONFIG_H -DTERMIOS -c /usr/src/lib/libncurses/../../contrib/ncurses/ncurses/base/lib_initscr.c -o lib_initscr.o cc -O -pipe -I. -I/usr/src/lib/libncurses -I/usr/src/lib/libncurses/../../contrib/ncurses/ncurses -I/usr/src/lib/libncurses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE -DNDEBUG -DHAVE_CONFIG_H -DTERMIOS -c
ata still breaks raid
tried cvsup again today [04/02/2002 14:00 PST] after noticing new code in repository relative to via northbridges ... same results as reported before ... 4.5-STABLE breaks the raid array and panics to an awkward halt. I am positive that if the ata system worked at least as well as it does in 4.5-RELEASE I wouldn't be plaguing the list with these frequent reports on attemtps to get 4.5-STABLE installed. I mean - 4.5-RELEASE manages to create and use ar0 with no trouble on the same equipment 4.5-STABLE fails on with relentless consistency. Therefore, it seems as though the differenc between having a working sever and a broken one is whatever difference there is between 4.5-RELEASE and 4.5-STABLE. A little more data is offered here (I'd still like someone to give me feedback on what other data or tests I can provide - haven't got any replies yet that moves this break in STABLE along) ... I noticed that the 4.5-RELEASE install on the same box that works(does it really?) shows some other errors in the ata sub-system as noted before the mb in question is an Abit KR7A-RAID with the KT266 chipset (VIA VT8366A /VT8233), yet look at this line from dmesg atapci0: VIA 82C686 ATA100 controller port 0xc400-0xc40f at device 17.1 on pci0 as far as this humble correspondent believes, there isn't a 686 chip on the mb - so, what's up with that? Is that a symptom that the ata code has a break in it that goes back to 4.5r or before? 4.5r misidentifies a hpt372 as an udma 5 device and when 4.5r boots it resets udma 6 drives to udma 5. That I understand to be a matter of developing code and that 4.5s does udma 6. 4.5-RELEASE dmesg appended in hopes there might be some demi-clueful data for anyone who cares about the ata sub-system. I am willing to provide any other data from the machine 4.5-STABLE breaks and there is a window of time still available for whatever tests might produce useful info, if only I knew what any maintainer might need to know. Pan * 4.5r dmesg KRA-R/hpt372 boot_verbose verbose_loading* Copyright (c) 1992-2002 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 4.5-RELEASE #0: Mon Mar 25 14:07:06 PST 2002 xxx Calibrating clock(s) ... TSC clock: 1600825917 Hz, i8254 clock: 1193289 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method Timecounter TSC frequency 1600690919 Hz CPU: AMD Athlon(tm) XP 1900+ (1600.69-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x662 Stepping = 2 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA, CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc048b19,AMIE,DSP,3DNow! Data TLB: 32 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 1073676288 (1048512K bytes) Physical memory chunk(s): 0x1000 - 0x0009, 651264 bytes (159 pages) 0x00312000 - 0x3ffe7fff, 1070424064 bytes (261334 pages) avail memory = 1042759680 (1018320K bytes) bios32: Found BIOS32 Service Directory header at 0xc00fb030 bios32: Entry = 0xfb4a0 (c00fb4a0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xb4d0 pnpbios: Found PnP BIOS data at 0xc00fbfa0 pnpbios: Entry = f:bfd0 Rev = 1.0 Other BIOS signatures found: ACPI: 000f6e00 Preloaded elf kernel kernel at 0xc02eb000. Preloaded userconfig_script /boot/kernel.conf at 0xc02eb09c. VESA: information block 56 45 53 41 00 02 b0 0e 00 c0 00 00 00 00 f6 0e 00 c0 20 00 01 01 cf 0e 00 c0 e0 0e 00 c0 ee 0e 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 VESA: 45 mode(s) found VESA: v2.0, 2048k memory, flags:0x0, mode table:0xc00c0ef6 (cef6) VESA: S3 Incorporated. ViRGE /DX /GX VESA: S3 Incorporated. ViRGE /DX /GX Rev B Pentium Pro MTRR support enabled md0: Malloc disk Creating DISK md0 pci_open(1): mode 1 addr port (0x0cf8) is 0x80008840 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=30991106) Using $PIR table, 8 entries at 0xc00fdef0 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard found- vendor=0x1106, dev=0x3099, revid=0x00 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 map[10]: type 1, range 32, base e000, size 26 found- vendor=0x1106, dev=0xb099, revid=0x00 class=06-04-00, hdrtype=0x01, mfdev=0 subordinatebus=1 secondarybus=1 found- vendor=0x11ad, dev=0x0002, revid=0x11 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=12 map[10]: type 1, range 32, base c000, size 8 map[14]:
netgear switch RO318 and -STABLE
I am having a problem deciding on a correct routing for this question, please feel free to direct me to a more appropriate place if you feel this is an off-topic request. I have a small home network with two BSD machines running -STABLE from Feb 13: BSD (192.168.0.4)--Netgear(hostname switch=192.168.0.1)--BSD (hostname kot=192.168.0.2) kot has a 3C905C-TX-M network card. Default route is 192.168.0.1 for both machines. This setup worked for about a month, but suddenly stopped working today for no apparent reason.kot obtains a fixed IP from switch via dhcp; and after that I cannot connect to switch from kot, i.e. pings don't work, etc. The weird thing is that tcpdump still reports icmp echo request/reply exchange, but ping command reports no replies: # ping switch PING switch (192.168.0.1): 56 data bytes ^C # tcpdump tcpdump: listening on xl0 22:44:16.113827 192.168.0.2 switch: icmp: echo request 22:44:16.115367 switch 192.168.0.2: icmp: echo reply 22:44:16.360259 192.168.0.2.1082 switch.domain: 46246+ PTR? 2.0.168.192.in-ad dr.arpa. (42) 22:44:16.371680 switch.domain 192.168.0.2.1082: 46246 NXDomain 0/1/0 (114) (D F) 22:44:17.11 192.168.0.2 switch: icmp: echo request 22:44:17.123572 switch 192.168.0.2: icmp: echo reply 22:44:18.132232 192.168.0.2 switch: icmp: echo request 22:44:18.133575 switch 192.168.0.2: icmp: echo reply 22:44:19.142263 192.168.0.2 switch: icmp: echo request 22:44:19.143618 switch 192.168.0.2: icmp: echo reply 22:44:20.152283 192.168.0.2 switch: icmp: echo request 22:44:20.153794 switch 192.168.0.2: icmp: echo reply 22:44:21.162323 192.168.0.2 switch: icmp: echo request 22:44:21.163670 switch 192.168.0.2: icmp: echo reply If I change kot's address to 192.168.0.3, everything works normal as before. Why would not ping command report icmp replies that tcpdump shows, any ideas? -- Vladimir To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: cvs commit: src/sbin/atacontrol atacontrol.8 atacontrol.c
It seems Mike Tancsa wrote: At 08:58 AM 4/2/02 +0200, Søren Schmidt wrote: If a disk in a RAID1 goes bad, the driver will continue to use the good half of the mirror, and log the fact that the mirror is now in degraded mode. You can then use atacontrol to detach the disk, add a new one, and use atacontrol to rebuild the array, all without having to take down the machine. If the last good disk fail, the driver will log that the array is broken, and return error on all accesses... And yes I'll add a get status/mode command :) Awesome! I just tried it on our test machine. raidtest2# atacontrol status ar0 ar0: ATA RAID1 subdisks: ad8 ad10 status: READY raidtest2# Also, I updated a few other boxes that have atapci0: VIA 82C686 ATA100 controller port 0xe000-0xe00f at device 7.1 on pci0 and so far so good! Also, what would you recommend for hot swapable trays ? The promise superswap enclosures, they are a bit pricy, but I support setting the LED color on the front for show the disk status, and you get get the fan speed/disk temperature/disk voltages form the superswap with atacontrol, very handy for servers :)... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Own iso CD
Hello, Otterr! On Tue, Apr 02, 2002 at 06:56:21PM -0500, you wrote: Sure. Assuming that's the last patch level of 4.4, you can start by reading /usr/src/Makefile, make the necessary settings in it, make sure you have a CVSROOT environment variable set, and use the tag RELENG_4_4. Enjoy. -Otter The question not in standard mini-install ISO, but official *4* CD set I have similar question. I'd like to build own 4CD set for 4.4-RELEASE-p9 which will contain same contents which official CD set contains. -- NEVE-RIPE To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
