VIRUS IN YOUR MAIL
V I R U S A L E R T Our viruschecker found the W32/[EMAIL PROTECTED] virus(es) in your email to the following recipient(s): - [EMAIL PROTECTED] Delivery of the email was stopped! Please check your system for viruses, or ask your system administrator to do so. For your reference, here are the headers from your email: - BEGIN HEADERS - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Mail Delivery (failure [EMAIL PROTECTED]) Date: Fri, 3 Dec 2004 13:39:06 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type=multipart/alternative; boundary==_NextPart_000_001B_01C0CA80.6B015D10 X-Priority: 3 X-MSMail-Priority: Normal -- END HEADERS -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: is it possible to mount a vinum-fs on 2 hosts?
I would love to see a cluster capable filesystem for freebsd. I do not know if this will help your situation but I have seen people mount the file system read/write on Host A and then mount the file system from Host A via NFS on Host B. This allows B to write to the file system using A. Michael Grant On Sun, Dec 12, 2004 at 09:41:28PM -0800, Doug White wrote: On Thu, 9 Dec 2004, Michael Schuh wrote: I hav Host A andHost B both are connected to an SAN through an QLA2200 Fibre-Channel (man isp). On the SAN are 14 Disks da0-da13 these Disks are configured w/ vinum to an RAID 10 Filesystem. Now i have the Problem i would make Host A to an PDC and HOST B to an BDC. To be redundant in an fail of the PDC (Host A) i would have access to the SAN from BDC (Host B). Now i Know the Problem of an already mounted Filesystem. I would mount the Filesystem on both Hosts, may i cannot update the Filesystemdescriptors from Host A on Host B. FreeBSD does not currently ship with a cluster-capable filesystem, so this configuration is not supported out of the box. Unless someone offers a cluster-capable filesystem as an addon product ... and I guess that's what your fishing for :) -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
code to allegedly support realtek gigabit ethernet for 4.x available
e First of all, sorry for the delay in this -- I had hoped to get this done in time for the 4.11 code freeze, but I don't feel this is yet ready for inclusion into 4.x, until a couple of observed issues are resolved. What good is support if it's somewhat broken? Anyway, I've taken the if_re code from -current and patched it so that it can build by hand as a kernel module with recent 4.x source. This is code to support the Realtek (shut up, I know already) gigabit ethernet chips, that are making their way onto the market in rather low-priced gig-e cards (we're talking the ten euro or so range). There are a few issues that need to be fixed before this code is a candidate for RELENG_4, as follows: *) I think manually setting interface media doesn't work; at least, it didn't work on the two cards I acquired. I have a hack that does let me specify the link speed/duplex, though it's not quite the same as forcing the settings. From reading the code, I suspect this is also a problem in 5.x and -current; I experienced the same with NetBSD as with my hacks on 4.x. Or else my cards/chipsets are properly buggered. *) My hacks to the latest -current code has introduced some new kernel messages ``re0: PHY write failed'' when setting media options, but this doesn't seem to hurt anything. I want to fix this though. As per the above, this seems somewhat pointless, anyway -- autoselect seems to work fine for all speeds. *) Most seriously, I think I'm getting corrupt data, shown by errors being thrown when transporting data wrapped by zlib or similar. This is a show-stopper, though superficially things seemed to work (I don't have much of a network with which to test things). Rather than let my hacks languish, like they have over the past few months, I thought I'd put a pointer to this work-in-progress, for anyone who wants to try it out. It's not a clean patch yet, so some familiarity with source layout is required, as well as access to the -current source. And, of course, the hardware. And as usual, the apology/disclaimer, that I have no clue what I'm doing, and there are no doubt absolutely boneheaded examples of my ignorance in my patches. Which you're welcome to fix after giving me a good scolding. The hacks that I've come up with can be downloaded from https://nospam.dyndns.dk/hacks/if_re/ for a short time (if unavailable, I've had to turn my machine off overnight or am again unable to be online) from the time I post this. In particular, pay attention to https://nospam.dyndns.dk/hacks/if_re/README which I keep updated to reflect the status of the patches present, and which tells what you need to do, as well as which of the files present in the above directory are relevant. Not for beginners. After I resolve the show-stopper issues, I'll submit a clean diff for review and widespread testing for potential inclusion into post-4.11 RELENG_4, but I can't say when that will be, so I'm making available what I've done so far for any interested parties. Please keep any followup on the list, as I'm probably going to be unable to be online after a few days. And feel free to adopt this code and treat it as your own, as I'm rather negligent in my responsibility to it these days. thanks barry bouwsma ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hw.ata.ata_dma=0: can I do this during bootup at the
* Erik Hollensbe [EMAIL PROTECTED] [041211 16:55]: Hi Erik, I have to dispatch a atacontrol mode 1 foo UDMA33 You can use /etc/rc.early for that. You'll have to create it if it doesn't yet exist. Put 'atacontrol mode 1 foo UDMA33' in it, and it should execute that command before mounting the drives. Note that you can put this in loader.conf as well - if you're having trouble booting the system to do it, boot to safe mode - should get you in. are you sure you can call atacontrol(1) from within loader.conf? I don't want to disable DMA (by setting hw.ata.ata_dma=0), just a slower DMA mode for a single device. Otherwise the fsck on this device will fail with read errors. I will try rc.early, thanks for the suggestion. Best regards Christian -- http://www.lackas.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: TIMEOUT - WRITE_DMA on SATA disc
Hello, I have the same problem with my 5.3-RELEASE GENERIC kernel. --CUT-- Nov 27 14:38:02 altair kernel: ad2: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=26344735 --CUT-- --CUT-- Dec 7 18:02:11 altair kernel: ad2: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=70378111 Dec 7 18:02:12 altair kernel: ad2: WARNING - removed from configuration Dec 7 18:02:12 altair kernel: ata1-master: FAILURE - WRITE_DMA timed out --CUT-- --CUT-- Dec 7 19:02:17 altair kernel: Copyright (c) 1992-2004 The FreeBSD Project. Dec 7 19:02:17 altair kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Dec 7 19:02:17 altair kernel: The Regents of the University of California. All rights reserved. Dec 7 19:02:17 altair kernel: FreeBSD 5.3-RELEASE #0: Fri Nov 5 04:19:18 UTC 2004 Dec 7 19:02:17 altair kernel: [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Dec 7 19:02:17 altair kernel: Timecounter i8254 frequency 1193182 Hz quality 0 Dec 7 19:02:17 altair kernel: CPU: Intel(R) Pentium(R) 4 CPU 1.50GHz (1500.07-MHz 686-class CPU) Dec 7 19:02:17 altair kernel: Origin = GenuineIntel Id = 0xf12 Stepping = 2 Dec 7 19:02:17 altair kernel: Features=0x3febf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV ,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2 ,SS,HTT,TM Dec 7 19:02:17 altair kernel: real memory = 402587648 (383 MB) Dec 7 19:02:17 altair kernel: avail memory = 384249856 (366 MB) Dec 7 19:02:17 altair kernel: npx0: [FAST] Dec 7 19:02:17 altair kernel: npx0: math processor on motherboard Dec 7 19:02:17 altair kernel: npx0: INT 16 interface Dec 7 19:02:17 altair kernel: acpi0: VIAP4X AWRDACPI on motherboard Dec 7 19:02:17 altair kernel: acpi0: Power Button (fixed) Dec 7 19:02:17 altair kernel: Timecounter ACPI-fast frequency 3579545 Hz quality 1000 Dec 7 19:02:17 altair kernel: acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 Dec 7 19:02:17 altair kernel: cpu0: ACPI CPU (3 Cx states) on acpi0 Dec 7 19:02:17 altair kernel: acpi_button0: Power Button on acpi0 Dec 7 19:02:17 altair kernel: acpi_button1: Sleep Button on acpi0 Dec 7 19:02:17 altair kernel: pcib0: ACPI Host-PCI bridge port 0x500-0x50f,0x400-0x47f,0xcf8-0xcff on acpi0 Dec 7 19:02:17 altair kernel: pci0: ACPI PCI bus on pcib0 Dec 7 19:02:17 altair kernel: agp0: VIA Generic host to PCI bridge mem 0xe800-0xebff at device 0.0 on pci0 Dec 7 19:02:17 altair kernel: pcib1: PCI-PCI bridge at device 1.0 on pci0 Dec 7 19:02:17 altair kernel: pci1: PCI bus on pcib1 Dec 7 19:02:17 altair kernel: pci1: display, VGA at device 0.0 (no driver attached) Dec 7 19:02:17 altair kernel: ndis0: Linksys Wireless-G PCI Adapter with SpeedBooster mem 0xef00-0xef001fff irq 10 at device 10.0 on pci0 Dec 7 19:02:17 altair kernel: ndis0: NDIS API version: 5.0 Dec 7 19:02:17 altair kernel: ndis0: Ethernet address: 00:0f:66:76:7b:d6 Dec 7 19:02:17 altair kernel: ndis0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps Dec 7 19:02:17 altair kernel: ndis0: 11g rates: 6Mbps 9Mbps 12Mbps 18Mbps 36Mbps 48Mbps 54Mbps Dec 7 19:02:17 altair kernel: rl0: RealTek 8139 10/100BaseTX port 0xd000-0xd0ff mem 0xef002000-0xef0020ff irq 10 at device 13.0 on pci0 Dec 7 19:02:17 altair kernel: miibus0: MII bus on rl0 Dec 7 19:02:17 altair kernel: rlphy0: RealTek internal media interface on miibus0 Dec 7 19:02:17 altair kernel: rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Dec 7 19:02:17 altair kernel: rl0: Ethernet address: 00:07:95:1d:0e:cb Dec 7 19:02:17 altair kernel: isab0: PCI-ISA bridge at device 17.0 on pci0 Dec 7 19:02:17 altair kernel: isa0: ISA bus on isab0 Dec 7 19:02:17 altair kernel: atapci0: VIA 8233 UDMA100 controller port 0xd400-0xd40f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 17.1 on pci0 Dec 7 19:02:17 altair kernel: ata0: channel #0 on atapci0 Dec 7 19:02:17 altair kernel: ata1: channel #1 on atapci0 Dec 7 19:02:17 altair kernel: uhci0: VIA 83C572 USB controller port 0xd800-0xd81f irq 5 at device 17.2 on pci0 Dec 7 19:02:17 altair kernel: uhci0: [GIANT-LOCKED] Dec 7 19:02:17 altair kernel: usb0: VIA 83C572 USB controller on uhci0 Dec 7 19:02:17 altair kernel: usb0: USB revision 1.0 Dec 7 19:02:17 altair kernel: uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Dec 7 19:02:17 altair kernel: uhub0: 2 ports with 2 removable, self powered Dec 7 19:02:17 altair kernel: uhci1: VIA 83C572 USB controller port 0xdc00-0xdc1f irq 5 at device 17.3 on pci0 Dec 7 19:02:17 altair kernel: uhci1: [GIANT-LOCKED] Dec 7 19:02:17 altair kernel: usb1: VIA 83C572 USB controller on uhci1 Dec 7 19:02:17 altair kernel: usb1: USB revision 1.0 Dec 7 19:02:17 altair kernel: uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Dec 7 19:02:17 altair kernel: uhub1: 2 ports with 2 removable, self powered Dec 7 19:02:17 altair kernel: uhid0: APC Back-UPS ES 500 FW:801.e3.D USB FW:e3, rev 1.10/1.06, addr 2, iclass 3/0 Dec 7 19:02:17 altair kernel: uhci2: VIA 83C572 USB controller port
RE: netstat fails with memory allocation error and error in kvm_read
On Mon, 13 Dec 2004, J. Martin Petersen wrote: We are trying to gather some debug information for a problem that is difficult to diagnose, as the machine always ends up hard frozen (does not do anything, can not break to debugger, does not respond to keyboard, etc.), so we are dumping output from netstat, vmstat, iostat etc. quite often. The cron jobs fail ever so often with error messages I do not quite understand, and I can not find anything relevant in the archives. Can anyone shed some light on this? Command: netstat -r Error message: netstat: kvm_read: Bad address Debug before: http://www.aub.dk/~jmp/fw/debug-2004.12.09-21.34.41.gz Debug after: http://www.aub.dk/~jmp/fw/debug-2004.12.09-21.35.06.gz # errors: 7 Command: netstat -an Error message:netstat: sysctl: net.inet.udp.pcblist: Cannot allocate memory Debug before: http://www.aub.dk/~jmp/fw/debug-2004.12.09-07.38.48.gz Debug after: http://www.aub.dk/~jmp/fw/debug-2004.12.09-07.39.04.gz # errors: 3 You appear to be running out of kernel memory. Since you're capturing the output of vmstat -m, you should check that for any bins that are growing at a high rate of speed. Seems possible that its in pf :) I've checked the numbers from just before the freeze (it's within 15 secs) with two sets of data: From a fresh boot and five minutes minutes before the freeze. You might also log 'sysctl vm.kvm_free' and 'sysctl vm.zone'. Here are the stuff that changed significantly between the fresh boot and just before the freeze: Just before the freeze (http://www.aub.dk/~jmp/fw/tmp/debug-2004.12.11-22.59.01.gz): AR driver 2 1K268K 2922822 64,256,512,2048 kqueue 0 0K 38K 13304405 128,1024 UFS dirhash 44488K107K 2559 16,32,64,128,256,512,1024,2048,4096 freeblks13 4K 29K 103030 256 freefrag 0 0K 1K 164217 32 allocindir 28718K162K 1966413 64 indirdep 1 1K209K 9925 32 allocdirect27 4K 18K 301048 128 inodedep18 131K150K 164032 128,256 routetbl 56647K 67K 800649 16,32,64,128,256 subproc99 301K849K 1873146 32,4096 Five minutes before the freeze (http://www.aub.dk/~jmp/fw/tmp/debug-2004.12.11-22.55.42.gz): AR driver 2 1K268K 2921793 64,256,512,2048 kqueue 0 0K 38K 13296556 128,1024 UFS dirhash 44488K107K 2559 16,32,64,128,256,512,1024,2048,4096 freeblks 1 1K 29K 102978 256 freefrag 0 0K 1K 164153 32 allocindir 0 0K162K 1965284 64 indirdep 0 0K209K 9921 32 allocdirect 1 1K 18K 300886 128 inodedep14 130K150K 163954 128,256 routetbl 56246K 67K 800255 16,32,64,128,256 subproc99 301K849K 1872250 32,4096 From a fresh boot (http://www.aub.dk/~jmp/fw/tmp/debug-2004.12.11-23.31.31.gz): AR driver 2 1K190K23450 64,256,512,2048 kqueue 0 0K 3K 1062 128,1024 UFS dirhash3613K 13K 42 16,32,512,2048,4096 freeblks 11529K 29K 253 256 freefrag 0 0K 1K 51 32 allocindir 2 1K135K 3332 64 indirdep10 1K173K 630 32 allocdirect 2 1K 40K 456 128 inodedep 137 145K168K 506 128,256 routetbl 30626K 27K 495 16,32,64,128,256 subproc 107 317K466K 1554 32,4096 The numbers for pflog and pf_if does not change at all. I checked vmstat -z, and the highest pf-related entries we're actually decreasing at the time of the deadlock, but I noticed the following: VM OBJECT: 132,0, 31508, 2132, 14364021 128 Bucket: 524,0,727, 1,0 64 Bucket: 268,0, 23, 19,0 32 Bucket: 140,0, 34, 22,0 16 Bucket:76,0, 15, 35,0 Can you or anyone else deduce anything from the numbers? If not, I'll whip something together that runs vmstat -m ever so often, parses the output and remove the non-increasing entries so it'll be easier to spot the trends. Thanks, Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: drive failure during rebuild causes page fault
On Sun, 12 Dec 2004, Joe Rhett wrote: On Sun, Dec 12, 2004 at 09:59:16PM -0800, Doug White wrote: Thats a nice shotgun you have there. Yessir. And that's what testing is designed to uncover. The question is why this works, and how do we prevent it? I'm sure Soren appreciates you donating your feet to the cause :) Why it works: the system assumes the administrator is competent enough to not yank a disk that is being rebuilt to. Is there a proper way to handle these sort of events? If so, where is it documented? And fyi just pulling the drives causes the same failure so that means that RAID1 buys you nothing because your system will also crash. This is why I don't trust ATA RAID for fault tolerance -- it'll save your data, but the system will tank. Since the disk state is maintained by the OS and not abstracted by a separate processor, if a disk dies in a particularly bad way the system may not be able to cope. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: is rebooting after a page fault disabled in 5.3-release?
On Sun, 12 Dec 2004, Joe Rhett wrote: As another side note, is there a reason that 5.3 doesn't reboot after page faults? The crash and dumpdev man pages still indicate that it should. This makes this problem hard to work on (must be at facility to debug..) It reboots fine on my systems. Do you have DDB compiled in without KDB_UNATTENDED? Or is there a new/undocumented configuration option? On Sun, Dec 12, 2004 at 09:41:59PM -0800, Joe Rhett wrote: And another, I can now confirm that it is fairly easy to kill 5.3-release during the rebuilding process. The following steps will cause a kernel page fault consistently: ... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x10 current process = 1063 (rebuilding ar0 1%) trap number = 12 panic: page fault -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: putty times out on 5.3 box
On Dec 12, [EMAIL PROTECTED] wrote: I can't seem to get remote access anymore but at the site everything seems to work?? I run a webserver and all the sites run fine but all of a sudden no more access through putty, or ftp. The only thing that is diff is I enabled ipfw but only open. It was always slow to get in using putty but now it just times out. the box is a dual amd w/512 mb ram and otherwise seems fine. I'm just stumped. Does it work with other ssh clients? There were changes to the default authentication method for ssh (keyboard interactive vs. password) that might give you problems with some clients. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
QEMU
Is anybody running qemu successfully on 5-stable? I'm trying to boot a knoppix live-cd from iso-image with: qemu -cdrom knoppix.iso -boot d It always reboots the computer (no core-dump, no panic, just reboot - and that's as user-started process, not under root). Same thing under X11 or console. I've never used qemu before, so it could be my fault :) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Questions about GEOM and MIRROR
Hi. I just added two disks (ad4 ad6, SATA 160Go) to my FreeBSD box. I want to use them in the following configuration: - ad4s1 ad6s1: geom mirror of 80Go containing all my precious data (/, /usr, /var, /home) - ad4s2b: swap - ad4s2x, ad6s2x: non-important data On the mirror (ad4s1+ad6s1), I created partitions for /, /tmp, /usr, and /var. Is there any pitfall in doing so? Do I have to be careful to keep extra space somewhere? (such as one sector at the end of ad4s1/ad6s1) I can't seem to place bootcode at the beginning of the mirror: # bsdlabel /dev/mirror/precious # /dev/mirror/precious: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 524288 164.2BSD 2048 16384 32776 c: 1677667310unused0 0 # raw part, don't edit d: 2097152 5243044.2BSD 2048 16384 28552 e: 524288 26214564.2BSD 2048 16384 32776 f: 164620971 31457444.2BSD 2048 16384 28552 # bsdlabel -B /dev/mirror/precious bsdlabel: Geom not found What does this error mean? Thanks in advance. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: QEMU
Ivan Voras wrote: Is anybody running qemu successfully on 5-stable? I'm trying to boot a knoppix live-cd from iso-image with: qemu -cdrom knoppix.iso -boot d It always reboots the computer (no core-dump, no panic, just reboot - and that's as user-started process, not under root). Same thing under X11 or console. I've never used qemu before, so it could be my fault :) I ran the NetBSD 2.0 LiveCD with QEMU last night with no problems (as my normal user and not as root): $ qemu -boot d -cdrom i386live.iso $ pkg_info | grep qemu qemu-0.6.1s.20041115 QEMU CPU Emulator $ uname -v FreeBSD 5.3-STABLE #28: Sun Dec 12 02:01:55 CST 2004... Last night was actually my first time to use QEMU. I was impressed that it was so easy to use. In fact, I was up and running in literally 15 seconds. Take *that* MS Virtual PC 2004 SP1... Jon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
thx to all that helped w/ putty or sshd problem
most of the problem was w/ my dns conf. but the other suggestions opened my eyes to alot thx. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.296 / Virus Database: 265.5.1 - Release Date: 12/13/2004 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: drive failure during rebuild causes page fault
On Sun, Dec 12, 2004 at 09:59:16PM -0800, Doug White wrote: Thats a nice shotgun you have there. On Sun, 12 Dec 2004, Joe Rhett wrote: Yessir. And that's what testing is designed to uncover. The question is why this works, and how do we prevent it? On Mon, Dec 13, 2004 at 10:28:53AM -0800, Doug White wrote: I'm sure Soren appreciates you donating your feet to the cause :) That's what sandbox feet are for ;-) Why it works: the system assumes the administrator is competent enough to not yank a disk that is being rebuilt to. Yes, I and most others are. But that's a bad assumption. The issue is fairly simple -- what occurs if the disk goes offline for a hardware failure? For example, that SATA interface starts having problems. We replace the drive, assuming it is the drive. The rebuild starts, and the interface dies again. Bam! There goes the system. Not good. Or, perhaps it's a DOA drive and it fails during the rebuild? Is there a proper way to handle these sort of events? If so, where is it documented? And fyi just pulling the drives causes the same failure so that means that RAID1 buys you nothing because your system will also crash. This is why I don't trust ATA RAID for fault tolerance -- it'll save your data, but the system will tank. Since the disk state is maintained by the OS and not abstracted by a separate processor, if a disk dies in a particularly bad way the system may not be able to cope. Yes, but SATA isn't limited by this problem. It does have a processor per disk. (this is all SATA, if I didn't make that clear) -- Joe Rhett Senior Geek Meer.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sys/bitypes.h (4.10)?
Doug White [EMAIL PROTECTED] wrote: I see a bitypes.h that ships with BIND (and is in src/contrib/bind), but there isn't an independent FreeBSD version. I suspect someone or something thought it'd be clever to sneak that in .. it should be OK to remove. Turns out the dns/bind8 and dns/bind84 ports install sys/bitypes.h, and if built with PORT_REPLACES_BASE_BIND8_INCLUDES, that header file ends up as /usr/include/sys/bitypes.h. I'm contacting the bind ports maintainer. -- Christian naddy Weisgerber [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: putty times out on 5.3 box
Have you actually tried connecting to port 22 via telnet or nc? If that does work, PuTTY has a tons of debugging options to show you where things have failed. If the debugging output gives you headaches send the output to [EMAIL PROTECTED] for some super help. ;) You can send me the output off list if it's a significant amount. Will On Mon, 13 Dec 2004, Mike Hunter wrote: =On Dec 12, [EMAIL PROTECTED] wrote: = = = I can't seem to get remote access anymore but at the site everything seems to = work?? I run a webserver and all the sites run fine but all of a sudden no more = access through putty, or ftp. The only thing that is diff is I enabled ipfw but = only open. It was always slow to get in using putty but now it just times out. = the box is a dual amd w/512 mb ram and otherwise seems fine. I'm just stumped. =Does it work with other ssh clients? There were changes to the default =authentication method for ssh (keyboard interactive vs. password) that =might give you problems with some clients. =___ =[EMAIL PROTECTED] mailing list =http://lists.freebsd.org/mailman/listinfo/freebsd-stable =To unsubscribe, send any mail to [EMAIL PROTECTED] = -- Will Froning Unix Sys. Admin. [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Fw: Re: Installation attempt results in shutdown
-Original Message- From: David Jonsson [EMAIL PROTECTED] To: dima [EMAIL PROTECTED] Date: Thu, 9 Dec 2004 17:57:29 +0100 Subject: Re: Installation attempt results in shutdown 2.3.1.1, stage 6. I get some alternatives to choose, and there is a ASCII-FreeBSD deamon at the right hand of the screen. It prints some lines, and then dies. I have tried using 5.3 getting the same result, at the same place. I tried using the same CD on my stationary computer, and it worked like a charm (not counting that the installation died midways, and screwed my windows partition :)). /David On Thu, 09 Dec 2004 18:49:40 +0300, dima [EMAIL PROTECTED] wrote: Btw, the most recent *stable* release is 5.3. You'd better use this one. What do you mean an alternative on the first menu? Please choose the stage you experience shutdown in from the following link: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install-start.html Hello! I am trying to install FreeBSD on my laptop (HP/Compaq nx9105), but as soon as I choose an alternative on the first menu that appears my computer shuts down. It happened both with 5.1 and 5.2.1, and it happens no matter which alternative I choose. I really have no clue what to do. I have tried asking around, but most people told me to send a mail to this adress, so I would be really happy if you have an answer for me :) Thanks in advance /David ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: Installation attempt results in shutdown
Seems to be a widely suffered ACPI issue... Have you tried different choices from the boot menu? 1) booting with ACPI disabled 2) safe mode 3) with verbose kernel logging Could you tell us if 1) a choice from above would help you to boot 2) the last messages with verbose logging enabled (well, if you'd manage to see them) -Original Message- From: David Jonsson [EMAIL PROTECTED] To: dima [EMAIL PROTECTED] Date: Thu, 9 Dec 2004 17:57:29 +0100 Subject: Re: Installation attempt results in shutdown 2.3.1.1, stage 6. I get some alternatives to choose, and there is a ASCII-FreeBSD deamon at the right hand of the screen. It prints some lines, and then dies. I have tried using 5.3 getting the same result, at the same place. I tried using the same CD on my stationary computer, and it worked like a charm (not counting that the installation died midways, and screwed my windows partition :)). /David On Thu, 09 Dec 2004 18:49:40 +0300, dima [EMAIL PROTECTED] wrote: Btw, the most recent *stable* release is 5.3. You'd better use this one. What do you mean an alternative on the first menu? Please choose the stage you experience shutdown in from the following link: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install-start.html Hello! I am trying to install FreeBSD on my laptop (HP/Compaq nx9105), but as soon as I choose an alternative on the first menu that appears my computer shuts down. It happened both with 5.1 and 5.2.1, and it happens no matter which alternative I choose. I really have no clue what to do. I have tried asking around, but most people told me to send a mail to this adress, so I would be really happy if you have an answer for me :) Thanks in advance /David ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: QEMU
Jon Noack wrote: Roland Smith wrote: On Mon, Dec 13, 2004 at 08:03:00PM +0100, Ivan Voras wrote: Is anybody running qemu successfully on 5-stable? I'm trying to boot a knoppix live-cd from iso-image with: I tried to build it from ports on amd64 but the compiler segfaulted. :-( So it might be interesting to know what platform you're running on. From the compiler output I could see a lot of size mismatch warnings, i.e. 64 bit issues. Works fine for me on i386. Sorry, pilot error. It seems that my kernelworld were too far unmatched. I've rebuilt kernelworld and it works now. (great that FreeSBIE is built with hz=1000 now!) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hushlogin attribute
Rostislav Krasny [EMAIL PROTECTED] writes: Yes, there are few words about one should run 'cap_mkdb /etc/login.conf' after each change. But this is not what I propose to add to the manual page and /etc/login.conf is not a manual page by itself. At first I wasn't pay attention to these lines at all because I already read the manual and I instinctively wasn't expected to find any new information in /etc/login.conf. FreeBSD 4.8 Errata have a much better explanation than lines 3 and 5 on /etc/login.conf. Why not to add something like that to the login.conf(5) manual page? That makes sense. Feel free to submit such a change. By the way, do you know why hushlogin attribute doesn't work from the ~/.login_conf or how it can work from there? Thank you in advance. I haven't used it in a while, but I thought that one worked. After you rebuild the database, of course. I'm fairly sure it assumes your login session is actually using login(1), though. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
is rebooting after a page fault disabled in 5.3-release?
As another side note, is there a reason that 5.3 doesn't reboot after page faults? The crash and dumpdev man pages still indicate that it should. This makes this problem hard to work on (must be at facility to debug..) Or is there a new/undocumented configuration option? On Sun, Dec 12, 2004 at 09:41:59PM -0800, Joe Rhett wrote: And another, I can now confirm that it is fairly easy to kill 5.3-release during the rebuilding process. The following steps will cause a kernel page fault consistently: ... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x10 current process = 1063 (rebuilding ar0 1%) trap number = 12 panic: page fault -- Joe Rhett Senior Geek Meer.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: netstat fails with memory allocation error and error in kvm_read
We are trying to gather some debug information for a problem that is difficult to diagnose, as the machine always ends up hard frozen (does not do anything, can not break to debugger, does not respond to keyboard, etc.), so we are dumping output from netstat, vmstat, iostat etc. quite often. The cron jobs fail ever so often with error messages I do not quite understand, and I can not find anything relevant in the archives. Can anyone shed some light on this? Command:netstat -r Error message: netstat: kvm_read: Bad address Debug before: http://www.aub.dk/~jmp/fw/debug-2004.12.09-21.34.41.gz Debug after: http://www.aub.dk/~jmp/fw/debug-2004.12.09-21.35.06.gz # errors: 7 Command:netstat -an Error message:netstat: sysctl: net.inet.udp.pcblist: Cannot allocate memory Debug before: http://www.aub.dk/~jmp/fw/debug-2004.12.09-07.38.48.gz Debug after: http://www.aub.dk/~jmp/fw/debug-2004.12.09-07.39.04.gz # errors: 3 You appear to be running out of kernel memory. Since you're capturing the output of vmstat -m, you should check that for any bins that are growing at a high rate of speed. Seems possible that its in pf :) I've checked the numbers from just before the freeze (it's within 15 secs) with two sets of data: From a fresh boot and five minutes minutes before the freeze. Here are the stuff that changed significantly between the fresh boot and just before the freeze: Just before the freeze (http://www.aub.dk/~jmp/fw/tmp/debug-2004.12.11-22.59.01.gz): AR driver 2 1K268K 2922822 64,256,512,2048 kqueue 0 0K 38K 13304405 128,1024 UFS dirhash 44488K107K 2559 16,32,64,128,256,512,1024,2048,4096 freeblks13 4K 29K 103030 256 freefrag 0 0K 1K 164217 32 allocindir 28718K162K 1966413 64 indirdep 1 1K209K 9925 32 allocdirect27 4K 18K 301048 128 inodedep18 131K150K 164032 128,256 routetbl 56647K 67K 800649 16,32,64,128,256 subproc99 301K849K 1873146 32,4096 Five minutes before the freeze (http://www.aub.dk/~jmp/fw/tmp/debug-2004.12.11-22.55.42.gz): AR driver 2 1K268K 2921793 64,256,512,2048 kqueue 0 0K 38K 13296556 128,1024 UFS dirhash 44488K107K 2559 16,32,64,128,256,512,1024,2048,4096 freeblks 1 1K 29K 102978 256 freefrag 0 0K 1K 164153 32 allocindir 0 0K162K 1965284 64 indirdep 0 0K209K 9921 32 allocdirect 1 1K 18K 300886 128 inodedep14 130K150K 163954 128,256 routetbl 56246K 67K 800255 16,32,64,128,256 subproc99 301K849K 1872250 32,4096 From a fresh boot (http://www.aub.dk/~jmp/fw/tmp/debug-2004.12.11-23.31.31.gz): AR driver 2 1K190K23450 64,256,512,2048 kqueue 0 0K 3K 1062 128,1024 UFS dirhash3613K 13K 42 16,32,512,2048,4096 freeblks 11529K 29K 253 256 freefrag 0 0K 1K 51 32 allocindir 2 1K135K 3332 64 indirdep10 1K173K 630 32 allocdirect 2 1K 40K 456 128 inodedep 137 145K168K 506 128,256 routetbl 30626K 27K 495 16,32,64,128,256 subproc 107 317K466K 1554 32,4096 The numbers for pflog and pf_if does not change at all. I checked vmstat -z, and the highest pf-related entries we're actually decreasing at the time of the deadlock, but I noticed the following: VM OBJECT: 132,0, 31508, 2132, 14364021 128 Bucket: 524,0,727, 1,0 64 Bucket: 268,0, 23, 19,0 32 Bucket: 140,0, 34, 22,0 16 Bucket:76,0, 15, 35,0 Can you or anyone else deduce anything from the numbers? If not, I'll whip something together that runs vmstat -m ever so often, parses the output and remove the non-increasing entries so it'll be easier to spot the trends. Thanks, Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: is rebooting after a page fault disabled in 5.3-release?
On Sun, 12 Dec 2004, Joe Rhett wrote: As another side note, is there a reason that 5.3 doesn't reboot after page faults? The crash and dumpdev man pages still indicate that it should. This makes this problem hard to work on (must be at facility to debug..) On Mon, Dec 13, 2004 at 10:30:05AM -0800, Doug White wrote: It reboots fine on my systems. Do you have DDB compiled in without KDB_UNATTENDED? Sorry, 5.3-RELEASE with GENERIC kernel. This is a sandbox ;-) -- Joe Rhett Senior Geek Meer.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: drive failure during rebuild causes page fault
On Mon, 2004-12-13 at 10:28 -0800, Doug White wrote: On Sun, 12 Dec 2004, Joe Rhett wrote: On Sun, Dec 12, 2004 at 09:59:16PM -0800, Doug White wrote: Thats a nice shotgun you have there. Yessir. And that's what testing is designed to uncover. The question is why this works, and how do we prevent it? I'm sure Soren appreciates you donating your feet to the cause :) Why it works: the system assumes the administrator is competent enough to not yank a disk that is being rebuilt to. That's not quite fair. He was obviously testing to see how resilient ATA RAID is to drive failures during rebuilding, as part of a series of tests. (Obviously, it is not.) If you look at his original message, he did not even yank the disk. He detached it in a somewhat orderly fashion using atacontrol detach. (One can argue that physically yanking it might have been a more accurate, if more severe failure test.) This makes the ensuing panic even more sad. (Would the same panic result if the disk being rebuilt fell victim to one of those TIMEOUT - WRITE_DMA errors that are in vogue nowadays and was detached by the system? I get those errors occasionally [never used to under 5.1 on the exact same hardware] but my geom_mirror has coped with it so far, thankfully.) It's reasonable to conduct simulated failure testing of ATA RAID (or others such as geom_mirror and geom_vinum) prior to adopting it on your system. I know I did in the case of ATA RAID and abandoned it precisely because it turned out for me to be too flaky when it came to error recovery. Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: is rebooting after a page fault disabled in 5.3-release?
On Mon, Dec 13, 2004 at 11:05:33AM -0800, Joe Rhett wrote: On Sun, 12 Dec 2004, Joe Rhett wrote: As another side note, is there a reason that 5.3 doesn't reboot after page faults? The crash and dumpdev man pages still indicate that it should. This makes this problem hard to work on (must be at facility to debug..) On Mon, Dec 13, 2004 at 10:30:05AM -0800, Doug White wrote: It reboots fine on my systems. Do you have DDB compiled in without KDB_UNATTENDED? Sorry, 5.3-RELEASE with GENERIC kernel. This is a sandbox ;-) Confirmed for my two servers with RELENG_5: no dumps, no reboot after panic. This is very annoying. Both servers with custom kernels without KDB_UNATTENDED. -- Joe Rhett Senior Geek Meer.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- NO37-RIPE pgp8jSKOiIhvB.pgp Description: PGP signature
Re: drive failure during rebuild causes page fault
On Mon, Dec 13, 2004 at 04:03:06PM -0500, Paul Mather wrote: That's not quite fair. He was obviously testing to see how resilient ATA RAID is to drive failures during rebuilding, as part of a series of tests. (Obviously, it is not.) If you look at his original message, he did not even yank the disk. He detached it in a somewhat orderly fashion using atacontrol detach. Actually, I did both and both caused the same page fault :-( -- Joe Rhett Senior Geek Meer.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: QEMU
On Mon, Dec 13, 2004 at 08:03:00PM +0100, Ivan Voras wrote: Is anybody running qemu successfully on 5-stable? I'm trying to boot a knoppix live-cd from iso-image with: I tried to build it from ports on amd64 but the compiler segfaulted. :-( So it might be interesting to know what platform you're running on. From the compiler output I could see a lot of size mismatch warnings, i.e. 64 bit issues. qemu -cdrom knoppix.iso -boot d It always reboots the computer (no core-dump, no panic, just reboot - and that's as user-started process, not under root). Same thing under X11 or console. I've never used qemu before, so it could be my fault :) I've used qemu on Linux before (that's how I tried FreeBSD first), and it ran fine. However, there are at least two qemu binaries built, one that uses the hosts MMU, and one that has software MMU emulation. I'd use the last one if I were you. I never could get the one that uses the host MMU to work. Roland -- R.F. Smith /\ASCII Ribbon Campaign r s m i t h @ x s 4 a l l . n l \ /No HTML/RTF in email http://www.xs4all.nl/~rsmith/ X No Word docs in email / \Respect for open standards pgpR5j2DCTZOJ.pgp Description: PGP signature
Fixing Posix semaphores
I have a desire to fix posix semaphores in at least 5.3. The current implementation doesn't actually follow the spirit of the standard, even though it technically qualifies in a somewhat degraded sense. I refer to the fact that the current implementation treats posix semaphores as completely contained inside the kernel and essentially divorced from the filesystem. The true spirit of the standard places the semaphores directly in the file system, similar to named pipes. However the current implementation treats the supplied name as a 14-character identifier, required to begin with a slash and contain no other slashes. Pretty weak. Well, in order to fix this, we need to add file system code and come up with a new type. I currently have some time to spend on something like this and am willing to put in whatever effort it takes. Does anyone want to add their own ideas or requirements? I currently run 5.3, but I suppose I could think about running current at some point in the future. /Joe ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: QEMU
Roland Smith wrote: On Mon, Dec 13, 2004 at 08:03:00PM +0100, Ivan Voras wrote: Is anybody running qemu successfully on 5-stable? I'm trying to boot a knoppix live-cd from iso-image with: I tried to build it from ports on amd64 but the compiler segfaulted. :-( So it might be interesting to know what platform you're running on. From the compiler output I could see a lot of size mismatch warnings, i.e. 64 bit issues. Works fine for me on i386. qemu -cdrom knoppix.iso -boot d It always reboots the computer (no core-dump, no panic, just reboot - and that's as user-started process, not under root). Same thing under X11 or console. I've never used qemu before, so it could be my fault :) I've used qemu on Linux before (that's how I tried FreeBSD first), and it ran fine. However, there are at least two qemu binaries built, one that uses the hosts MMU, and one that has software MMU emulation. I'd use the last one if I were you. I never could get the one that uses the host MMU to work. The host MMU version (aka qemu-fast) is Linux-only as far as I know. The FreeBSD port doesn't build it at the very least. Jon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: is rebooting after a page fault disabled in 5.3-release?
On Mon, 13 Dec 2004, Joe Rhett wrote: On Sun, 12 Dec 2004, Joe Rhett wrote: As another side note, is there a reason that 5.3 doesn't reboot after page faults? The crash and dumpdev man pages still indicate that it should. This makes this problem hard to work on (must be at facility to debug..) On Mon, Dec 13, 2004 at 10:30:05AM -0800, Doug White wrote: It reboots fine on my systems. Do you have DDB compiled in without KDB_UNATTENDED? Sorry, 5.3-RELEASE with GENERIC kernel. This is a sandbox ;-) I in fact tested this on Saturday and it in fact rebooted. With GENERIC, even. The digi driver sort of got left behind with the tty changes and handed out uninitialized mutexes that trip null pointer panics. Machine came back up fine, so unless you have some type of panic that screws up the system enough to disrupt booting then it should work. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: drive failure during rebuild causes page fault
On Mon, 13 Dec 2004, Joe Rhett wrote: This is why I don't trust ATA RAID for fault tolerance -- it'll save your data, but the system will tank. Since the disk state is maintained by the OS and not abstracted by a separate processor, if a disk dies in a particularly bad way the system may not be able to cope. Yes, but SATA isn't limited by this problem. It does have a processor per disk. (this is all SATA, if I didn't make that clear) Actually on SATA its worse -- the disk just stops responding to everything and hangs. If you don't detect this condition then you go into an infinite wait. In any case, yes the ATA RAID code could use a massive robustness pass. So could the core ATA code. Patches accepted :) -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
polling probrem?
I have rebuid the FreeBSD 5.3-RELEASE kernel with options below: options DEVICE_POLLING options HZ=1000 on ThinkPad iSeries 1800. And setting 'sysctl kern.polling.enable=1', then running dnetc installed from ports(dnetc-2.9008.491_1,1), I detected considerable amount of packet loss. Top command shows that dnetc is using 1000% (not 100%, but 1000%!). ping result (snip) 64 bytes from 192.168.2.200: icmp_seq=258 ttl=64 time=9597.83 ms 64 bytes from 192.168.2.200: icmp_seq=268 ttl=64 time=9624.56 ms 64 bytes from 192.168.2.200: icmp_seq=278 ttl=64 time=9612.66 ms 64 bytes from 192.168.2.200: icmp_seq=288 ttl=64 time=9639.19 ms 64 bytes from 192.168.2.200: icmp_seq=298 ttl=64 time=19652 ms 64 bytes from 192.168.2.200: icmp_seq=318 ttl=64 time=9579.19 ms 64 bytes from 192.168.2.200: icmp_seq=328 ttl=64 time=9606.89 ms 64 bytes from 192.168.2.200: icmp_seq=329 ttl=64 time=8606.83 ms 64 bytes from 192.168.2.200: icmp_seq=338 ttl=64 time=19564.4 ms 64 bytes from 192.168.2.200: icmp_seq=340 ttl=64 time=17564.2 ms 64 bytes from 192.168.2.200: icmp_seq=358 ttl=64 time=9547.07 ms 64 bytes from 192.168.2.200: icmp_seq=361 ttl=64 time=6546.53 ms ^C --- 192.168.2.200 ping statistics --- 372 packets transmitted, 201 packets received, 45% packet loss round-trip min/avg/max = 0.367/1158.48/19652 ms top result PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 434 dnetc 139 20 964K 764K RUN 11:09 1259.46% 1259.42% dnetc Is this the problem with polling? Please let me know. Thank you. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
not putty but mostly a dns and windows virus problem
yep, I did also have an old version of putty, but I think the main problem was the dns conf and network problems, there is one windows box acting as a server on the same network that got a few viruses and started taking up all the bandwidth I found this yesterday and have tightened up security by installing zone alarm on it. I hope that will help, I guess I will see in a few days. - Original Message - From: whitevamp [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, December 13, 2004 2:01 AM Subject: Re: putty times out on 5.3 box i have a couple users on my box and they was haveing the same issues and what it wound up being is that they was useing an older ver of putty.. i had them d/l the new ver and all was fine .. no more time outs ner ver of putty is 0.56 hope this helps you , it helped out my users after upgrade to 5.3 - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, December 12, 2004 12:52 PM Subject: putty times out on 5.3 box I can't seem to get remote access anymore but at the site everything seems to work?? I run a webserver and all the sites run fine but all of a sudden no more access through putty, or ftp. The only thing that is diff is I enabled ipfw but only open. It was always slow to get in using putty but now it just times out. the box is a dual amd w/512 mb ram and otherwise seems fine. I'm just stumped. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.296 / Virus Database: 265.5.1 - Release Date: 12/13/2004 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.296 / Virus Database: 265.5.1 - Release Date: 12/13/2004 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: is rebooting after a page fault disabled in 5.3-release?
On Mon, 2004-Dec-13 18:37:29 -0800, Doug White wrote: I in fact tested this on Saturday and it in fact rebooted. With GENERIC, even. The digi driver sort of got left behind with the tty changes and handed out uninitialized mutexes that trip null pointer panics. Machine came back up fine, so unless you have some type of panic that screws up the system enough to disrupt booting then it should work. I missed the previous reference to digi(4). Check out http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/72436 which includes a patch to fix this. -- Peter Jeremy ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: drive failure during rebuild causes page fault
Doug White wrote: On Mon, 13 Dec 2004, Joe Rhett wrote: This is why I don't trust ATA RAID for fault tolerance -- it'll save your data, but the system will tank. Since the disk state is maintained by the OS and not abstracted by a separate processor, if a disk dies in a particularly bad way the system may not be able to cope. Yes, but SATA isn't limited by this problem. It does have a processor per disk. (this is all SATA, if I didn't make that clear) Actually on SATA its worse -- the disk just stops responding to everything and hangs. If you don't detect this condition then you go into an infinite wait. In any case, yes the ATA RAID code could use a massive robustness pass. So could the core ATA code. Patches accepted :) Actually I'm in the process of rewriting the ATA RAID code, so things are rolling, albeit slowly, time is a precious resource. I belive that it can be made pretty robust, but the rest of the kernel still have issues with disappearing devices etc thats out of ATA's realm. Anyhow. I can only test with the HW I have here in the lab, which by far covers all possible permutations, so testing etc by the community is very much needed here to get things sorted out... -- -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
