Re: today's build is causing errors for me
Hi Jeremy, I used Mergemaster. Thats what I mean't when I said that I carefully merged /usr/src/etc/ with /etc. But like I said, no files were replaced that contained my own configuration, e.g. group. I will say this- that I have always considered Mergemaster a confusing mess, despite the dogma on the lists. I have been running FreeBSD and installing it since 1998, so I have some experience- but this is new behavior beyond my previous experiences. Sincerely, Rob. On 5/15/08, Jeremy Chadwick [EMAIL PROTECTED] wrote: On Thu, May 15, 2008 at 04:44:57PM -0700, Rob Lytle wrote: First I am running 7.0-Stable and just cvsup'd today. Then I built the system, new kernel, and installed them. Second I am using the GENERIC KERNEL. Sysctl.conf is empty. I will put my /etc/rc.conf at the end. I tried to do a very careful job of merging /usr/src/etc with /etc. I didn't touch any files that I or the computer configured. But I am getting these errors upon bootup: 1. eval: /etc/rc.d/cleanvar: Permission Denied 2. syslogd: bind: Can't assign requested address. (repeated twice) 3. syslogd: child pid 134 exited with return code 1 4. /etc/rc: Warning: Dump device does not exist. Savecore will not run. (this always worked before) 5. /etc/rc.d/securelevel: /etc/rc.d/sysctl: Permission denied. 6. My computer says Amnesiac yet the host name is clearly in rc.conf 7. My WiFi no longer starts up by myself. I have to do it all manually using ifconfig and dhclient. You should have followed the instructions in /usr/src/Makefile. You don't merge things by hand. You can use mergemaster for that. Please use it, as I'm willing to bet there's a portion of your rc framework which is broken in some way. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: today's build is causing errors for me
On Thu, May 15, 2008 at 11:04:34PM -0700, Rob Lytle wrote: Hi Jeremy, I used Mergemaster. Thats what I mean't when I said that I carefully merged /usr/src/etc/ with /etc. But like I said, no files were replaced that contained my own configuration, e.g. group. I will say this- that I have always considered Mergemaster a confusing mess, despite the dogma on the lists. I have been running FreeBSD and installing it since 1998, so I have some experience- but this is new behavior beyond my previous experiences. Permission denied could imply that the rc scripts aren't set to executable. Possibly a umask problem? Additionally, mergemaster isn't a confusing mess. If anything, it's one of the most simple tools there is for managing /etc. The part you probably find confusing, which is the same part I did when I started using it, is the side-by-side interactive diff. It's very easy to use; r means use the text shown on the right, and l means use the text shown on the left. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: today's build is causing errors for me / Fixed for now
Hi Jeremy, I always back up /etc before I upgrade the system. The old /etc works just fine. I will eventually go back in and check out the new /etc to see what is wrong. Sincerely, Rob. On Thu, May 15, 2008 at 11:17 PM, Jeremy Chadwick [EMAIL PROTECTED] wrote: On Thu, May 15, 2008 at 11:04:34PM -0700, Rob Lytle wrote: Hi Jeremy, I used Mergemaster. Thats what I mean't when I said that I carefully merged /usr/src/etc/ with /etc. But like I said, no files were replaced that contained my own configuration, e.g. group. I will say this- that I have always considered Mergemaster a confusing mess, despite the dogma on the lists. I have been running FreeBSD and installing it since 1998, so I have some experience- but this is new behavior beyond my previous experiences. Permission denied could imply that the rc scripts aren't set to executable. Possibly a umask problem? Additionally, mergemaster isn't a confusing mess. If anything, it's one of the most simple tools there is for managing /etc. The part you probably find confusing, which is the same part I did when I started using it, is the side-by-side interactive diff. It's very easy to use; r means use the text shown on the right, and l means use the text shown on the left. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: today's build is causing errors for me
Hi Jeremy, You were correct. Somehow some files in /etc/rc.d had permissions of 644. Setting the new permissions to that of the old fixed the problem. Thanks. Rob. On Thu, May 15, 2008 at 11:17 PM, Jeremy Chadwick [EMAIL PROTECTED] wrote: On Thu, May 15, 2008 at 11:04:34PM -0700, Rob Lytle wrote: Hi Jeremy, I used Mergemaster. Thats what I mean't when I said that I carefully merged /usr/src/etc/ with /etc. But like I said, no files were replaced that contained my own configuration, e.g. group. I will say this- that I have always considered Mergemaster a confusing mess, despite the dogma on the lists. I have been running FreeBSD and installing it since 1998, so I have some experience- but this is new behavior beyond my previous experiences. Permission denied could imply that the rc scripts aren't set to executable. Possibly a umask problem? Additionally, mergemaster isn't a confusing mess. If anything, it's one of the most simple tools there is for managing /etc. The part you probably find confusing, which is the same part I did when I started using it, is the side-by-side interactive diff. It's very easy to use; r means use the text shown on the right, and l means use the text shown on the left. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
just one last question about /etc/rc.d file permissions
Hi Jeremy, I noticed that most all of the files in my old /etc/rc.d had 555 permissions. There were 4 or 5 that had 644 permissions in my old /etc/rc.d. What I am wondering is if all the files in rc.d should be 555? So far I am not experiencing any problems with anything with a very few 644 files. Thanks, Rob. On 5/16/08, Rob Lytle [EMAIL PROTECTED] wrote: Hi Jeremy, You were correct. Somehow some files in /etc/rc.d had permissions of 644. Setting the new permissions to that of the old fixed the problem. Thanks. Rob. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ciss(4) not coping with large arrays?
Hi all, Running today's RELENG_7 (although 7.0-RELEASE has the same problem), GENERIC kernel on an amd64 and I can't seem to get a da(4) device for any arrays bigger than 2TB. dmesg: ... ciss0: HP Smart Array P400 port 0x4000-0x40ff mem 0xfdf0-0xfdff,0xfdef -0xfdef0fff irq 16 at device 0.0 on pci10 ciss0: [ITHREAD] ... da0 at ciss0 bus 0 target 0 lun 0 da0: COMPAQ RAID 1 VOLUME OK Fixed Direct Access SCSI-5 device da0: 135.168MB/s transfers da0: 953837MB (1953459632 512 byte sectors: 255H 32S/T 65535C) da1 at ciss0 bus 0 target 1 lun 0 da1: COMPAQ RAID 0 VOLUME OK Fixed Direct Access SCSI-5 device da1: 135.168MB/s transfers da1: 953837MB (1953459632 512 byte sectors: 255H 32S/T 65535C) da2 at ciss0 bus 0 target 2 lun 0 da2: COMPAQ RAID 0 VOLUME OK Fixed Direct Access SCSI-5 device da2: 135.168MB/s transfers da2: 1907675MB (3906918832 512 byte sectors: 255H 32S/T 65535C) (da3:ciss0:0:3:0): got CAM status 0x4 (da3:ciss0:0:3:0): fatal error, failed to attach to device (da3:ciss0:0:3:0): lost device (da3:ciss0:0:3:0): removing device entry (da4:ciss0:0:4:0): got CAM status 0x4 (da4:ciss0:0:4:0): fatal error, failed to attach to device (da4:ciss0:0:4:0): lost device (da4:ciss0:0:4:0): removing device entry ... The arrays I'm testing with: da1 = 1 x 1TB da2 = 2 x 1TB da3 = 3 x 1TB da4 = 4 x 1TB Also: # camcontrol devlist COMPAQ RAID 1 VOLUME OK at scbus0 target 0 lun 0 (pass0,da0) COMPAQ RAID 0 VOLUME OK at scbus0 target 1 lun 0 (pass1,da1) COMPAQ RAID 0 VOLUME OK at scbus0 target 2 lun 0 (pass2,da2) COMPAQ RAID 0 VOLUME OK at scbus0 target 3 lun 0 (pass3) COMPAQ RAID 0 VOLUME OK at scbus0 target 4 lun 0 (pass4) # camcontrol readcap pass2 Last Block: 3906918831, Block Length: 512 bytes # camcontrol readcap pass3 (pass3:ciss0:0:3:0): SERVICE ACTION IN(16). CDB: 9e 10 0 0 0 0 0 0 0 0 0 0 0 c 0 0 (pass3:ciss0:0:3:0): CAM Status: CCB request completed with an error Is it possible to get FreeBSD to recognize arrays 2TB? Are there any further diagnostics I can provide? --Emil ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ciss(4) not coping with large arrays?
Running today's RELENG_7 (although 7.0-RELEASE has the same problem), GENERIC kernel on an amd64 and I can't seem to get a da(4) device for any arrays bigger than 2TB. In earlier releases (5 and 6 at least) you couldn't create partitions larger than 2 TB. I don't know whether work has been to circumvent this in 7 but tools like fsck has to be changed as well. Have you tried zfs? dmesg: ... ciss0: HP Smart Array P400 port 0x4000-0x40ff mem 0xfdf0-0xfdff,0xfdef -0xfdef0fff irq 16 at device 0.0 on pci10 ciss0: [ITHREAD] ... da0 at ciss0 bus 0 target 0 lun 0 da0: COMPAQ RAID 1 VOLUME OK Fixed Direct Access SCSI-5 device da0: 135.168MB/s transfers da0: 953837MB (1953459632 512 byte sectors: 255H 32S/T 65535C) da1 at ciss0 bus 0 target 1 lun 0 da1: COMPAQ RAID 0 VOLUME OK Fixed Direct Access SCSI-5 device da1: 135.168MB/s transfers da1: 953837MB (1953459632 512 byte sectors: 255H 32S/T 65535C) da2 at ciss0 bus 0 target 2 lun 0 da2: COMPAQ RAID 0 VOLUME OK Fixed Direct Access SCSI-5 device da2: 135.168MB/s transfers da2: 1907675MB (3906918832 512 byte sectors: 255H 32S/T 65535C) (da3:ciss0:0:3:0): got CAM status 0x4 (da3:ciss0:0:3:0): fatal error, failed to attach to device (da3:ciss0:0:3:0): lost device (da3:ciss0:0:3:0): removing device entry (da4:ciss0:0:4:0): got CAM status 0x4 (da4:ciss0:0:4:0): fatal error, failed to attach to device (da4:ciss0:0:4:0): lost device (da4:ciss0:0:4:0): removing device entry ... The arrays I'm testing with: da1 = 1 x 1TB da2 = 2 x 1TB da3 = 3 x 1TB da4 = 4 x 1TB Also: # camcontrol devlist COMPAQ RAID 1 VOLUME OK at scbus0 target 0 lun 0 (pass0,da0) COMPAQ RAID 0 VOLUME OK at scbus0 target 1 lun 0 (pass1,da1) COMPAQ RAID 0 VOLUME OK at scbus0 target 2 lun 0 (pass2,da2) COMPAQ RAID 0 VOLUME OK at scbus0 target 3 lun 0 (pass3) COMPAQ RAID 0 VOLUME OK at scbus0 target 4 lun 0 (pass4) # camcontrol readcap pass2 Last Block: 3906918831, Block Length: 512 bytes # camcontrol readcap pass3 (pass3:ciss0:0:3:0): SERVICE ACTION IN(16). CDB: 9e 10 0 0 0 0 0 0 0 0 0 0 0 c 0 0 (pass3:ciss0:0:3:0): CAM Status: CCB request completed with an error Is it possible to get FreeBSD to recognize arrays 2TB? Are there any further diagnostics I can provide? --Emil ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ciss(4) not coping with large arrays?
On Fri, May 16, 2008 at 1:03 AM, Paul Saab [EMAIL PROTECTED] wrote: On Fri, May 16, 2008 at 12:50 AM, Claus Guttesen [EMAIL PROTECTED] wrote: Running today's RELENG_7 (although 7.0-RELEASE has the same problem), GENERIC kernel on an amd64 and I can't seem to get a da(4) device for any arrays bigger than 2TB. In earlier releases (5 and 6 at least) you couldn't create partitions larger than 2 TB. I don't know whether work has been to circumvent this in 7 but tools like fsck has to be changed as well. Have you tried zfs? zfs has nothing to do with this. The driver is not properly dealing with the large volume. set the kernel tunable in loader.conf kern.cam.da.3.minimum_cmd_size=16 kern.cam.da.4.minimum_cmd_size=16 Actually, this has nothing to do with it either.. Please try the following patch: http://yogurt.org/FreeBSD/ciss_large.diff ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ciss(4) not coping with large arrays?
On Fri, May 16, 2008 at 12:50 AM, Claus Guttesen [EMAIL PROTECTED] wrote: Running today's RELENG_7 (although 7.0-RELEASE has the same problem), GENERIC kernel on an amd64 and I can't seem to get a da(4) device for any arrays bigger than 2TB. In earlier releases (5 and 6 at least) you couldn't create partitions larger than 2 TB. I don't know whether work has been to circumvent this in 7 but tools like fsck has to be changed as well. Have you tried zfs? zfs has nothing to do with this. The driver is not properly dealing with the large volume. set the kernel tunable in loader.conf kern.cam.da.3.minimum_cmd_size=16 kern.cam.da.4.minimum_cmd_size=16 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Timedia 8 port serial pci card problem
Hello I run FreeBSD 7-Stable on my soekris net 5501 with a 8 Port Timedia Serial PCI Card. It's also know as SUNIX 4066 card. My Kernel Config is like Generic exept this two added options: options CPU_SOEKRIS device puc FreeBSD detects it with: puc0: Timedia technology 8 Port Serial port 0xe500-0xe51f,0xe520-0xe52f,0xe530-0xe537,0xe538-0xe53f, 0xe540-0xe547,0xe548-0xe54f irq 10 at device 14.0 on pci0 . But it only adds 3 uart ports instead of 8. Any idea what i can do? Maybe useful informations: FreeBSD a2.test.lan 7.0-STABLE FreeBSD 7.0-STABLE #4: Thu May 15 16:27:54 CEST 2008 pciconf: [EMAIL PROTECTED]:0:14:0: class=0x070002 card=0x50661409 chip=0x71681409 rev=0x01 hdr=0x00 vendor = 'Timedia Technology Co Ltd' device = '40371409 PCI / ISA Asynchronous UART Signal Chips Solution' class = simple comms subclass = UART puc/uart: puc0: Timedia technology 8 Port Serial port 0xe500-0xe51f, 0xe520-0xe52f,0xe530-0xe537,0xe538-0xe53f,0xe540-0xe547,0xe548-0xe54f irq 10 at device 14.0 on pci0 puc0: Reserved 0x20 bytes for rid 0x10 type 4 at 0xe500 puc0: Lazy allocation of 0x4 bytes rid 0x11 type 4 at 0x1000 puc0: Lazy allocation of 0x4 bytes rid 0x12 type 4 at 0x1004 puc0: Lazy allocation of 0x4 bytes rid 0x13 type 4 at 0x1008 puc0: Reserved 0x10 bytes for rid 0x14 type 4 at 0xe520 puc0: Lazy allocation of 0x4 bytes rid 0x15 type 4 at 0x100c puc0: [FILTER] uart0: Non-standard ns8250 class UART with FIFOs on puc0 uart0: [FILTER] uart0: fast interrupt uart1: 16550 or compatible on puc0 uart1: [FILTER] uart1: fast interrupt uart2: Non-standard ns8250 class UART with FIFOs on puc0 uart2: [FILTER] uart2: fast interrupt Complete dmesg: Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-STABLE #4: Thu May 15 16:27:54 CEST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ULL Preloaded elf kernel /boot/kernel/kernel at 0xc0905000. Calibrating clock(s) ... i8254 clock: 1193155 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 499904707 Hz CPU: Geode(TM) Integrated Processor by AMD PCS (499.90-MHz 586-class CPU) Origin = AuthenticAMD Id = 0x5a2 Stepping = 2 Features=0x88a93dFPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CLFLUSH,MMX AMD Features=0xc040MMX+,3DNow!+,3DNow! Data TLB: 16 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 32 bytes/line, 1 lines/tag, 16-way associative L1 instruction cache: 64 kbytes, 32 bytes/line, 1 lines/tag, 16-way associative L2 internal cache: 128 kbytes, 32 bytes/line, 1 lines/tag, 4-way associative Write Allocate Disable real memory = 536870912 (512 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x00c25000 - 0x1f6bbfff, 514420736 bytes (125591 pages) avail memory = 515969024 (492 MB) bios32: Found BIOS32 Service Directory header at 0xc00fac00 bios32: Entry = 0xfac40 (c00fac40) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xac61 Other BIOS signatures found: ULE: setup cpu 0 kbd: new array size 4 kbd1 at kbdmux0 nfslock: pseudo-device random: entropy source, Software, Yarrow mem: memory K6-family MTRR support enabled (2 registers) io: I/O null: null device, zero device npx0: INT 16 interface cpu0 on motherboard pci_open(1):mode 1 addr port (0x0cf8) is 0x pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 1 [class=06] [hdr=80] is there (id=20801022) pcibios: BIOS version 2.01 pcib0: Host to PCI bridge pcibus 0 on motherboard pci0: PCI bus on pcib0 pci0: domain=0, physical bus=0 found- vendor=0x1022, dev=0x2080, revid=0x31 domain=0, bus=0, slot=1, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0220, cachelnsz=8 (dwords) lattimer=0xf8 (7440 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found- vendor=0x1022, dev=0x2082, revid=0x00 domain=0, bus=0, slot=1, func=2 class=10-10-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0220, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[10]: type Memory, range 32, base 0xa000, size 14, enabled found- vendor=0x1106, dev=0x3053, revid=0x96 domain=0, bus=0, slot=6, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x03 (750 ns), maxlat=0x08 (2000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O
Re: Timedia 8 port serial pci card problem
On May 16, 2008, at 1:17 AM, Thomas Vogt wrote: FreeBSD detects it with: puc0: Timedia technology 8 Port Serial port 0xe500-0xe51f,0xe520-0xe52f,0xe530-0xe537,0xe538-0xe53f, 0xe540-0xe547,0xe548-0xe54f irq 10 at device 14.0 on pci0 . But it only adds 3 uart ports instead of 8. Any idea what i can do? Can you try the following (white-space corrupted) patch: Index: pucdata.c === RCS file: /home/ncvs/src/sys/dev/puc/pucdata.c,v retrieving revision 1.59.2.1 diff -u -r1.59.2.1 pucdata.c --- pucdata.c 26 Feb 2008 09:33:57 - 1.59.2.1 +++ pucdata.c 16 May 2008 10:48:25 - @@ -1116,7 +1116,7 @@ *res = (port == 1 || port == 3) ? 8 : 0; return (0); case PUC_CFG_GET_RID: - *res = 0x10 + ((port 3) ? port - 2 : port 1); + *res = 0x10 + ((port 3) ? port - 2 : port 1) * 4; return (0); case PUC_CFG_GET_TYPE: *res = PUC_TYPE_SERIAL; -- Marcel Moolenaar [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: g_vfs_done error third part--PLEASE HELP!
On Fri, May 16, 2008 at 02:14:14PM +0200, Willy Offermans wrote: On Mon, Apr 21, 2008 at 10:10:47PM +0200, Roland Smith wrote: Did you notice any file corruption in the filesystem on ar0s1g? No the two disks are brand new and I did not encounter any noticeable file corruption. However I assume that nowadays bad sectors on HD are handled by the hardware and do not need any user interaction to correct this. But maybe I'm totally wrong. You're right, but it depends on the type of disk. SCSI disks will report bad blocks to the OS regardless if it is about to mark the block as a grown defect or not. PATA and SATA disks, on the other hand, will report bad blocks to the OS only if the internal bad block list (which it manages itself -- this is what you're thinking of) is full. There are still many conditions where PATA and SATA disks can induce errors in the OS. If the disk is attempting to work around a bad block, and there's a physical error (servo problem, head crash, repetitive re-reads of the block due to dust, whatever -- something that ties up the disk for long periods of time), ATA subsystem timeouts may be seen, DMA errors, or whatever else. SMART stats will show this kind of problem. Unmount the filesystem and run fsck(8) on it. Does it report any errors? sun# fsck /dev/ar0s1g ** /dev/ar0s1g ** Last Mounted on /share ** Phase 1 - Check Blocks and Sizes INCORRECT BLOCK COUNT I=34788357 (272 should be 264) CORRECT? [yn] y INCORRECT BLOCK COUNT I=34789217 (296 should be 288) CORRECT? [yn] y ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? [yn] y SUMMARY INFORMATION BAD SALVAGE? [yn] y BLK(S) MISSING IN BIT MAPS SALVAGE? [yn] y 182863 files, 17282440 used, 120206472 free (12448 frags, 15024253 blocks, 0.0% fragmentation) * FILE SYSTEM MARKED CLEAN * * FILE SYSTEM WAS MODIFIED * The usual stuff I would say. How is this usual?. It appears to me you did have some filesystem corruption. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Status of ZFS in -stable?
Hi, I would like to know memory allocation problem eith zfs has been fixed in -stable since the release of 7.0? Is zfs more stable ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: g_vfs_done error third part--PLEASE HELP!
Willy Offermans wrote: Hello Roland and FreeBSD friends, I'm sorry to be so quite for a while, but I went away for a vacation. But now I'm back, I like to solve this issue. On Mon, Apr 21, 2008 at 10:10:47PM +0200, Roland Smith wrote: On Mon, Apr 21, 2008 at 09:04:03PM +0200, Willy Offermans wrote: Dear FreeBSD friends, It is already the third time that I report this error. Can someone help me in solving this issue? Probably the reason that you hear so little is that you provide so little information. Most of us are not clairvoyant. Over and over again and always after heavy disk I/O I see the following errors in the log files. If I force ar0s1g to unmount the machine spontaneously reboots. Nothing seriously seems to be damaged by this act, but anyway I cannot afford something bad happening to this production machine. Why would you force an unmount? Otherwise the device keeps on reporting to be unavailable and cannot be unmounted: sun# umount /share/ umount: unmount of /share failed: Resource temporarily unavailable Apr 18 20:02:19 sun kernel: g_vfs_done():ar0s1g[WRITE(offset=290725068800, length=4096)]error = 5 I have no clue what the errors mean, since offsets of 290725068800, 290725072896, and 290725074944 seem to be ridiculous. Does anybody have a clue what is going on? For starters, how big is ar0s1g? If the offset is in bytes, it is around 270 GB, which is not that unusual in this day and age. I have to admit that I was a bit confused by an offset value of 290725068800. There is no indication of a unit, so I assumed that it was sector but probably it is simply bytes and then indeed the number does make sense. I'm using FreeBSD 7.0, but found the error being reported before with previous versions of FreeBSD. I can and will provide more details on demand. What does 'df' say? Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ar0s1a 20308398 230438 18453290 1%/ devfs 11 0 100%/dev /dev/ar0s1d 21321454 3814482 1580125619%/usr /dev/ar0s1e 50777034 5331686 4138318611%/var /dev/ar0s1f 101554150 18813760 7461605820%/home /dev/ar0s1g 274977824 34564876 21841472414%/share pretty normal I would say. Did you notice any file corruption in the filesystem on ar0s1g? No the two disks are brand new and I did not encounter any noticeable file corruption. However I assume that nowadays bad sectors on HD are handled by the hardware and do not need any user interaction to correct this. But maybe I'm totally wrong. Unmount the filesystem and run fsck(8) on it. Does it report any errors? sun# fsck /dev/ar0s1g ** /dev/ar0s1g ** Last Mounted on /share ** Phase 1 - Check Blocks and Sizes INCORRECT BLOCK COUNT I=34788357 (272 should be 264) CORRECT? [yn] y INCORRECT BLOCK COUNT I=34789217 (296 should be 288) CORRECT? [yn] y ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? [yn] y SUMMARY INFORMATION BAD SALVAGE? [yn] y BLK(S) MISSING IN BIT MAPS SALVAGE? [yn] y 182863 files, 17282440 used, 120206472 free (12448 frags, 15024253 blocks, 0.0% fragmentation) * FILE SYSTEM MARKED CLEAN * * FILE SYSTEM WAS MODIFIED * The usual stuff I would say. No, any form of filesystem corruption is not usual. Any hints are very much appreciated. Did you manage to create a partition larger than the disk is (using newfs's -s switch)? In that case it could be that you're trying to write past the end of the device. No, look to the following output: sun# bsdlabel -A /dev/ar0s1 # /dev/ar0s1: type: unknown disk: amnesiac label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 60799 sectors/unit: 976751937 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 4194304004.2BSD0 0 0 b: 8388608 41943040 swap c: 9767519370unused0 0 # raw part, don't edit d: 44040192 503316484.2BSD 2048 16384 28552 e: 104857600 943718404.2BSD 2048 16384 28552 f: 209715200 1992294404.2BSD 2048 16384 28552 g: 567807297 4089446404.2BSD 2048 16384 28552 /dev/ar0s1g starts after 408944640*512/1024/1024=199680MB So I have to conclude that the write error message does make sense and that something seems to be wrong with the disks. The next question is what can I do about it? Should I return the disks to the shop and ask for new ones? #define EIO 5 /* Input/output error */ At least one of your disks is toast. Kris ___ freebsd-stable@freebsd.org mailing list
Re: Timedia 8 port serial pci card problem
Hi Marcel Am 16.05.2008 um 12:53 schrieb Marcel Moolenaar: On May 16, 2008, at 1:17 AM, Thomas Vogt wrote: FreeBSD detects it with: puc0: Timedia technology 8 Port Serial port 0xe500-0xe51f,0xe520-0xe52f,0xe530-0xe537,0xe538-0xe53f, 0xe540-0xe547,0xe548-0xe54f irq 10 at device 14.0 on pci0 . But it only adds 3 uart ports instead of 8. Any idea what i can do? Can you try the following (white-space corrupted) patch: Index: pucdata.c === RCS file: /home/ncvs/src/sys/dev/puc/pucdata.c,v retrieving revision 1.59.2.1 diff -u -r1.59.2.1 pucdata.c --- pucdata.c 26 Feb 2008 09:33:57 - 1.59.2.1 +++ pucdata.c 16 May 2008 10:48:25 - @@ -1116,7 +1116,7 @@ *res = (port == 1 || port == 3) ? 8 : 0; return (0); case PUC_CFG_GET_RID: - *res = 0x10 + ((port 3) ? port - 2 : port 1); + *res = 0x10 + ((port 3) ? port - 2 : port 1) * 4; return (0); case PUC_CFG_GET_TYPE: *res = PUC_TYPE_SERIAL; Thats it. It works with your patch dmesg: puc0: Timedia technology 8 Port Serial port 0xe500-0xe51f, 0xe520-0xe52f,0xe530-0xe537,0xe538-0xe53f,0xe540-0xe547,0xe548-0xe54f irq 10 at device 14.0 on pci0 puc0: Reserved 0x20 bytes for rid 0x10 type 4 at 0xe500 puc0: Reserved 0x10 bytes for rid 0x14 type 4 at 0xe520 puc0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xe530 puc0: Reserved 0x8 bytes for rid 0x1c type 4 at 0xe538 puc0: Reserved 0x8 bytes for rid 0x20 type 4 at 0xe540 puc0: Reserved 0x8 bytes for rid 0x24 type 4 at 0xe548 puc0: [FILTER] uart0: Non-standard ns8250 class UART with FIFOs on puc0 uart0: [FILTER] uart0: fast interrupt uart1: Non-standard ns8250 class UART with FIFOs on puc0 uart1: [FILTER] uart1: fast interrupt uart2: Non-standard ns8250 class UART with FIFOs on puc0 uart2: [FILTER] uart2: fast interrupt uart3: Non-standard ns8250 class UART with FIFOs on puc0 uart3: [FILTER] uart3: fast interrupt uart4: Non-standard ns8250 class UART with FIFOs on puc0 uart4: [FILTER] uart4: fast interrupt uart5: Non-standard ns8250 class UART with FIFOs on puc0 uart5: [FILTER] uart5: fast interrupt uart6: Non-standard ns8250 class UART with FIFOs on puc0 uart6: [FILTER] uart6: fast interrupt uart7: Non-standard ns8250 class UART with FIFOs on puc0 uart7: [FILTER] uart7: fast interrupt Thank you, Thomas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD Status Reports for the First Quarter of 2008
Hi Everyone, The FreeBSD Status Reports for the First Quarter of 2008 are now available at: http://www.freebsd.org/news/status/report-2008-01-2008-03.html Regards, Brad Davis ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
cfservd crashing on 7.0
Hi, I just moved my cfservd (a part of sysutils/cfengine) from a 6.2 server to a 7.0 server. Ever since, cfservd crashes regularly. The backtrace is below, although obviously it is missing a lot. If anyone has clues or suggestions, I'd really appreciate it. # gdb /usr/local/sbin/cfservd cfservd.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd...(no debugging symbols found)... Core was generated by `cfservd'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libdb-4.6.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libdb-4.6.so.0 Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libcrypto.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypto.so.5 Reading symbols from /usr/lib/librt.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/librt.so.1 Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x283214e0 in sha1_block_data_order () from /lib/libcrypto.so.5 [New Thread 0x28501600 (LWP 100725)] [New Thread 0x28501500 (LWP 100723)] [New Thread 0x28501c00 (LWP 100289)] [New Thread 0x28501a00 (LWP 100722)] [New Thread 0x28501900 (LWP 100505)] [New Thread 0x28501400 (LWP 100726)] [New Thread 0x28501100 (LWP 100614)] (gdb) bt #0 0x283214e0 in sha1_block_data_order () from /lib/libcrypto.so.5 #1 0x28323112 in SHA1_Update () from /lib/libcrypto.so.5 #2 0x283114fe in EVP_sha512 () from /lib/libcrypto.so.5 #3 0x2952e080 in ?? () #4 0x28391cf4 in ?? () from /lib/libcrypto.so.5 #5 0xff6b in ?? () #6 0x28311b65 in EVP_DigestInit_ex () from /lib/libcrypto.so.5 #7 0x2831161f in EVP_DigestUpdate () from /lib/libcrypto.so.5 #8 0x282f38ef in RAND_SSLeay () from /lib/libcrypto.so.5 #9 0xbf8f5d20 in ?? () #10 0x28391cf4 in ?? () from /lib/libcrypto.so.5 #11 0xff6b in ?? () #12 0x01c2 in ?? () #13 0x0100 in ?? () #14 0xbf8f5d38 in ?? () #15 0x2836aad0 in RSA_version () from /lib/libcrypto.so.5 #16 0xbf8f5d0c in ?? () #17 0xbf8f5d30 in ?? () #18 0x000a in ?? () #19 0x03ff in ?? () #20 0x0001 in ?? () #21 0xfc0b in ?? () #22 0x9479e4c0 in ?? () #23 0x907484c9 in ?? () ---Type return to continue, or q return to quit--- #24 0x99437746 in ?? () #25 0xde61d2b4 in ?? () #26 0xaab0b47e in ?? () #27 0x2838cc20 in ASN1_OCTET_STRING_NDEF_it () from /lib/libcrypto.so.5 #28 0x in ?? () #29 0x in ?? () #30 0x2952e080 in ?? () #31 0x952a in ?? () #32 0x36ea in ?? () #33 0x in ?? () #34 0x2838f08c in ?? () from /lib/libcrypto.so.5 #35 0x29512080 in ?? () #36 0x2952a102 in ?? () #37 0xbf8f5d68 in ?? () #38 0x282f2eac in RAND_bytes () from /lib/libcrypto.so.5 Previous frame identical to this frame (corrupt stack?) (gdb) Thanks, Steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.0-STABLE: mount_nfs vs mount -t nfs: problems with second one, UDP timeouts and ICMP ports unreach?!
Lev Serebryakov wrote: You see? b answer with UDP port unreachable on each RPC reply! Additional info. ktrace from mount -t nfs: = 65962 mount_nfs 0.006679 RET sendto 40/0x28 65962 mount_nfs 0.006682 CALL kevent(0x4,0x638110,0x1,0x7fffe2d0,0x1,0x7fffe310) 65962 mount_nfs 10.218001 GIO fd 4 wrote 32 bytes 65962 mount_nfs 10.218018 GIO fd 4 read 0 bytes 65962 mount_nfs 10.218023 RET kevent 0 65962 mount_nfs 10.218029 CALL gettimeofday(0x7fffe320,0) 65962 mount_nfs 10.218035 RET gettimeofday 0 65962 mount_nfs 10.218040 CALL close(0x4) 65962 mount_nfs 10.218049 RET close 0 65962 mount_nfs 10.218077 CALL close(0x3) 65962 mount_nfs 10.218087 RET close 0 65962 mount_nfs 10.218101 CALL write(0x2,0x7fffdd40,0x37) 65962 mount_nfs 10.218117 GIO fd 2 wrote 55 bytes [udp] gateway:/usr/ports: NFSPROC_NULL: RPC: Timed out = ktrace (same piece) from mount_nfs: = 93109 mount_nfs 0.005458 RET sendto 40/0x28 93109 mount_nfs 0.005462 CALL kevent(0x4,0x638110,0x1,0x7fffe2a0,0x1,0x7fffe2e0) 93109 mount_nfs 0.005724 GIO fd 4 wrote 32 bytes 93109 mount_nfs 0.005738 GIO fd 4 read 32 bytes 93109 mount_nfs 0.005743 RET kevent 1 93109 mount_nfs 0.005748 CALL recvfrom(0x3,0x638134,0x2260,0,0,0) 93109 mount_nfs 0.005756 GIO fd 3 read 24 bytes 93109 mount_nfs 0.005761 RET recvfrom 24/0x18 93109 mount_nfs 0.005767 CALL close(0x4) 93109 mount_nfs 0.005775 RET close 0 93109 mount_nfs 0.005781 CALL close(0x3) 93109 mount_nfs 0.005788 RET close 0 = ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: cvsup.uk.FreeBSD.org
On Fri, 16 May 2008, Dr Josef Karthauser wrote: As a matter of interest, do you know what the peak bandwidth usage is? Based on the cvsupd log the peak is around 600KB/sec in and 360KB/sec out at about 2am. The university's bandwidth accounting system says: date hostin (MB) out (MB) total 2008-05-09 131.111.008.041 1902.863 2890.291 4793.155 2008-05-10 131.111.008.041 9278.231 5287.797 14566.028 2008-05-11 131.111.008.041 9214.064 4059.799 13273.863 2008-05-12 131.111.008.041 9248.677 4458.978 13707.655 2008-05-13 131.111.008.041 8818.575 4651.896 13470.471 2008-05-14 131.111.008.041 9254.688 5833.494 15088.182 2008-05-15 131.111.008.041 9116.638 4715.182 13831.820 Tony. -- f.anthony.n.finch [EMAIL PROTECTED] http://dotat.at/ VIKING: NORTHERLY 4 OR 5 INCREASING 6 OR 7, PERHAPS GALE 8 LATER. MODERATE BECOMING ROUGH. SHOWERS. MODERATE OR GOOD. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how much memory does increasing max rules for IPFW take up?
How are the buckets used? Are they hashed per rule number or some other mechanism? Nearly all of my states are from the same rule (eg, on a mail server for the SMTP port rule). How should I scale the buckets with the max rules? The default seems to be 4096 rules and 256 buckets. Should I maintain that ratio? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: today's build is causing errors for me
On Friday 16 May 2008 06:17:24 Jeremy Chadwick wrote: Additionally, mergemaster isn't a confusing mess. If anything, it's one of the most simple tools there is for managing /etc. The part you probably find confusing, which is the same part I did when I started using it, is the side-by-side interactive diff. It's very easy to use; r means use the text shown on the right, and l means use the text shown on the left. That is certainly the part that confused me until I referred to the Absolute FreeBSD book. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: today's build is causing errors for me
On Friday 16 May 2008 06:04:34 Rob Lytle wrote: Hi Jeremy, I used Mergemaster. Thats what I mean't when I said that I carefully merged /usr/src/etc/ with /etc. But like I said, no files were replaced that contained my own configuration, e.g. group. I will say this- that I have always considered Mergemaster a confusing mess, despite the dogma on the lists. I have been running FreeBSD and installing it since 1998, so I have some experience- but this is new behavior beyond my previous experiences. I have only been using FreeBSD for almost one year and I am still a little confused by Mergemaster, but what helped me with it was the book Absolute FreeBSD. I would not have been able to deal with it without the book. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.0-STABLE: mount_nfs vs mount -t nfs: problems with second one, UDP timeouts and ICMP ports unreach?!
Lev Serebryakov wrote: Main problem is, that /etc/fstab is processed by mount, and NFS mount hangs up on boot, as shown above :( Mounting with mount -t nfs with 7.0 server (host B) and 6.3 client (host A) works... -- // Lev Serebryakov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: g_vfs_done error third part--PLEASE HELP!
Hello Jeremy and FreeBSD friends, On Fri, May 16, 2008 at 05:27:59AM -0700, Jeremy Chadwick wrote: On Fri, May 16, 2008 at 02:14:14PM +0200, Willy Offermans wrote: On Mon, Apr 21, 2008 at 10:10:47PM +0200, Roland Smith wrote: Did you notice any file corruption in the filesystem on ar0s1g? No the two disks are brand new and I did not encounter any noticeable file corruption. However I assume that nowadays bad sectors on HD are handled by the hardware and do not need any user interaction to correct this. But maybe I'm totally wrong. You're right, but it depends on the type of disk. SCSI disks will report bad blocks to the OS regardless if it is about to mark the block as a grown defect or not. PATA and SATA disks, on the other hand, will report bad blocks to the OS only if the internal bad block list (which it manages itself -- this is what you're thinking of) is full. There are still many conditions where PATA and SATA disks can induce errors in the OS. If the disk is attempting to work around a bad block, and there's a physical error (servo problem, head crash, repetitive re-reads of the block due to dust, whatever -- something that ties up the disk for long periods of time), ATA subsystem timeouts may be seen, DMA errors, or whatever else. SMART stats will show this kind of problem. Unmount the filesystem and run fsck(8) on it. Does it report any errors? sun# fsck /dev/ar0s1g ** /dev/ar0s1g ** Last Mounted on /share ** Phase 1 - Check Blocks and Sizes INCORRECT BLOCK COUNT I=34788357 (272 should be 264) CORRECT? [yn] y INCORRECT BLOCK COUNT I=34789217 (296 should be 288) CORRECT? [yn] y ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? [yn] y SUMMARY INFORMATION BAD SALVAGE? [yn] y BLK(S) MISSING IN BIT MAPS SALVAGE? [yn] y 182863 files, 17282440 used, 120206472 free (12448 frags, 15024253 blocks, 0.0% fragmentation) * FILE SYSTEM MARKED CLEAN * * FILE SYSTEM WAS MODIFIED * The usual stuff I would say. How is this usual?. It appears to me you did have some filesystem corruption. What kind of filesystem corruption and how to solve that? I see these messages frequently if a FreeBSD machine unexpectedly reboots. Not only on this system but also on others. I never worried about it. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Willy * W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 653 27 16 23 e-mail: [EMAIL PROTECTED] Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: g_vfs_done error third part--PLEASE HELP!
Hello Kris, On Fri, May 16, 2008 at 02:43:24PM +0200, Kris Kennaway wrote: Willy Offermans wrote: Hello Roland and FreeBSD friends, I'm sorry to be so quite for a while, but I went away for a vacation. But now I'm back, I like to solve this issue. On Mon, Apr 21, 2008 at 10:10:47PM +0200, Roland Smith wrote: On Mon, Apr 21, 2008 at 09:04:03PM +0200, Willy Offermans wrote: Dear FreeBSD friends, It is already the third time that I report this error. Can someone help me in solving this issue? Probably the reason that you hear so little is that you provide so little information. Most of us are not clairvoyant. Over and over again and always after heavy disk I/O I see the following errors in the log files. If I force ar0s1g to unmount the machine spontaneously reboots. Nothing seriously seems to be damaged by this act, but anyway I cannot afford something bad happening to this production machine. Why would you force an unmount? Otherwise the device keeps on reporting to be unavailable and cannot be unmounted: sun# umount /share/ umount: unmount of /share failed: Resource temporarily unavailable Apr 18 20:02:19 sun kernel: g_vfs_done():ar0s1g[WRITE(offset=290725068800, length=4096)]error = 5 I have no clue what the errors mean, since offsets of 290725068800, 290725072896, and 290725074944 seem to be ridiculous. Does anybody have a clue what is going on? For starters, how big is ar0s1g? If the offset is in bytes, it is around 270 GB, which is not that unusual in this day and age. I have to admit that I was a bit confused by an offset value of 290725068800. There is no indication of a unit, so I assumed that it was sector but probably it is simply bytes and then indeed the number does make sense. I'm using FreeBSD 7.0, but found the error being reported before with previous versions of FreeBSD. I can and will provide more details on demand. What does 'df' say? Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ar0s1a 20308398 230438 18453290 1%/ devfs 11 0 100%/dev /dev/ar0s1d 21321454 3814482 1580125619%/usr /dev/ar0s1e 50777034 5331686 4138318611%/var /dev/ar0s1f 101554150 18813760 7461605820%/home /dev/ar0s1g 274977824 34564876 21841472414%/share pretty normal I would say. Did you notice any file corruption in the filesystem on ar0s1g? No the two disks are brand new and I did not encounter any noticeable file corruption. However I assume that nowadays bad sectors on HD are handled by the hardware and do not need any user interaction to correct this. But maybe I'm totally wrong. Unmount the filesystem and run fsck(8) on it. Does it report any errors? sun# fsck /dev/ar0s1g ** /dev/ar0s1g ** Last Mounted on /share ** Phase 1 - Check Blocks and Sizes INCORRECT BLOCK COUNT I=34788357 (272 should be 264) CORRECT? [yn] y INCORRECT BLOCK COUNT I=34789217 (296 should be 288) CORRECT? [yn] y ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? [yn] y SUMMARY INFORMATION BAD SALVAGE? [yn] y BLK(S) MISSING IN BIT MAPS SALVAGE? [yn] y 182863 files, 17282440 used, 120206472 free (12448 frags, 15024253 blocks, 0.0% fragmentation) * FILE SYSTEM MARKED CLEAN * * FILE SYSTEM WAS MODIFIED * The usual stuff I would say. No, any form of filesystem corruption is not usual. Any hints are very much appreciated. Did you manage to create a partition larger than the disk is (using newfs's -s switch)? In that case it could be that you're trying to write past the end of the device. No, look to the following output: sun# bsdlabel -A /dev/ar0s1 # /dev/ar0s1: type: unknown disk: amnesiac label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 60799 sectors/unit: 976751937 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 4194304004.2BSD0 0 0 b: 8388608 41943040 swap c: 9767519370unused0 0 # raw part, don't edit d: 44040192 503316484.2BSD 2048 16384 28552 e: 104857600 943718404.2BSD 2048 16384 28552 f: 209715200 1992294404.2BSD 2048 16384 28552 g: 567807297 4089446404.2BSD 2048 16384 28552 /dev/ar0s1g starts after 408944640*512/1024/1024=199680MB So I have to conclude that the write error message does make sense and that something seems to be wrong with the disks. The next question is what can I do about it? Should I return the disks to the shop and ask for new ones? #define
Re: g_vfs_done error third part--PLEASE HELP!
On Fri, May 16, 2008 at 05:37:56PM +0200, Willy Offermans wrote: sun# fsck /dev/ar0s1g ** /dev/ar0s1g ** Last Mounted on /share ** Phase 1 - Check Blocks and Sizes INCORRECT BLOCK COUNT I=34788357 (272 should be 264) CORRECT? [yn] y INCORRECT BLOCK COUNT I=34789217 (296 should be 288) CORRECT? [yn] y ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? [yn] y SUMMARY INFORMATION BAD SALVAGE? [yn] y BLK(S) MISSING IN BIT MAPS SALVAGE? [yn] y 182863 files, 17282440 used, 120206472 free (12448 frags, 15024253 blocks, 0.0% fragmentation) * FILE SYSTEM MARKED CLEAN * * FILE SYSTEM WAS MODIFIED * The usual stuff I would say. How is this usual?. It appears to me you did have some filesystem corruption. What kind of filesystem corruption and how to solve that? That's difficult to answer, for a lot of reasons. Your original post stated that you were seeing g_vfs_done errors on the console, and you were worried about what they implied. Then someone asked you have you fsck'd the filesystem?, and you hadn't. Then you did fsck it, and as can be seen above, the filesystem had errors. When combined with your below comment, it's very difficult to figure out what's going on with your system over there, or what information you're not disclosing. Additionally, kris@ has stated that it looks like you may have a hard disk that's gone bad, and that's a strong possibility as well. SMART statistics of the drives in your RAID array would be useful. I see these messages frequently if a FreeBSD machine unexpectedly reboots. Not only on this system but also on others. I never worried about it. Are you saying the above errors experienced were caused by an unexpected crash or reboot? If so, the filesystem should have been automatically fsck'd shortly (60-120 seconds) after getting a login: prompt on the console. Is your filesystem UFS2 with softupdates enabled? If so, and the automatic fsck didn't happen, then that's something separate to look into -- it should happen automatically with softupdates enabled. More importantly, though, would be the explanation for why your system is crashing/rebooting/power-cycling. Data corruption can happen in those situations, especially the latter, but any form of non-clean shutdown should induce a fsck on UFS2+softupdate filesystems. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
udf
Howdy! What is the experience regarding udf on cd/dvd on 7.0? I saw netbsd mail few days ago having those steps: newfs_udf and mount_udf. Best regards Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: udf
Zoran Kolic wrote: Howdy! What is the experience regarding udf on cd/dvd on 7.0? I saw netbsd mail few days ago having those steps: newfs_udf and mount_udf. Best regards From man mount_udf (FreeBSD7) HISTORY The mount_udf utility first appeared in FreeBSD 5.0. FreeBSD 7.0 March 23, 2002 FreeBSD 7.0 I have no idea for newfs_udf , and what is supposed this to do :) Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: udf
On Fri, May 16, 2008 at 07:08:11PM +0300, Stefan Lambrev wrote: From man mount_udf (FreeBSD7) HISTORY The mount_udf utility first appeared in FreeBSD 5.0. FreeBSD 7.0 March 23, 2002 FreeBSD 7.0 I have no idea for newfs_udf , and what is supposed this to do :) It creates a UDF (commonly DVD/DVD Audio) filesystem. NetBSD and Solaris 10 both have this. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7
Alexandre Sunny Kovalenko wrote: On Mon, 2008-05-12 at 19:33 -0700, Sam Leffler wrote: Alexandre Sunny Kovalenko wrote: I seem to be able to lock my machine by going into wpa_cli and asking it to 'reassoc'. The reason for question mark after hard is that debug information (caused by wlandebug and athdebug) is being printed on the console. The only way to get machine's attention is to hold power button for 8 seconds. So this is just livelock due to console debug msgs. I am not sure, I have parsed this well enough, so I will try to clarify: machine becomes unresponsive *without* any debugging turned on, to an extent that pressing the power button twice *does not* generate ACPI console message (something to the tune of going into S5 already -- gimme a break). If I turn ath debugging on, I do see those messages, and only them, scrolling on the console. Guess I misunderstood you. Note: manual reassociation is just the handy way to reproduce the problem -- I have had machine locking up on me the whole day long completely on its own. Below are, what I think, relevant pieces of information. If anything is missing, please, chastise me appropriately and will do my best to provide. I have rigged firewire console, but am unable to break into the debugger locally or remotely. I see no log msgs. I am sorry -- mailman must have eaten it up -- I have posted them here now: http://members.verizon.net/~akovalenko/Misc/reassoc.log.gz All I see in the log is normal scanning. While I am on the subject, I would appreciate couple of the troubleshooting suggestions: * is there any way to get sysctl dev.ath.0.debug to appear, other then defining ATH_DEBUG in something like /usr/src/sys/dev/ath/ah_osdep.h? options ATH_DEBUG That does not seem to work for if_ath built as the module, sorry for not being clear in that respect. If you are build a module then you must edit the Makefile to add the option. Feel free to provide a patch to improve this situation. * is there minimal, but still usable mask for athdebug and wlandebug? I have started with 0x and kept trimming likely high-volume settings until output slowed down to the reasonable pace. Why do you want debug msgs from ath? The debug msgs from wlandebug depend on what you're trying to debug. Because neither wpa_supplicant (quoted below), nor wlandebug (in the URL above) gave me the answer -- it looks like we are going into the scan with the specific SSID in mind and never come back, so I went for the next level. However, could you, please, clarify that I understood you correctly -- you *do not* want to see mix of wlandebug and athdebug messages in the report, and I should turn wlandebug off before turning athdebug on, right? wlandebug msgs are typically low duty and can be left enabled when you add driver-level debug msgs. But I can't see from the log you sent what is going on. Try reducing the noise by eliminating all the ath debug msgs; maybe provide one log w/ only wlan msgs and one w/ wlan+ath. I suggest that when debugging you start from the highest layer and move downward. If you can't find what you need in a wpa_supplicant log then turn on msgs in net80211 with wlandebug. If that doesn't tell you what you need then move to the driver. Blindly turning everything on can easily livelock your system. That's what I did -- what I have posted is the end result of the walking down that chain, and I assumed, possibly incorrectly, that you would want result of all three to put things in context. I do apologize for the misunderstanding. For high volume msgs I often do something like: athdebug +intr; sleep 1; athdebug -intr or athdebug +intr; read x; athdebug -intr so a carriage return will disable msgs. Thank you for the suggestion. * what facility does wpa_supplicant use, when forced to syslog by -s switch? trouble% cd /data/freebsd/head/contrib/wpa_supplicant/ trouble% grep openlog *.c common.c: openlog(wpa_supplicant, LOG_PID | LOG_NDELAY, LOG_DAEMON); Thank you, should have done this myself, sorry. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: udf
Jeremy Chadwick wrote: On Fri, May 16, 2008 at 07:08:11PM +0300, Stefan Lambrev wrote: From man mount_udf (FreeBSD7) HISTORY The mount_udf utility first appeared in FreeBSD 5.0. FreeBSD 7.0 March 23, 2002 FreeBSD 7.0 I have no idea for newfs_udf , and what is supposed this to do :) It creates a UDF (commonly DVD/DVD Audio) filesystem. NetBSD and Solaris 10 both have this. There is no write support in UDF in FreeBSD. When I wrote the fs code, packet writing was the only way to do discrete writes, and it's very hard to make that work with a traditional VM system. Now with DVD+R, it's probably worth someone's time to look at it (though the append-only nature of +R means that there are still some nasty VM complications to deal with). Until that happens, mkisofs can be used to create a static UDF filesystem. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl.
* Evren Yurtesen ([EMAIL PROTECTED]) wrote: I guess one good question is, how can one see the number of PV entries used by a process? shouldnt these appear in the output of ipcs -a command? No, PV entries are a VM thing, not limited to SysV IPC. Another good question is, in many places there is references to rebooting after putting a new vm.pmap.shpgperproc value to loader.conf. However I just changed this on a running system, has it really been changed or was I suppose to reboot? Looking at the code it should be fine, the limit's just a couple of integers. In either case, I already increased vm.pmap.shpgperproc to 2000 (from 200) and still the error occurs, there is not so much load on this box, maybe there is a leak somewhere? What sort of load is there? Do you have a bunch of big processes sharing significant chunks of memory in any way? -- Thomas 'Freaky' Hurst http://hur.st/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl.
Thomas Hurst wrote: In either case, I already increased vm.pmap.shpgperproc to 2000 (from 200) and still the error occurs, there is not so much load on this box, maybe there is a leak somewhere? What sort of load is there? Do you have a bunch of big processes sharing significant chunks of memory in any way? How do I see what process is sharing memory and how much memory? There are a bunch of apache 2.2 processes working normally about 20-30 processes. This box doesnt do much more than that... I just checked the machine and here is what it looks like: 2:32PM up 18 days, 5:40, 3 users, load averages: 0.41, 0.36, 0.27 web:/root#ps ax |grep http 21429 ?? Ss 0:18.08 /usr/local/sbin/httpd 86473 ?? S 0:00.09 /usr/local/sbin/httpd 86659 ?? S 0:00.09 /usr/local/sbin/httpd 86851 ?? S 0:00.07 /usr/local/sbin/httpd 86857 ?? S 0:00.04 /usr/local/sbin/httpd 86912 ?? S 0:00.04 /usr/local/sbin/httpd 86918 ?? S 0:00.03 /usr/local/sbin/httpd 86919 ?? S 0:00.03 /usr/local/sbin/httpd 86996 ?? S 0:00.04 /usr/local/sbin/httpd 87023 ?? S 0:00.02 /usr/local/sbin/httpd 87028 ?? S 0:00.03 /usr/local/sbin/httpd 87059 ?? S 0:00.01 /usr/local/sbin/httpd 87060 ?? S 0:00.01 /usr/local/sbin/httpd 87062 ?? S 0:00.02 /usr/local/sbin/httpd 87065 ?? S 0:00.03 /usr/local/sbin/httpd 87074 ?? S 0:00.01 /usr/local/sbin/httpd 87076 ?? S 0:00.02 /usr/local/sbin/httpd 87077 ?? S 0:00.03 /usr/local/sbin/httpd 87079 ?? S 0:00.04 /usr/local/sbin/httpd 87081 ?? S 0:00.03 /usr/local/sbin/httpd 87083 ?? S 0:00.03 /usr/local/sbin/httpd 87085 ?? S 0:00.04 /usr/local/sbin/httpd 87090 ?? S 0:00.02 /usr/local/sbin/httpd 87190 p1 R+ 0:00.00 grep http web:/root# Although I see now that for 2 days the PV entries error did not appear. I wonder if it is spooling up somehow... There is a cron job restarting apache everyday at midnight so it cant be apache leaking perhaps. Thanks, Evren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: g_vfs_done error third part--PLEASE HELP!
On Fri, May 16, 2008 at 02:14:14PM +0200, Willy Offermans wrote: Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ar0s1a 20308398 230438 18453290 1%/ devfs 11 0 100%/dev /dev/ar0s1d 21321454 3814482 1580125619%/usr /dev/ar0s1e 50777034 5331686 4138318611%/var /dev/ar0s1f 101554150 18813760 7461605820%/home /dev/ar0s1g 274977824 34564876 21841472414%/share pretty normal I would say. Yes. Did you notice any file corruption in the filesystem on ar0s1g? No the two disks are brand new and I did not encounter any noticeable file corruption. However I assume that nowadays bad sectors on HD are handled by the hardware and do not need any user interaction to correct this. But maybe I'm totally wrong. Every ATA disk has spare sectors, and they usually don't report bad blocks untill the spares are exhausted. In which case it is prudent to replace the disk. Unmount the filesystem and run fsck(8) on it. Does it report any errors? sun# fsck /dev/ar0s1g ** /dev/ar0s1g ** Last Mounted on /share ** Phase 1 - Check Blocks and Sizes INCORRECT BLOCK COUNT I=34788357 (272 should be 264) CORRECT? [yn] y INCORRECT BLOCK COUNT I=34789217 (296 should be 288) CORRECT? [yn] y ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? [yn] y SUMMARY INFORMATION BAD SALVAGE? [yn] y BLK(S) MISSING IN BIT MAPS SALVAGE? [yn] y 182863 files, 17282440 used, 120206472 free (12448 frags, 15024253 blocks, 0.0% fragmentation) * FILE SYSTEM MARKED CLEAN * * FILE SYSTEM WAS MODIFIED * The usual stuff I would say. Disk corruption is never normal. It can be explained by if the machine crashed or was power-cycles before the disks were unmounted, but it can also indicate hardware troubles. Any hints are very much appreciated. So I have to conclude that the write error message does make sense and that something seems to be wrong with the disks. The next question is what can I do about it? Should I return the disks to the shop and ask for new ones? Install sysutils/smartmontools, and run 'smartctl -A /dev/adX|less', where X are the numbers of the drives in the RAID array. In the output, look at the values for Reallocated_Sector_Ct, Current_Pending_Sector, Offline_Uncorrectable, which is the last number that you see on each line. A small number for Reallocated_Sector_Ct is allowable. But non-zero counts for Current_Pending_Sector or Offline_Uncorrectable means it's time to get a new disk. However other people that I have contacted and who had a similar problem before have solved it by using software raid setup instead of a hardware raid setup. This seems to indicate that there is some bug in the FreeBSD code. The RAID support that you find on most desktop motherboards _is_ software RAID. See ataraid(4). Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpNcSsEdIcRL.pgp Description: PGP signature
Re: FreeBSD 7.0-STABLE: mount_nfs vs mount -t nfs: problems with second one, UDP timeouts and ICMP ports unreach?!
Hello, freebsd-stable. You wrote 16 мая 2008 г., 14:40:18: There is NO any firewalls on B. And, I repeat, it WORKS when I call mount_nfs directly in a moment! Adding `-o -c' to mount (to pass `-c' to mount_nfs) helps. But I'm very curious WHY mount_nfs, called directly, work WITHOUT `-c'... -- // Black Lion AKA Lev Serebryakov [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: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl.
* Evren Yurtesen ([EMAIL PROTECTED]) wrote: How do I see what process is sharing memory and how much memory? Guessing is normally sufficient; typically it's processes with the same name and similar size/res. On 7-STABLE you can use procstat -v to look at the VM mappings for a process, but typically that'll be overkill. There are a bunch of apache 2.2 processes working normally about 20-30 processes. This box doesnt do much more than that... I just checked the machine and here is what it looks like: 2:32PM up 18 days, 5:40, 3 users, load averages: 0.41, 0.36, 0.27 web:/root#ps ax |grep http 21429 ?? Ss 0:18.08 /usr/local/sbin/httpd 86473 ?? S 0:00.09 /usr/local/sbin/httpd 86659 ?? S 0:00.09 /usr/local/sbin/httpd Although I see now that for 2 days the PV entries error did not appear. I wonder if it is spooling up somehow... They do look a bit small to be triggering it; assuming they're sharing most of that, that's still only about 400k pv entries; 5MB or so (12 bytes per entry). The systems I've seen pv entries run out on run to a couple of orders of magnitude more than that. There is a cron job restarting apache everyday at midnight so it cant be apache leaking perhaps. Load spikes maybe? Child count running into the stratosphere? Big PHP opcode cache? -- Thomas 'Freaky' Hurst http://hur.st/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ciss(4) not coping with large arrays?
On Fri, May 16, 2008 at 01:19:33AM -0700, Paul Saab wrote: Emil: Running today's RELENG_7 (although 7.0-RELEASE has the same problem), GENERIC kernel on an amd64 and I can't seem to get a da(4) device for any arrays bigger than 2TB. Please try the following patch: http://yogurt.org/FreeBSD/ciss_large.diff This works a treat! da4 at ciss0 bus 0 target 4 lun 0 da4: COMPAQ RAID 0 VOLUME OK Fixed Direct Access SCSI-5 device da4: 135.168MB/s transfers da4: 3815350MB (7813837232 512 byte sectors: 255H 32S/T 65535C) Double thanks for committing it, and for merging to RELENG_7! --Emil ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
