system/6586: rdist (file larger than 2GB) times out but will not die -- Testers needed

[Steven R. Gerber]

Hi folks.
Current rdist will timeout with files >2GB, log as finished, but will
not die.
The bug (system/6586) was originally noted by IBM (AIX) in 2006:
https://www-304.ibm.com/support/docview.wss?uid=isg1IY85396
I have patches for the client rdist and server rdistd.
I have tested i386 and amd64, in both directions.  Please continue this.
Testing on alpha would be especially welcomed.
Thanks to everyone in advance.

Steven

client.c
I did check into the comparison at line 689. Basically, it is ASSUMED
that link files (not the actual files) will be tiny.
The only attributes returned from an lstat() that refer to the symbolic
link itself are the file type (S_IFLNK), size, blocks, and link count
(always 1).
That code is safe FOR NOW ...
IF the (meta)data in the link grows a lot THEN it could be a problem.

This should be a good state.
1. FIXED bug of filesize >2GB -- calculations and messages
2. FIXED similar in minimum freespace (and free files)
3. verified/fixed system write (and read) calls
4. TODO improve buffering

i386 -> i386  OK
i386 -> i386OK
amd64 -> i386 OK
amd64 -> i386   OK
i386 -> amd64 OK
i386 -> amd64   OK


diff -uw /usr/src/usr.bin/rdist/Makefile rdist/Makefile
--- /usr/src/usr.bin/rdist/Makefile Sun Jan  4 21:55:28 2004
+++ rdist/Makefile  Mon Mar 28 22:03:24 2011
@@ -3,6 +3,7 @@

 PROG=  rdist
 CFLAGS+=-I. -I${.CURDIR} -DOS_H=\"os-openbsd.h\"
+#CFLAGS+=-Wall -pedantic
 SRCS=  gram.y child.c client.c common.c distopt.c docmd.c expand.c \
isexec.c lookup.c message.c rdist.c
 CLEANFILES+=gram.c y.tab.h
diff -uw /usr/src/usr.bin/rdist/child.c rdist/child.c
--- /usr/src/usr.bin/rdist/child.c  Thu Oct 29 00:34:05 2009
+++ rdist/child.c   Sun Mar 27 16:36:19 2011
@@ -177,7 +177,7 @@
 readchild(CHILD *child)
 {
char rbuf[BUFSIZ];
-   int amt;
+   ssize_t amt;

debugmsg(DM_CALL, "[readchild(%s, %d, %d) start]",
 child->c_name, child->c_pid, child->c_readfd);
@@ -196,7 +196,7 @@
 */
while ((amt = read(child->c_readfd, rbuf, sizeof(rbuf))) > 0) {
/* XXX remove these debug calls */
-   debugmsg(DM_MISC, "[readchild(%s, %d, %d) got %d bytes]",
+   debugmsg(DM_MISC, "[readchild(%s, %d, %d) got %ld bytes]",
 child->c_name, child->c_pid, child->c_readfd, amt);

(void) xwrite(fileno(stdout), rbuf, amt);
@@ -205,7 +205,7 @@
 child->c_name, child->c_pid, child->c_readfd);
}

-   debugmsg(DM_MISC, "readchild(%s, %d, %d) done: amt = %d errno = %d\n",
+   debugmsg(DM_MISC, "readchild(%s, %d, %d) done: amt = %ld errno = %d\n",
 child->c_name, child->c_pid, child->c_readfd, amt, errno);

/*
diff -uw /usr/src/usr.bin/rdist/client.c rdist/client.c
--- /usr/src/usr.bin/rdist/client.c Thu Oct 29 00:34:06 2009
+++ rdist/client.c  Sun Mar 27 16:05:15 2011
@@ -399,8 +399,8 @@
 */
ENCODE(ername, rname);

-   (void) sendcmd(C_RECVREG, "%o %04o %ld %ld %ld %s %s %s",
-  opts, stb->st_mode & 0, (long) stb->st_size,
+   (void) sendcmd(C_RECVREG, "%o %04o %lld %ld %ld %s %s %s",
+   opts, stb->st_mode & 0, stb->st_size,
   stb->st_mtime, stb->st_atime,
   user, group, ername);
if (response() < 0) {
@@ -409,8 +409,8 @@
}


-   debugmsg(DM_MISC, "Send file '%s' %ld bytes\n", rname,
-(long) stb->st_size);
+   debugmsg(DM_MISC, "Send file '%s' %lld bytes\n", rname,
+   stb->st_size);

/*
 * Set remote time out alarm handler.
@@ -666,8 +666,8 @@
 * Gather and send basic link info
 */
ENCODE(ername, rname);
-   (void) sendcmd(C_RECVSYMLINK, "%o %04o %ld %ld %ld %s %s %s",
-  opts, stb->st_mode & 0, (long) stb->st_size,
+   (void) sendcmd(C_RECVSYMLINK, "%o %04o %lld %ld %ld %s %s %s",
+   opts, stb->st_mode & 0, stb->st_size,
   stb->st_mtime, stb->st_atime,
   user, group, ername);
if (response() < 0)
@@ -869,7 +869,7 @@
/*
 * Parse size
 */
-   size = (off_t) strtol(cp, (char **)&cp, 10);
+   size = (off_t) strtoll(cp, (char **)&cp, 10);
if (*cp++ != ' ') {
error("update: size not delimited");
return(US_NOTHING);
@@ -878,7 +878,7 @@
/*
 * Parse mtime
 */
-   mtime = strtol(cp, (char **)&cp, 10);
+   mtime = (time_t) strtol(cp, (char **)&cp, 10);
if (*cp++ != ' ') {
error("update: mti

Re: -current kernel freeze

[STeve Andre']

On 04/07/11 20:33, Florian Fuessl wrote:

Hi,

upgrading GENERIC kernel from snapshot 24-Mar-2011 to -current results in
system freezes after some minutes (up to some hours) without any error
message, here:

OpenBSD 4.9-current (GENERIC) #1: Fri Apr  8 02:20:49 CEST 2011
 root@[...]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Xeon(TM) CPU 3.00GHz ("GenuineIntel" 686-class) 3.01 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLU
SH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,CNXT-ID,CX16,xT
PR
real mem  = 1073258496 (1023MB)
avail mem = 1045561344 (997MB)


[snip]

I can confirm this.  Twice in the last day or so my package builder
has frozen after a few hours.  Previously on Wednesday the kernel
paniced.

OpenBSD 4.9-current (GENERIC.MP) #11: Thu Apr  7 21:29:35 EDT 2011
root@sata6:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz ("GenuineIntel" 
686-class) 3.51 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX

real mem  = 3209814016 (3061MB)
avail mem = 3147149312 (3001MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 10/20/10, SMBIOS rev. 2.7 @ 
0xead50 (20 entries)

bios0: vendor American Megatrends Inc. version "4.6.4" date 02/17/2011
bios0: BIOSTAR Group TP67B+
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC SSDT MCFG HPET ASPT
acpi0: wakeup devices PS2K(S1) PS2M(S1) UAR1(S4) BR20(S1) EUSB(S4) 
USBE(S4) P0P1(S4) P0P2(S4) P0P3(S4) P0P4(S4) PEX0(S4) PEX1(S4) PEX2(S4) 
PEX3(S4) PEX4(S4) PEX5(S4) PEX6(S4) PEX7(S4) SLPB(S0) PWRB(S4)

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: unknown i686 model 0x2a, can't get bus clock (0x0)
cpu0: apic clock running at 102MHz
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz ("GenuineIntel" 
686-class) 3.51 GHz
cpu1: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX

cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz ("GenuineIntel" 
686-class) 3.51 GHz
cpu2: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX

cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz ("GenuineIntel" 
686-class) 3.51 GHz
cpu3: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX

cpu4 at mainbus0: apid 1 (application processor)
cpu4: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz ("GenuineIntel" 
686-class) 3.51 GHz
cpu4: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX

cpu5 at mainbus0: apid 3 (application processor)
cpu5: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz ("GenuineIntel" 
686-class) 3.51 GHz
cpu5: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX

cpu6 at mainbus0: apid 5 (application processor)
cpu6: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz ("GenuineIntel" 
686-class) 3.51 GHz
cpu6: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX

cpu7 at mainbus0: apid 7 (application processor)
cpu7: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz ("GenuineIntel" 
686-class) 3.51 GHz
cpu7: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX

ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (P0P1)
acpiprt2 at acpi0: bus -1 (P0P2)
acpiprt3 at acpi0: bus -1 (P0P3)
acpiprt4 at acpi0: bus -1 (P0P4)
acpiprt5 at acpi0: bus 2 (PEX0)
acpiprt6 at acpi0: bus 3 (PEX1)
acpiprt7 at acpi0: bus 4 (PEX2)
acpiprt8 at acpi0: bus -1 (PEX3)
acpiprt9 at acpi0: bus -1 (PEX4)
acpiprt10 at acpi0: bus -1 (PEX5)
acpiprt11 at acpi0:

Compactas Digitales Importadas

[DigitalesNet]

Consulte por otros modelos  de cámaras y
filmadoras compactas Nikon, Canon, Panasonic,  Sony, JVC
  USD211   Sony 
DSC-W330 Cámara  digital
compacta, sin visor / Sensor SuperHAD  de
14,10 MP efectivos / Objetivo (en 35 mm) 26,0   
  - 105,0 mm / Zoom 4x (óptico) / Soportes   
  compatibles SD Card, MemoryStick Duo, MemoryStick 
Pro Duo, MemoryStick Pro-HG Duo, microSDHC, MemoryStick 
Pro Duo High Speed / Pantalla TFT de 3,00 pulgadas  
USD220   Sony   
  DSC-W350 Cámara  digital compacta,
sin visor / Sensor SuperHAD  de 14,10 MP
efectivos Objetivo (en 35 mm) 26,0  - 105,0
mm / Zoom 4x (óptico) / Soportes 
compatibles SD Card, MemoryStick Duo, MemoryStick   
  Pro Duo, SDHC, MemoryStick Pro-HG Duo, MemoryStick
 Pro Duo High Speed / Pantalla TFT de 2,70 pulgadas Sony DSC-HX1
 USD  495 Canon 
 SX130 IS  USD  279 Panasonic TZ10/ZS7 
USD  369 Nikon  
L110   USD  345

amd64 pmap diff to g/c ifdef _LP64

[Brad]

Some _LP64 ifdef's leftover from rev 1.1. They appear to be unnecessary
since this code is only for amd64 anyway and thus a 64-bit arch.


Index: pmap.c
===
RCS file: /home/cvs/src/sys/arch/amd64/amd64/pmap.c,v
retrieving revision 1.61
diff -u -p -r1.61 pmap.c
--- pmap.c  14 Mar 2011 00:05:46 -  1.61
+++ pmap.c  8 Apr 2011 00:41:33 -
@@ -289,10 +289,8 @@ extern paddr_t msgbuf_paddr;
 extern vaddr_t idt_vaddr;  /* we allocate IDT early */
 extern paddr_t idt_paddr;
 
-#ifdef _LP64
 extern vaddr_t lo32_vaddr;
 extern vaddr_t lo32_paddr;
-#endif
 
 vaddr_t virtual_avail;
 extern int end;
@@ -649,7 +647,6 @@ pmap_bootstrap(paddr_t first_avail, padd
idt_paddr = first_avail;/* steal a page */
first_avail += 2 * PAGE_SIZE;
 
-#ifdef _LP64
/*
 * Grab a page below 4G for things that need it (i.e.
 * having an initial %cr3 for the MP trampoline).
@@ -658,7 +655,7 @@ pmap_bootstrap(paddr_t first_avail, padd
virtual_avail += PAGE_SIZE;
lo32_paddr = first_avail;
first_avail += PAGE_SIZE;
-#endif
+
/*
 * init the global lists.
 */

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: -current kernel freeze

[Rod Whitworth]

On Fri, 8 Apr 2011 02:33:51 +0200, Florian Fuessl wrote:

>upgrading GENERIC kernel from snapshot 24-Mar-2011 to -current results in
>system freezes after some minutes (up to some hours) without any error
>message, here:
>
>OpenBSD 4.9-current (GENERIC) #1: Fri Apr  8 02:20:49 CEST 2011
>root@[...]:/usr/src/sys/arch/i386/compile/GENERIC
>cpu0: Intel(R) Xeon(TM) CPU 3.00GHz ("GenuineIntel" 686-class) 3.01 GHz
>cpu0:
>FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLU
>SH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,CNXT-ID,CX16,xT
>PR
8> subscribed to the list.
Mail to the sender address that does not originate at the list server is 
tarpitted. The reply-to: address is provided for those who feel compelled to 
reply off list. Thankyou.

Rod/
---
This life is not the real thing.
It is not even in Beta.
If it was, then OpenBSD would already have a man page for it.

-current kernel freeze

[Florian Fuessl]

Hi,

upgrading GENERIC kernel from snapshot 24-Mar-2011 to -current results in
system freezes after some minutes (up to some hours) without any error
message, here:

OpenBSD 4.9-current (GENERIC) #1: Fri Apr  8 02:20:49 CEST 2011
root@[...]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Xeon(TM) CPU 3.00GHz ("GenuineIntel" 686-class) 3.01 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLU
SH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,CNXT-ID,CX16,xT
PR
real mem  = 1073258496 (1023MB)
avail mem = 1045561344 (997MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 12/31/99, BIOS32 rev. 0 @ 0xf,
SMBIOS rev. 2.3 @ 0xec000 (77 entries)
bios0: vendor HP version "P51" date 04/26/2006
bios0: HP ProLiant DL380 G4
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP SPCR MCFG APIC
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 200MHz
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins
ioapic1 at mainbus0: apid 9 pa 0xfec8, version 20, 24 pins
ioapic2 at mainbus0: apid 10 pa 0xfec80400, version 20, 24 pins
ioapic3 at mainbus0: apid 11 pa 0xfec84000, version 20, 24 pins
ioapic4 at mainbus0: apid 12 pa 0xfec84400, version 20, 24 pins
acpiprt0 at acpi0: bus 1 (IP2P)
acpiprt1 at acpi0: bus 3 (PCXA)
acpiprt2 at acpi0: bus 4 (PCXB)
acpiprt3 at acpi0: bus 2 (PTA0)
acpiprt4 at acpi0: bus 6 (PCXC)
acpiprt5 at acpi0: bus 10 (PCXD)
acpiprt6 at acpi0: bus 5 (PTC0)
acpiprt7 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0
acpitz0 at acpi0: critical temperature 31 degC
bios0: ROM list: 0xc/0x8000 0xc8000/0x4000! 0xcc000/0x1600
0xee000/0x2000!
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
bridge io address conflict 0x1000/0x3000
pchb0 at pci0 dev 0 function 0 "Intel E7520 Host" rev 0x0c
ppb0 at pci0 dev 2 function 0 "Intel E7520 PCIE" rev 0x0c
pci1 at ppb0 bus 2
ppb1 at pci1 dev 0 function 0 "Intel PCIE-PCIE" rev 0x09
pci2 at ppb1 bus 3
bge0 at pci2 dev 1 function 0 "Broadcom BCM5704C" rev 0x10, BCM5704 B0
(0x2100): apic 9 int 1 (irq 5), address 00:18:fe:72:82:73
brgphy0 at bge0 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0
bge1 at pci2 dev 1 function 1 "Broadcom BCM5704C" rev 0x10, BCM5704 B0
(0x2100): apic 9 int 2 (irq 5), address 00:18:fe:72:82:72
brgphy1 at bge1 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0
ppb2 at pci1 dev 0 function 2 "Intel PCIE-PCIE" rev 0x09
pci3 at ppb2 bus 4
ciss0 at pci3 dev 3 function 0 "Compaq Smart Array 64xx" rev 0x01: apic 10
int 3 (irq 5)
ciss0: 1 LD, HW rev 1, FW 2.76/2.76, 64bit fifo
scsibus0 at ciss0: 1 targets
sd0 at scsibus0 targ 0 lun 0:  SCSI3 0/direct
fixed
sd0: 69459MB, 512 bytes/sec, 142253280 sec total
ppb3 at pci0 dev 6 function 0 "Intel E7520 PCIE" rev 0x0c: apic 8 int 16
(irq 255)
pci4 at ppb3 bus 5
ppb4 at pci4 dev 0 function 0 "Intel PCIE-PCIE" rev 0x09
pci5 at ppb4 bus 6
em0 at pci5 dev 1 function 0 "Intel PRO/1000MT (82546GB)" rev 0x03: apic 11
int 2 (irq 5), address 00:04:23:d6:cc:40
em1 at pci5 dev 1 function 1 "Intel PRO/1000MT (82546GB)" rev 0x03: apic 11
int 1 (irq 5), address 00:04:23:d6:cc:41
ppb5 at pci4 dev 0 function 2 "Intel PCIE-PCIE" rev 0x09
pci6 at ppb5 bus 10
em2 at pci6 dev 1 function 0 "Intel PRO/1000MT (82546GB)" rev 0x03: apic 12
int 1 (irq 5), address 00:04:23:ce:cb:74
em3 at pci6 dev 1 function 1 "Intel PRO/1000MT (82546GB)" rev 0x03: apic 12
int 2 (irq 5), address 00:04:23:ce:cb:75
uhci0 at pci0 dev 29 function 0 "Intel 82801EB/ER USB" rev 0x02: apic 8 int
16 (irq 5)
uhci1 at pci0 dev 29 function 1 "Intel 82801EB/ER USB" rev 0x02: apic 8 int
19 (irq 5)
uhci2 at pci0 dev 29 function 2 "Intel 82801EB/ER USB" rev 0x02: apic 8 int
18 (irq 5)
uhci3 at pci0 dev 29 function 3 "Intel 82801EB/ER USB" rev 0x02: apic 8 int
16 (irq 5)
ehci0 at pci0 dev 29 function 7 "Intel 82801EB/ER USB2" rev 0x02: apic 8 int
23 (irq 5)
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb6 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xc2
pci7 at ppb6 bus 1
vga1 at pci7 dev 3 function 0 "ATI Rage XL" rev 0x27
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
"Compaq iLO" rev 0x01 at pci7 dev 4 function 0 not configured
"Compaq iLO" rev 0x01 at pci7 dev 4 function 2 not configured
ichpcib0 at pci0 dev 31 function 0 "Intel 82801EB/ER LPC" rev 0x02
pciide0 at pci0 dev 31 function 1 "Intel 82801EB/ER IDE" rev 0x02: DMA,
channel 0 configured to compatibility, channel 1 configured to compatibility
atapiscsi0 at pciide0 channel 0 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0:  ATAPI
5/cdrom removable
cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 disabled (no drives)
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 "In

Re: http gzip support for ftp

[Stuart Henderson]

On 2011/04/07 15:03, Martynas Venckus wrote:
> 
> As much as I like it, I'm not sure we'll be able to enable this by
> default, though.  There are quite some misconfigured servers out
> there, like:
>   http://elinks.cz/download/elinks-0.11.7.tar.gz
> 
> This one incorrectly sends:
>   Content-Encoding: gzip
> 
> While it doesn't actually compress it (twice).  So the client
> decompresses it, and you end up actually having decompressed TAR
> called 'elinks-0.11.7.tar.gz'.
> 

yes, this causes a big problem for ports distfile fetching.

Modele su cuerpo sin esfuerzos y comodamente

[Netwin Store]

Abtronic  X2   $
 130  Balanza  digital   $  
   65  Elecroestimulador 
Etong   $  170

Possible PF bug with block and reply-to

[Michael Lechtermann]

Hello,

sorry for the long text, but I try to be thorough with the description.

I have a router which connects to another machine using a Layer 2 VPN.
When that connection is active, a new default route with higher
(actually its numerically lower) priority is added, to overwrite the old
one.

Destination   Gateway  Flags   RefsUse   Mtu  Prio Iface
default   172.16.94.113UG 2482 -32 tun0
default   217.0.116.247UGS   20203 -48 pppoe0


For incoming connections on pppoe0 I am using reply-to, so the packets
go back out where they came in. That works really good.

Now, in the pf.conf I am setting "set block-policy return", just to be
nice and to allow for easier debugging.

The problem here is, that with just having a "block log" at the
beginning of the ruleset, those ICMP and TCP resets are being sent out
using tun0 instead of pppoe0.

I didn't see that at first but I guess it is to be expected.

Now I added a "block in log on $ext_if inet reply-to ( ... )" rule, but
it seems, that the reply-to part is getting ignored here. The resets
packets still go out using the tun0 interface.

Unfortunately it also isn't possible to use reply-to with match rules.

Sadly I just have some very basic C skills, meaning that all the PF
stuff is way over my head. I hope that someone help me here. ;-)

If you want to see my /etc/pf.conf, I'll send it off list.

Regards,
Michael Lechtermann


# dmesg
OpenBSD 4.9 (GENERIC) #671: Wed Mar  2 07:09:00 MST 2011
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD"
586-class) 499 MHz
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX
real mem  = 268009472 (255MB)
avail mem = 253493248 (241MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 12/10/07, BIOS32 rev. 0 @ 0xfceb2
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xe/0xa800
cpu0 at mainbus0: (uniprocessor)
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x31
glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
vr0 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10,
address 00:0d:b9:12:73:54
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr1 at pci0 dev 10 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11,
address 00:0d:b9:12:73:55
ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr2 at pci0 dev 11 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 12,
address 00:0d:b9:12:73:56
ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
glxpcib0 at pci0 dev 15 function 0 "AMD CS5536 ISA" rev 0x03: rev 3,
32-bit 3579545Hz timer, watchdog, gpio
gpio0 at glxpcib0: 32 pins
pciide0 at pci0 dev 15 function 2 "AMD CS5536 IDE" rev 0x01: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: 
wd0: 1-sector PIO, LBA, 971MB, 1989792 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 4
pciide0: channel 1 ignored (disabled)
ohci0 at pci0 dev 15 function 4 "AMD CS5536 USB" rev 0x02: irq 15,
version 1.0, legacy support
ehci0 at pci0 dev 15 function 5 "AMD CS5536 USB" rev 0x02: irq 15
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "AMD EHCI root hub" rev 2.00/1.00 addr 1
isa0 at glxpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 "AMD OHCI root hub" rev 1.00/1.00 addr 1
biomask e3ef netmask ffef ttymask 
mtrr: K6-family MTRR support (2 registers)
nvram: invalid checksum
vscsi0 at root
scsibus0 at vscsi0: 256 targets
softraid0 at root
root on wd0a swap on wd0b dump on wd0b
clock: unknown CMOS layout
gpioow0 at gpio0: DATA[4] open-drain pull-up
onewire0 at gpioow0

Yeeloong fast resume diff

[Miod Vallat]

Here is what I have currently to make the Lemote Yeeloong resume without
that long 31 second delay.

What happens is that the reset code waits until each valid channel
reports itself as ready, giving up after 31 seconds.

However, as hinted by the comments in wdactivate(), we need to reset
twice, and the first reset will only warm up the controller, not the
drives. So we do not have to wait here, this only matters during the
second reset.

The wd_get_params() added after the reset was a leftover from dlg@'s
tinkering, and is definitely necessary to prevent the dreaded `spurious
interrupt' situation after reset.

I tried to make the diff as non-intrusive as possible. Which means other
wd attachments than wd@pciide and wd@atapiscsi ought to be unaffected by
this change.

Please test this on x86 systems as well and let me know if it breaks
suspend/resume (or even regular operation).

Miod

Index: dev/ata/atavar.h
===
RCS file: /cvs/src/sys/dev/ata/atavar.h,v
retrieving revision 1.19
diff -u -p -r1.19 atavar.h
--- dev/ata/atavar.h23 Jul 2010 07:47:13 -  1.19
+++ dev/ata/atavar.h7 Apr 2011 20:09:22 -
@@ -164,7 +164,7 @@ void wdc_probe_caps(struct ata_drive_dat
 void wdc_print_caps(struct ata_drive_datas*);
 int  wdc_downgrade_mode(struct ata_drive_datas*);
 
-void wdc_reset_channel(struct ata_drive_datas *);
+void wdc_reset_channel(struct ata_drive_datas *, int);
 
 int wdc_ata_addref(struct ata_drive_datas *);
 void wdc_ata_delref(struct ata_drive_datas *);
Index: dev/ata/wd.c
===
RCS file: /cvs/src/sys/dev/ata/wd.c,v
retrieving revision 1.98
diff -u -p -r1.98 wd.c
--- dev/ata/wd.c5 Apr 2011 19:57:40 -   1.98
+++ dev/ata/wd.c7 Apr 2011 20:09:22 -
@@ -355,13 +355,14 @@ wdactivate(struct device *self, int act)
/*
 * Do two resets separated by a small delay. The
 * first wakes the controller, the second resets
-* the channel
+* the channel.
 */
wdc_disable_intr(wd->drvp->chnl_softc);
-   wdc_reset_channel(wd->drvp);
+   wdc_reset_channel(wd->drvp, 1);
delay(1);
-   wdc_reset_channel(wd->drvp);
+   wdc_reset_channel(wd->drvp, 0);
wdc_enable_intr(wd->drvp->chnl_softc);
+   wd_get_params(wd, at_poll, &wd->sc_params);
break;
}
return (rv);
@@ -582,7 +583,7 @@ wddone(void *v)
sizeof buf);
 retry:
/* Just reset and retry. Can we do more ? */
-   wdc_reset_channel(wd->drvp);
+   wdc_reset_channel(wd->drvp, 0);
diskerr(bp, "wd", errbuf, LOG_PRINTF,
wd->sc_wdc_bio.blkdone, wd->sc_dk.dk_label);
if (wd->retries++ < WDIORETRIES) {
Index: dev/atapiscsi/atapiscsi.c
===
RCS file: /cvs/src/sys/dev/atapiscsi/atapiscsi.c,v
retrieving revision 1.96
diff -u -p -r1.96 atapiscsi.c
--- dev/atapiscsi/atapiscsi.c   18 Nov 2010 21:13:19 -  1.96
+++ dev/atapiscsi/atapiscsi.c   7 Apr 2011 20:09:22 -
@@ -311,9 +311,9 @@ atapiscsi_activate(struct device *self, 
 * the channel
 */
wdc_disable_intr(chp);
-   wdc_reset_channel(drvp);
+   wdc_reset_channel(drvp, 1);
delay(1);
-   wdc_reset_channel(drvp);
+   wdc_reset_channel(drvp, 0);
wdc_enable_intr(chp);
break;
}
@@ -1626,7 +1626,7 @@ wdc_atapi_reset_2(chp, xfer, timeout, re
chp->wdc->sc_dev.dv_xname, chp->channel,
xfer->drive);
sc_xfer->error = XS_SELTIMEOUT;
-   wdc_reset_channel(drvp);
+   wdc_reset_channel(drvp, 0);
 
xfer->next = wdc_atapi_done;
return;
Index: dev/ic/wdc.c
===
RCS file: /cvs/src/sys/dev/ic/wdc.c,v
retrieving revision 1.111
diff -u -p -r1.111 wdc.c
--- dev/ic/wdc.c5 Apr 2011 19:57:40 -   1.111
+++ dev/ic/wdc.c7 Apr 2011 20:09:22 -
@@ -934,7 +934,7 @@ wdcintr(void *arg)
 
 /* Put all disk in RESET state */
 void
-wdc_reset_channel(struct ata_drive_datas *drvp)
+wdc_reset_channel(struct ata_drive_datas *drvp, int nowait)
 {
struct channel_softc *chp = drvp->chnl_softc;
int drive;
@@ -942,14 +942,14 @@ wdc_reset_channel(struct ata_drive_datas
WDCDEBUG_PRINT(("ata_reset_channel %s:%d for drive %d\n",
chp->wdc->sc_dev.dv_xname, chp->channel, drvp->drive),
DEBUG_FUNCS);
-   (void) wdcreset(chp, VERBOSE);
+   (void) wdcreset(chp, nowait ? NOWAIT : VERBOSE);
for (drive = 0

Re: fsck_ffs diff needs testing

[Amit Kulkarni]

Thanks! I understand.

On Thu, Apr 7, 2011 at 11:09 AM, Otto Moerbeek  wrote:
> On Thu, Apr 07, 2011 at 11:05:42AM -0500, Amit Kulkarni wrote:
>
>> >> Also, depending on the usage patterns, you might have a fs where high
>> >> numbered inodes are used, while the fs itself is pretty empty. Filling
>> >> up a fs with lots of files and them removing a lot of them is an
>> >> example that could lead to such a situation. This diff does not speed
>> >> things up in such cases.
>> >
>> > ...might have an impact in my case, since I often do things like
rebuilding
>> > the system including tons of packages on this machine, and that use case
of
>> > course perfectly matches what you say above. I think I'll remake these
file
>> > systems and run the test again just to satisfy my curiosity. But that'll
>> > have to wait until after dinner. :-)
>> >
>> > Anyway, I see improvements both in memory usage and in speed, and I see
no
>> > obvoius malfunctions, so I'd say it's a go.
>>
>>
>> Hi Otto,
>>
>> Comparing your diff with FreeBSD svn (not cvs, they dropped cvs! my
>> bad on the initial comment) after Benny pointed this out.
>>
>>
http://svn.freebsd.org/viewvc/base/head/sbin/fsck_ffs/pass1.c?revision=201708
&view=markup
>>
>> Look at this comment inside the file
>>
>> /*
>>* This optimization speeds up future runs of fsck
>>* by trimming down the number of inodes in cylinder
>>* groups that formerly had many inodes but now have
>>* fewer in use.
>>*/
>>
>> and the commit entry by McKusick for rev 188110
>>
>> "Update the actions previously attempted by the -D option to make them
>> robust. With these changes fsck is now able to detect and reliably
>> rebuild corrupted cylinder group maps. The -D option is no longer
>> necessary as it has been replaced by a prompt asking whether the
>> corrupted cylinder group should be rebuilt and doing so when requested.
>> These actions are only offered and taken when running fsck in manual
>> mode. Corrupted cylinder groups found during preen mode cause the fsck
>> to fail.
>>
>> Add the -r option to free up excess unused inodes. Decreasing the
>> number of preallocated inodes reduces the running time of future
>> runs of fsck and frees up space that can allocated to files. The -r
>> option is ignored when running in preen mode."
>> --
>>
>> Will you please please please integrate that part of the code too!!!
>> This is absolutely useful to have and is a fairly common situation. It
>> will make fsck better and be a good way to partially defrag your fs.
>>
>> Or did you plan to keep that for later after more testing on this diff?
>>
>> Thanks,
>> amit
>
> Yes, I go step by step.
>
>-Otto

ftp-proxy: use divert-to instead of rdr-to

[Mike Belopuhov]

this allows us to get rid of the nasty NATLOOKUP ioctl and get
the original server address right from the socket.  also this
paves the way to the transparent ftp-proxy mode.

if you will like this diff and nobody objects, i'll try to rip
NATLOOKUP out from the other places too.

note, that it requires you to change your rdr-to rule to do
divert:

 -pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port 8021
 +pass in quick proto tcp to port ftp divert-to 127.0.0.1 port 8021


Index: filter.c
===
RCS file: /home/cvs/src/usr.sbin/ftp-proxy/filter.c,v
retrieving revision 1.14
diff -u -p -r1.14 filter.c
--- filter.c25 Mar 2011 14:51:31 -  1.14
+++ filter.c7 Apr 2011 16:31:30 -
@@ -42,10 +42,6 @@
 int add_addr(struct sockaddr *, struct pf_pool *);
 int prepare_rule(u_int32_t, struct sockaddr *, struct sockaddr *,
 u_int16_t);
-int server_lookup4(struct sockaddr_in *, struct sockaddr_in *,
-struct sockaddr_in *, int *);
-int server_lookup6(struct sockaddr_in6 *, struct sockaddr_in6 *,
-struct sockaddr_in6 *, int *);
 
 static struct pfioc_rule   pfr;
 static struct pfioc_trans  pft;
@@ -252,82 +248,6 @@ prepare_rule(u_int32_t id, struct sockad
strlcpy(pfr.rule.tagname, tagname,
sizeof pfr.rule.tagname);
}
-
-   return (0);
-}
-
-int
-server_lookup(struct sockaddr *client, struct sockaddr *proxy,
-struct sockaddr *server, int *cdomain)
-{
-   if (client->sa_family == AF_INET)
-   return (server_lookup4(satosin(client), satosin(proxy),
-   satosin(server), cdomain));
-   
-   if (client->sa_family == AF_INET6)
-   return (server_lookup6(satosin6(client), satosin6(proxy),
-   satosin6(server), cdomain));
-
-   errno = EPROTONOSUPPORT;
-   return (-1);
-}
-
-int
-server_lookup4(struct sockaddr_in *client, struct sockaddr_in *proxy,
-struct sockaddr_in *server, int *cdomain)
-{
-   struct pfioc_natlook pnl;
-
-   memset(&pnl, 0, sizeof pnl);
-   pnl.direction = PF_OUT;
-   pnl.af = AF_INET;
-   pnl.proto = IPPROTO_TCP;
-   pnl.rdomain = getrtable();
-   memcpy(&pnl.saddr.v4, &client->sin_addr.s_addr, sizeof pnl.saddr.v4);
-   memcpy(&pnl.daddr.v4, &proxy->sin_addr.s_addr, sizeof pnl.daddr.v4);
-   pnl.sport = client->sin_port;
-   pnl.dport = proxy->sin_port;
-   
-   if (ioctl(dev, DIOCNATLOOK, &pnl) == -1)
-   return (-1);
-
-   memset(server, 0, sizeof(struct sockaddr_in));
-   server->sin_len = sizeof(struct sockaddr_in);
-   server->sin_family = AF_INET;
-   memcpy(&server->sin_addr.s_addr, &pnl.rdaddr.v4,
-   sizeof server->sin_addr.s_addr);
-   server->sin_port = pnl.rdport;
-   *cdomain = pnl.rrdomain;
-
-   return (0);
-}
-
-int
-server_lookup6(struct sockaddr_in6 *client, struct sockaddr_in6 *proxy,
-struct sockaddr_in6 *server, int *cdomain)
-{
-   struct pfioc_natlook pnl;
-
-   memset(&pnl, 0, sizeof pnl);
-   pnl.direction = PF_OUT;
-   pnl.af = AF_INET6;
-   pnl.proto = IPPROTO_TCP;
-   pnl.rdomain = getrtable();
-   memcpy(&pnl.saddr.v6, &client->sin6_addr.s6_addr, sizeof pnl.saddr.v6);
-   memcpy(&pnl.daddr.v6, &proxy->sin6_addr.s6_addr, sizeof pnl.daddr.v6);
-   pnl.sport = client->sin6_port;
-   pnl.dport = proxy->sin6_port;
-   
-   if (ioctl(dev, DIOCNATLOOK, &pnl) == -1)
-   return (-1);
-
-   memset(server, 0, sizeof(struct sockaddr_in6));
-   server->sin6_len = sizeof(struct sockaddr_in6);
-   server->sin6_family = AF_INET6;
-   memcpy(&server->sin6_addr.s6_addr, &pnl.rdaddr.v6,
-   sizeof server->sin6_addr);
-   server->sin6_port = pnl.rdport;
-   *cdomain = pnl.rrdomain;
 
return (0);
 }
Index: filter.h
===
RCS file: /home/cvs/src/usr.sbin/ftp-proxy/filter.h,v
retrieving revision 1.6
diff -u -p -r1.6 filter.h
--- filter.h25 Mar 2011 14:51:31 -  1.6
+++ filter.h7 Apr 2011 16:31:38 -
@@ -26,5 +26,3 @@ int do_commit(void);
 int do_rollback(void);
 void init_filter(char *, char *, int);
 int prepare_commit(u_int32_t);
-int server_lookup(struct sockaddr *, struct sockaddr *, struct sockaddr *,
-int *);
Index: ftp-proxy.8
===
RCS file: /home/cvs/src/usr.sbin/ftp-proxy/ftp-proxy.8,v
retrieving revision 1.14
diff -u -p -r1.14 ftp-proxy.8
--- ftp-proxy.8 21 Nov 2009 13:59:31 -  1.14
+++ ftp-proxy.8 7 Apr 2011 16:49:56 -
@@ -40,7 +40,7 @@
 is a proxy for the Internet File Transfer Protocol.
 FTP control connections should be redirected into the proxy using the
 .Xr pf 4
-.Ar rdr-to
+.Ar divert-to
 command, after which the proxy connects to the server on behalf of
 the client.
 .Pp
@@ -169,7 +169,7 

Re: bridge ip chsum handling

[Christiano F. Haesbaert]

On 3 April 2011 14:22, Henning Brauer  wrote:
> so we have to special case the bridge in teh stack because it doesn't
> behave wrt ip checksums (yes yes, all hail layer violations).
> so make the bridge behave by always peeking into the ip header, and
> not just when we have a kernel with pf compiled in (aka no change
> really) and apply the same cksum treatment as in ip_output. as a bonus
> this makes us use hardware checksumming where available.
>
> there is anoteh rspecial casing in pf that can also be killed by i
> already have too many pf Ms, thus -> later.
>
> needs heavy testing by bridge users.
>
> Index: net/if_bridge.c
> ===
> RCS file: /cvs/src/sys/net/if_bridge.c,v
> retrieving revision 1.188
> diff -u -p -r1.188 if_bridge.c
> --- net/if_bridge.c 4 Nov 2010 23:07:15 -   1.188
> +++ net/if_bridge.c 3 Apr 2011 16:56:22 -
> @@ -68,7 +68,6 @@
>
>  #ifdef IPSEC
>  #include 
> -
>  #include 
>  #endif
>
> @@ -148,10 +147,8 @@ intbridge_flushrule(struct bridge_ifli
>  intbridge_brlconf(struct bridge_softc *, struct ifbrlconf *);
>  u_int8_t bridge_filterrule(struct brl_head *, struct ether_header *,
> struct mbuf *);
> -#if NPF > 0
> -struct mbuf *bridge_filter(struct bridge_softc *, int, struct ifnet *,
> +struct mbuf *bridge_ip(struct bridge_softc *, int, struct ifnet *,
> struct ether_header *, struct mbuf *m);
> -#endif
>  intbridge_ifenqueue(struct bridge_softc *, struct ifnet *, struct mbuf
*);
>  void   bridge_fragment(struct bridge_softc *, struct ifnet *,
> struct ether_header *, struct mbuf *);
> @@ -1065,9 +1062,8 @@ bridge_output(struct ifnet *ifp, struct
>}
>  #endif /* IPSEC */
>
> -   /* Catch packets that need TCP/UDP/IP hardware checksumming
*/
> -   if (m->m_pkthdr.csum_flags & M_IPV4_CSUM_OUT ||
> -   m->m_pkthdr.csum_flags & M_TCPV4_CSUM_OUT ||
> +   /* Catch packets that need TCP/UDP hardware checksumming */
> +   if (m->m_pkthdr.csum_flags & M_TCPV4_CSUM_OUT ||
>m->m_pkthdr.csum_flags & M_UDPV4_CSUM_OUT) {
>m_freem(m);
>splx(s);
> @@ -1308,11 +1304,9 @@ bridgeintr_frame(struct bridge_softc *sc
>m_freem(m);
>return;
>}
> -#if NPF > 0
> -   m = bridge_filter(sc, BRIDGE_IN, src_if, &eh, m);
> +   m = bridge_ip(sc, BRIDGE_IN, src_if, &eh, m);
>if (m == NULL)
>return;
> -#endif
>/*
> * If the packet is a multicast or broadcast OR if we don't
> * know any better, forward it to all interfaces.
> @@ -1350,11 +1344,9 @@ bridgeintr_frame(struct bridge_softc *sc
>m_freem(m);
>return;
>}
> -#if NPF > 0
> -   m = bridge_filter(sc, BRIDGE_OUT, dst_if, &eh, m);
> +   m = bridge_ip(sc, BRIDGE_OUT, dst_if, &eh, m);
>if (m == NULL)
>return;
> -#endif
>
>len = m->m_pkthdr.len;
>  #if NVLAN > 0
> @@ -1656,11 +1648,9 @@ bridge_broadcast(struct bridge_softc *sc
>mc = m1;
>}
>
> -#if NPF > 0
> -   mc = bridge_filter(sc, BRIDGE_OUT, dst_if, eh, mc);
> +   mc = bridge_ip(sc, BRIDGE_OUT, dst_if, eh, mc);
>if (mc == NULL)
>continue;
> -#endif
>
>len = mc->m_pkthdr.len;
>  #if NVLAN > 0
> @@ -2506,7 +2496,6 @@ bridge_ipsec(struct bridge_softc *sc, st
>  }
>  #endif /* IPSEC */
>
> -#if NPF > 0
>  /*
>  * Filter IP packets by peeking into the ethernet frame.  This violates
>  * the ISO model, but allows us to act as a IP filter at the data link
> @@ -2514,7 +2503,7 @@ bridge_ipsec(struct bridge_softc *sc, st
>  * who've read net/if_ethersubr.c and netinet/ip_input.c
>  */
>  struct mbuf *
> -bridge_filter(struct bridge_softc *sc, int dir, struct ifnet *ifp,
> +bridge_ip(struct bridge_softc *sc, int dir, struct ifnet *ifp,
> struct ether_header *eh, struct mbuf *m)
>  {
>struct llc llc;
> @@ -2590,9 +2579,20 @@ bridge_filter(struct bridge_softc *sc, i
>ip = mtod(m, struct ip *);
>}
>
> -   if ((ip->ip_sum = in_cksum(m, hlen)) != 0) {
> -   ipstat.ips_badsum++;
> -   goto dropit;
> +   if ((m->m_pkthdr.csum_flags & M_IPV4_CSUM_IN_OK) == 0) {
> +   if (m->m_pkthdr.csum_flags & M_IPV4_CSUM_IN_BAD) {
> +   ipstat.ips_inhwcsum++;
> +   ipstat.ips_badsum++;
> +   goto dropit;
> +   }
> +
> +   if (in_cksum(m, hlen) != 0) {
> +   ipstat.ips_badsum++;
> +   goto dropit;
> +   }
> +   } else {
> +   m->m

Re: fsck_ffs diff needs testing

[Amit Kulkarni]

>> Also, depending on the usage patterns, you might have a fs where high
>> numbered inodes are used, while the fs itself is pretty empty. Filling
>> up a fs with lots of files and them removing a lot of them is an
>> example that could lead to such a situation. This diff does not speed
>> things up in such cases.
>
> ...might have an impact in my case, since I often do things like rebuilding
> the system including tons of packages on this machine, and that use case of
> course perfectly matches what you say above. I think I'll remake these file
> systems and run the test again just to satisfy my curiosity. But that'll
> have to wait until after dinner. :-)
>
> Anyway, I see improvements both in memory usage and in speed, and I see no
> obvoius malfunctions, so I'd say it's a go.


Hi Otto,

Comparing your diff with FreeBSD svn (not cvs, they dropped cvs! my
bad on the initial comment) after Benny pointed this out.

http://svn.freebsd.org/viewvc/base/head/sbin/fsck_ffs/pass1.c?revision=201708&view=markup

Look at this comment inside the file

/*
 * This optimization speeds up future runs of fsck
 * by trimming down the number of inodes in cylinder
 * groups that formerly had many inodes but now have
 * fewer in use.
 */

and the commit entry by McKusick for rev 188110

"Update the actions previously attempted by the -D option to make them
robust. With these changes fsck is now able to detect and reliably
rebuild corrupted cylinder group maps. The -D option is no longer
necessary as it has been replaced by a prompt asking whether the
corrupted cylinder group should be rebuilt and doing so when requested.
These actions are only offered and taken when running fsck in manual
mode. Corrupted cylinder groups found during preen mode cause the fsck
to fail.

Add the -r option to free up excess unused inodes. Decreasing the
number of preallocated inodes reduces the running time of future
runs of fsck and frees up space that can allocated to files. The -r
option is ignored when running in preen mode."
--

Will you please please please integrate that part of the code too!!!
This is absolutely useful to have and is a fairly common situation. It
will make fsck better and be a good way to partially defrag your fs.

Or did you plan to keep that for later after more testing on this diff?

Thanks,
amit

dhclient(8) vs classful static routes

[Kenneth R Westerback]

Classful routing is no longer widely used. Our current support
for DHCP option 33 (DHO_STATIC_ROUTES) does not treat the provided
information as classful routes but as host routes.

Is this deliberate or accidental on our part?

If accidental I would recommend the diff below, removing the handling
of this option, and then looking into providing support for option
121 (classless static routes). Rather than fixing classful routes.

Thoughts?

 Ken

Index: dhclient-script
===
RCS file: /cvs/src/sbin/dhclient/dhclient-script,v
retrieving revision 1.21
diff -u -p -r1.21 dhclient-script
--- dhclient-script 4 Apr 2011 12:22:41 -   1.21
+++ dhclient-script 7 Apr 2011 16:01:36 -
@@ -54,15 +54,6 @@ delete_old_routes() {
# Delete existing default route. We only allow one, so no need to
# process $old_routers list.
route -q $rdomain -n flush -inet -iface $interface
-
-   if [ -n "$old_static_routes" ]; then
-   set $old_static_routes
-   while [ $# -gt 1 ]; do
-   route -q $rdomain delete "$1" "$2"
-   shift; shift
-   done
-   fi
-
arp -dan
 }
 
@@ -78,14 +69,6 @@ add_new_routes() {
# stop processing the list after the first one.
break
done
-
-   if [ -n "$new_static_routes" ]; then
-   set $new_static_routes
-   while [ $# -gt 1 ]; do
-   route -q $rdomain add $1 $2
-   shift; shift
-   done
-   fi
 }
 
 add_new_resolv_conf() {

Re: fsck_ffs diff needs testing

[Otto Moerbeek]

On Thu, Apr 07, 2011 at 11:05:42AM -0500, Amit Kulkarni wrote:

> >> Also, depending on the usage patterns, you might have a fs where high
> >> numbered inodes are used, while the fs itself is pretty empty. Filling
> >> up a fs with lots of files and them removing a lot of them is an
> >> example that could lead to such a situation. This diff does not speed
> >> things up in such cases.
> >
> > ...might have an impact in my case, since I often do things like rebuilding
> > the system including tons of packages on this machine, and that use case of
> > course perfectly matches what you say above. I think I'll remake these file
> > systems and run the test again just to satisfy my curiosity. But that'll
> > have to wait until after dinner. :-)
> >
> > Anyway, I see improvements both in memory usage and in speed, and I see no
> > obvoius malfunctions, so I'd say it's a go.
> 
> 
> Hi Otto,
> 
> Comparing your diff with FreeBSD svn (not cvs, they dropped cvs! my
> bad on the initial comment) after Benny pointed this out.
> 
> http://svn.freebsd.org/viewvc/base/head/sbin/fsck_ffs/pass1.c?revision=201708&view=markup
> 
> Look at this comment inside the file
> 
> /*
>* This optimization speeds up future runs of fsck
>* by trimming down the number of inodes in cylinder
>* groups that formerly had many inodes but now have
>* fewer in use.
>*/
> 
> and the commit entry by McKusick for rev 188110
> 
> "Update the actions previously attempted by the -D option to make them
> robust. With these changes fsck is now able to detect and reliably
> rebuild corrupted cylinder group maps. The -D option is no longer
> necessary as it has been replaced by a prompt asking whether the
> corrupted cylinder group should be rebuilt and doing so when requested.
> These actions are only offered and taken when running fsck in manual
> mode. Corrupted cylinder groups found during preen mode cause the fsck
> to fail.
> 
> Add the -r option to free up excess unused inodes. Decreasing the
> number of preallocated inodes reduces the running time of future
> runs of fsck and frees up space that can allocated to files. The -r
> option is ignored when running in preen mode."
> --
> 
> Will you please please please integrate that part of the code too!!!
> This is absolutely useful to have and is a fairly common situation. It
> will make fsck better and be a good way to partially defrag your fs.
> 
> Or did you plan to keep that for later after more testing on this diff?
> 
> Thanks,
> amit

Yes, I go step by step.

-Otto

interleaved+mirrored ccd bugfix

[Miod Vallat]

Revision 1.58 of ccd.c (a mere six years ago...) introduced an
unintialized variable usage, in the case of an interleaved and mirrored
ccd; read access could favor the mirror instead of the main ccd by
incorrectly considering the main ccd is in the failure state.

The following diff ought to fix this.

Index: dev/ccd.c
===
RCS file: /cvs/src/sys/dev/ccd.c,v
retrieving revision 1.92
diff -u -p -r1.92 ccd.c
--- dev/ccd.c   22 Sep 2010 01:18:57 -  1.92
+++ dev/ccd.c   7 Apr 2011 15:32:52 -
@@ -795,6 +795,7 @@ ccdbuffer(struct ccd_softc *cs, struct b
ccdisk = ii->ii_index[off % ii->ii_ndisk];
cbn = ii->ii_startoff + off / ii->ii_ndisk;
}
+   ci = &cs->sc_cinfo[ccdisk];
if (cs->sc_cflags & CCDF_MIRROR) {
/* Mirrored data */
ccdisk2 = ccdisk + ii->ii_ndisk;
@@ -803,11 +804,12 @@ ccdbuffer(struct ccd_softc *cs, struct b
if (bp->b_flags & B_READ &&
bcount > bp->b_bcount / 2 &&
(!(ci2->ci_flags & CCIF_FAILED) ||
- ci->ci_flags & CCIF_FAILED))
+ ci->ci_flags & CCIF_FAILED)) {
ccdisk = ccdisk2;
+   ci = ci2;
+   }
}
cbn *= cs->sc_ileave;
-   ci = &cs->sc_cinfo[ccdisk];
CCD_DPRINTF(CCDB_IO, ("ccdisk %d cbn %lld ci %p ci2 %p\n",
ccdisk, cbn, ci, ci2));
}

Re: fsck_ffs diff needs testing

[Benny Lofgren]

On 2011-04-07 17.19, Otto Moerbeek wrote:
> softdep does not change the layout. But only filesystems which were
> mounted with softdep get this optimization. There's a flag in teh
> superblock to signal that. Filesystem mounted with softdep have better
> guarantees about the cylinder group headers being consistent. 

Ah, right. But then I don't really understand why I didn't get more
oomph out of the patch. There's obviously some difference, since I could
see the memory usage drop significantly.

Or wait, I suddenly realized that what you wrote in an earlier mail, here:

> Also, depending on the usage patterns, you might have a fs where high
> numbered inodes are used, while the fs itself is pretty empty. Filling
> up a fs with lots of files and them removing a lot of them is an
> example that could lead to such a situation. This diff does not speed
> things up in such cases.

...might have an impact in my case, since I often do things like rebuilding
the system including tons of packages on this machine, and that use case of
course perfectly matches what you say above. I think I'll remake these file
systems and run the test again just to satisfy my curiosity. But that'll
have to wait until after dinner. :-)

Anyway, I see improvements both in memory usage and in speed, and I see no
obvoius malfunctions, so I'd say it's a go.


Regards,
/Benny


>> And yes, they were all ffs1 filesystems. I have a 13 TB ffs2 file system on
>> that machine as well, didn't try that now because I wanted to fire off a
>> quick reply to your request for testing, and also you mentioned that ffs2
>> is less (if at all) affected by this patch. I'll be glad to run a test
>> against
>> that volume as well, if you think there's an interest. Expect about 50
>> minutes
>> a run for one pass with the old and one pass with the new code though. :-)
>>
 Unpatched, run with time /sbin/fsck_ffs -pf /dev/rraid0[adefghi]:
>>> [snip]
 1m20.35s real 0m2.57s user 0m4.29s system

 Patched, run with time /root/fsck_ffs -pf /dev/rraid0[adefghi]:

>>> [snip]
 1m18.52s real 0m1.32s user 0m3.85s system

 The file systems are organized like this:

 skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0a
 # newfs command for /dev/rraid0a
 newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
 525856 /dev/rraid0a
 skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0d
 # newfs command for /dev/rraid0d
 newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
 4197120 /dev/rraid0d
 skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0e
 # newfs command for /dev/rraid0e
 newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
 8390400 /dev/rraid0e
 skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0f
 # newfs command for /dev/rraid0f
 newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
 16780800 /dev/rraid0f
 skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0g
 # newfs command for /dev/rraid0g
 newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
 41944320 /dev/rraid0g
 skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0h
 # newfs command for /dev/rraid0h
 newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
 12583680 /dev/rraid0h
 skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0i
 # newfs command for /dev/rraid0i
 newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
 7857920 /dev/rraid0i
 skynet:~/fsck_ffs_patch#
 Btw, I noticed a small change in this diff compared to the one you posted
 in the previous discussion thread. I assume this is the correct one to use?
>>>
>>> Yes, though that's the most recent version.
>>>
>>> -Otto

 skynet:~# diff fsck_ffs.patch fsck_ffs_2.patch
 158c158
 < +++ inode.c   31 Mar 2011 16:34:27 -
 ---
> +++ inode.c   4 Apr 2011 09:16:36 -
 203c203
 < + info[i].ino_state = USTATE;
 ---
> + SET_ISTATE(i, USTATE);

-- 
internetlabbet.se / work:   +46 8 551 124 80  / "Words must
Benny Lvfgren/  mobile: +46 70 718 11 90 /   be weighed,
/   fax:+46 8 551 124 89/not counted."
   /email:  benny -at- internetlabbet.se

Re: fsck_ffs diff needs testing

[Otto Moerbeek]

On Thu, Apr 07, 2011 at 04:28:25PM +0200, Benny Lofgren wrote:

> On 2011-04-07 15.06, Otto Moerbeek wrote:
> > On Thu, Apr 07, 2011 at 02:34:27PM +0200, Benny Lofgren wrote:
> > 
> >> On 2011-04-07 11.08, Otto Moerbeek wrote:
> >>> Hi,
> >>>
> >>> I got little feedeback on this diff posed in a rather long thread, so
> >>> I am posting it again.
> >>>
> >>> Please test this, it makes fsck_ffs much faster (especially with -p)
> >>> and less memory hungry in a lot of cases.
> >>
> >> I've run it on a variety of file systems now and first of all, it seems
> >> to work without regressions. It also looks like it has about 2/3 of its
> >> previous memory footprint. However, I see very little increase in speed:
> > 
> > Were your filesystems mounted with softdep? Also, the most gain is
> > realized with ffs1 filesystems.
> 
> Apart from the / file system they had been mounted with softdep, yes.
> However they were of course unmounted when I ran fsck_ffs.
> 
> Does softdep actually alter the physical file system structure on disk? I
> have always been under the impression that softdep affects stuff like how
> things are buffered and the order of which things are written to disk rather
> than *what* is written, am I mistaken?

softdep does not change the layout. But only filesystems which were
mounted with softdep get this optimization. There's a flag in teh
superblock to signal that. Filesystem mounted with softdep have better
guarantees about the cylinder group headers being consistent. 

-Otto


> And yes, they were all ffs1 filesystems. I have a 13 TB ffs2 file system on
> that machine as well, didn't try that now because I wanted to fire off a
> quick reply to your request for testing, and also you mentioned that ffs2
> is less (if at all) affected by this patch. I'll be glad to run a test
> against
> that volume as well, if you think there's an interest. Expect about 50
> minutes
> a run for one pass with the old and one pass with the new code though. :-)
> 
> 
> Regards,
> /Benny
> 
> 
> >> Unpatched, run with time /sbin/fsck_ffs -pf /dev/rraid0[adefghi]:
> > [snip]
> >> 1m20.35s real 0m2.57s user 0m4.29s system
> >>
> >> Patched, run with time /root/fsck_ffs -pf /dev/rraid0[adefghi]:
> >>
> > [snip]
> >> 1m18.52s real 0m1.32s user 0m3.85s system
> >>
> >> The file systems are organized like this:
> >>
> >> skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0a
> >> # newfs command for /dev/rraid0a
> >> newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
> >> 525856 /dev/rraid0a
> >> skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0d
> >> # newfs command for /dev/rraid0d
> >> newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
> >> 4197120 /dev/rraid0d
> >> skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0e
> >> # newfs command for /dev/rraid0e
> >> newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
> >> 8390400 /dev/rraid0e
> >> skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0f
> >> # newfs command for /dev/rraid0f
> >> newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
> >> 16780800 /dev/rraid0f
> >> skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0g
> >> # newfs command for /dev/rraid0g
> >> newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
> >> 41944320 /dev/rraid0g
> >> skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0h
> >> # newfs command for /dev/rraid0h
> >> newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
> >> 12583680 /dev/rraid0h
> >> skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0i
> >> # newfs command for /dev/rraid0i
> >> newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
> >> 7857920 /dev/rraid0i
> >> skynet:~/fsck_ffs_patch#
> >> Btw, I noticed a small change in this diff compared to the one you posted
> >> in the previous discussion thread. I assume this is the correct one to use?
> > 
> > Yes, though that's the most recent version.
> > 
> > -Otto
> >>
> >> skynet:~# diff fsck_ffs.patch fsck_ffs_2.patch
> >> 158c158
> >> < +++ inode.c   31 Mar 2011 16:34:27 -
> >> ---
> >>> +++ inode.c   4 Apr 2011 09:16:36 -
> >> 203c203
> >> < + info[i].ino_state = USTATE;
> >> ---
> >>> + SET_ISTATE(i, USTATE);
> >>
> >>
> >> Regards,
> >>
> >> /Benny
> > 
> 
> -- 
> internetlabbet.se / work:   +46 8 551 124 80  / "Words must
> Benny L?fgren/  mobile: +46 70 718 11 90 /   be weighed,
> /   fax:+46 8 551 124 89/not counted."
>/email:  benny -at- internetlabbet.se

Re: [PATCH] Bypass routing table for mcast packets when using IP_MULTICAST_IF

[Christiano F. Haesbaert]

Keeping this up.

On 17 March 2011 00:51, Christiano F. Haesbaert 
wrote:
> On 12 June 2010 16:26, Christiano F. Haesbaert 
wrote:
>> Hi,
>>
>> The following will disregard the routing table for multicast packets
>> when the application chose the interface with IP_MULTICAST_IF, if not,
>> normal lookup will take place.
>>
>> Ripd now no longer needs to explicitly add the mcast host route to
>> bypass the default reject to 224/4, follows the diff to remove it.
>>
>> Regarding the normal lookup when IP_MULTICAST_IF wan't set, UNP
>> regards it as a BSD descendant behaviour, I really don't know anything
>> else.
>>
>> I've tested it in a small setup, if someone could confirm it in a
>> scarier environment would be nice.
>>
>> Index: netinet/in_pcb.c
>> ===
>> RCS file: /cvs/src/sys/netinet/in_pcb.c,v
>> retrieving revision 1.112
>> diff -d -u -p -w netinet/in_pcb.c
>> --- netinet/in_pcb.c7 May 2010 13:33:16 -   1.112
>> +++ netinet/in_pcb.c12 Jun 2010 19:18:49 -
>> @@ -819,7 +819,9 @@ in_selectsrc(struct sockaddr_in *sin, struct route *ro
>>}
>>if ((soopts & SO_DONTROUTE) == 0 && /*XXX*/
>>(ro->ro_rt == (struct rtentry *)0 ||
>> -   ro->ro_rt->rt_ifp == (struct ifnet *)0)) {
>> +   ro->ro_rt->rt_ifp == (struct ifnet *)0) &&
>> +   !(IN_MULTICAST(sin->sin_addr.s_addr) &&
>> +   mopts && (mopts->imo_multicast_ifp != NULL))) {
>>/* No route yet, so try to acquire one */
>>ro->ro_dst.sa_family = AF_INET;
>>ro->ro_dst.sa_len = sizeof(struct sockaddr_in);
>>
>>
>> Index: kroute.c
>> ===
>> RCS file: /cvs/src/usr.sbin/ripd/kroute.c,v
>> retrieving revision 1.21
>> diff -d -u -p -w kroute.c
>> --- kroute.c2 Jan 2009 14:40:54 -   1.21
>> +++ kroute.c12 Jun 2010 19:19:51 -
>> @@ -97,9 +97,6 @@ RB_HEAD(kif_tree, kif_node)   kit;
>>  RB_PROTOTYPE(kif_tree, kif_node, entry, kif_compare)
>>  RB_GENERATE(kif_tree, kif_node, entry, kif_compare)
>>
>> -struct kroute kr_all_rip_routers;
>> -intflag_all_rip_routers = 0;
>> -
>>  int
>>  kif_init(void)
>>  {
>> @@ -151,14 +148,6 @@ kr_init(int fs, u_int rdomain)
>>if (protect_lo() == -1)
>>return (-1);
>>
>> -   kr_all_rip_routers.prefix.s_addr = inet_addr(ALL_RIP_ROUTERS);
>> -   kr_all_rip_routers.netmask.s_addr = htonl(INADDR_BROADCAST);
>> -   kr_all_rip_routers.nexthop.s_addr = htonl(INADDR_LOOPBACK);
>> -
>> -   kr_state.fib_sync = 1; /* force addition of multicast route */
>> -   if (send_rtmsg(kr_state.fd, RTM_ADD, &kr_all_rip_routers) != -1)
>> -   flag_all_rip_routers = 1;
>> -
>>kr_state.fib_sync = fs; /* now set correct sync mode */
>>kr_state.rdomain = rdomain;
>>
>> @@ -243,11 +232,6 @@ void
>>  kr_shutdown(void)
>>  {
>>kr_fib_decouple();
>> -
>> -   if (flag_all_rip_routers) {
>> -   kr_state.fib_sync = 1; /* force removal of mulitcast route
*/
>> -   (void)send_rtmsg(kr_state.fd, RTM_DELETE,
&kr_all_rip_routers);
>> -   }
>>
>>kroute_clear();
>>kif_clear();
>>
>
> Wow I had completely forgotten about this, I'm using this diff since
> then, any comments ?
>
> Thanks

Re: fsck_ffs diff needs testing

[Benny Lofgren]

On 2011-04-07 15.06, Otto Moerbeek wrote:
> On Thu, Apr 07, 2011 at 02:34:27PM +0200, Benny Lofgren wrote:
> 
>> On 2011-04-07 11.08, Otto Moerbeek wrote:
>>> Hi,
>>>
>>> I got little feedeback on this diff posed in a rather long thread, so
>>> I am posting it again.
>>>
>>> Please test this, it makes fsck_ffs much faster (especially with -p)
>>> and less memory hungry in a lot of cases.
>>
>> I've run it on a variety of file systems now and first of all, it seems
>> to work without regressions. It also looks like it has about 2/3 of its
>> previous memory footprint. However, I see very little increase in speed:
> 
> Were your filesystems mounted with softdep? Also, the most gain is
> realized with ffs1 filesystems.

Apart from the / file system they had been mounted with softdep, yes.
However they were of course unmounted when I ran fsck_ffs.

Does softdep actually alter the physical file system structure on disk? I
have always been under the impression that softdep affects stuff like how
things are buffered and the order of which things are written to disk rather
than *what* is written, am I mistaken?

And yes, they were all ffs1 filesystems. I have a 13 TB ffs2 file system on
that machine as well, didn't try that now because I wanted to fire off a
quick reply to your request for testing, and also you mentioned that ffs2
is less (if at all) affected by this patch. I'll be glad to run a test
against
that volume as well, if you think there's an interest. Expect about 50
minutes
a run for one pass with the old and one pass with the new code though. :-)


Regards,
/Benny


>> Unpatched, run with time /sbin/fsck_ffs -pf /dev/rraid0[adefghi]:
> [snip]
>> 1m20.35s real 0m2.57s user 0m4.29s system
>>
>> Patched, run with time /root/fsck_ffs -pf /dev/rraid0[adefghi]:
>>
> [snip]
>> 1m18.52s real 0m1.32s user 0m3.85s system
>>
>> The file systems are organized like this:
>>
>> skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0a
>> # newfs command for /dev/rraid0a
>> newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
>> 525856 /dev/rraid0a
>> skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0d
>> # newfs command for /dev/rraid0d
>> newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
>> 4197120 /dev/rraid0d
>> skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0e
>> # newfs command for /dev/rraid0e
>> newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
>> 8390400 /dev/rraid0e
>> skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0f
>> # newfs command for /dev/rraid0f
>> newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
>> 16780800 /dev/rraid0f
>> skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0g
>> # newfs command for /dev/rraid0g
>> newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
>> 41944320 /dev/rraid0g
>> skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0h
>> # newfs command for /dev/rraid0h
>> newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
>> 12583680 /dev/rraid0h
>> skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0i
>> # newfs command for /dev/rraid0i
>> newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
>> 7857920 /dev/rraid0i
>> skynet:~/fsck_ffs_patch#
>> Btw, I noticed a small change in this diff compared to the one you posted
>> in the previous discussion thread. I assume this is the correct one to use?
> 
> Yes, though that's the most recent version.
> 
>   -Otto
>>
>> skynet:~# diff fsck_ffs.patch fsck_ffs_2.patch
>> 158c158
>> < +++ inode.c   31 Mar 2011 16:34:27 -
>> ---
>>> +++ inode.c   4 Apr 2011 09:16:36 -
>> 203c203
>> < + info[i].ino_state = USTATE;
>> ---
>>> + SET_ISTATE(i, USTATE);
>>
>>
>> Regards,
>>
>> /Benny
> 

-- 
internetlabbet.se / work:   +46 8 551 124 80  / "Words must
Benny Lvfgren/  mobile: +46 70 718 11 90 /   be weighed,
/   fax:+46 8 551 124 89/not counted."
   /email:  benny -at- internetlabbet.se

gdt(4) iopoolification - test now or forever hold your peace

[Kenneth R Westerback]

As with cac(4). You can test now or can break later.

 Ken

Index: ic/gdt_common.c
===
RCS file: /cvs/src/sys/dev/ic/gdt_common.c,v
retrieving revision 1.55
diff -u -p -r1.55 gdt_common.c
--- ic/gdt_common.c 12 Oct 2010 00:53:32 -  1.55
+++ ic/gdt_common.c 13 Oct 2010 11:09:09 -
@@ -61,16 +61,12 @@ int gdt_maxcmds = GDT_MAXCMDS;
 #define GDT_DRIVER_SUBVERSION 2
 
 intgdt_async_event(struct gdt_softc *, int);
-void   gdt_chain(struct gdt_softc *);
 void   gdt_clear_events(struct gdt_softc *);
 void   gdt_copy_internal_data(struct scsi_xfer *, u_int8_t *, size_t);
-struct scsi_xfer *gdt_dequeue(struct gdt_softc *);
-void   gdt_enqueue(struct gdt_softc *, struct scsi_xfer *, int);
-void   gdt_enqueue_ccb(struct gdt_softc *, struct gdt_ccb *);
 void   gdt_eval_mapping(u_int32_t, int *, int *, int *);
 intgdt_exec_ccb(struct gdt_ccb *);
-void   gdt_free_ccb(struct gdt_softc *, struct gdt_ccb *);
-struct gdt_ccb *gdt_get_ccb(struct gdt_softc *, int);
+void   gdt_ccb_free(void *, void *);
+void   *gdt_ccb_alloc(void *);
 void   gdt_internal_cache_cmd(struct scsi_xfer *);
 intgdt_internal_cmd(struct gdt_softc *, u_int8_t, u_int16_t,
 u_int32_t, u_int32_t, u_int32_t);
@@ -82,9 +78,7 @@ int   gdt_ioctl_disk(struct gdt_softc *, s
 intgdt_ioctl_alarm(struct gdt_softc *, struct bioc_alarm *);
 intgdt_ioctl_setstate(struct gdt_softc *, struct bioc_setstate *);
 #endif /* NBIO > 0 */
-void   gdt_raw_scsi_cmd(struct scsi_xfer *);
 void   gdt_scsi_cmd(struct scsi_xfer *);
-void   gdt_start_ccbs(struct gdt_softc *);
 intgdt_sync_event(struct gdt_softc *, int, u_int8_t,
 struct scsi_xfer *);
 void   gdt_timeout(void *);
@@ -99,10 +93,6 @@ struct scsi_adapter gdt_switch = {
gdt_scsi_cmd, gdtminphys, 0, 0,
 };
 
-struct scsi_adapter gdt_raw_switch = {
-   gdt_raw_scsi_cmd, gdtminphys, 0, 0,
-};
-
 int gdt_cnt = 0;
 u_int8_t gdt_polling;
 u_int8_t gdt_from_wait;
@@ -132,9 +122,8 @@ gdt_attach(struct gdt_softc *sc)
gdt_clear_events(sc);
 
TAILQ_INIT(&sc->sc_free_ccb);
-   TAILQ_INIT(&sc->sc_ccbq);
-   TAILQ_INIT(&sc->sc_ucmdq);
-   LIST_INIT(&sc->sc_queue);
+   mtx_init(&sc->sc_ccb_mtx, IPL_BIO);
+   scsi_iopool_init(&sc->sc_iopool, sc, gdt_ccb_alloc, gdt_ccb_free);
 
/* Initialize the ccbs */
for (i = 0; i < GDT_MAXCMDS; i++) {
@@ -484,26 +473,6 @@ gdt_attach(struct gdt_softc *sc)
 
config_found(&sc->sc_dev, &saa, scsiprint);
 
-   sc->sc_raw_link = malloc(sc->sc_bus_cnt * sizeof (struct scsi_link),
-   M_DEVBUF, M_NOWAIT | M_ZERO);
-   if (sc->sc_raw_link == NULL)
-   panic("gdt_attach");
-
-   for (i = 0; i < sc->sc_bus_cnt; i++) {
-   /* Fill in the prototype scsi_link. */
-   sc->sc_raw_link[i].adapter_softc = sc;
-   sc->sc_raw_link[i].adapter = &gdt_raw_switch;
-   sc->sc_raw_link[i].adapter_target = 7;
-   sc->sc_raw_link[i].openings = 4;/* XXX a guess */
-   sc->sc_raw_link[i].adapter_buswidth =
-   (sc->sc_class & GDT_FC) ? GDT_MAXID : 16;   /* XXX */
-
-   bzero(&saa, sizeof(saa));
-   saa.saa_sc_link = &sc->sc_raw_link[i];
-
-   config_found(&sc->sc_dev, &saa, scsiprint);
-   }
-
gdt_polling = 0;
return (0);
 }
@@ -531,43 +500,6 @@ gdt_eval_mapping(u_int32_t size, int *cy
 }
 
 /*
- * Insert a command into the driver queue, either at the front or at the tail.
- * It's ok to overload the freelist link as these structures are never on
- * the freelist at this time.
- */
-void
-gdt_enqueue(struct gdt_softc *sc, struct scsi_xfer *xs, int infront)
-{
-   if (infront || LIST_FIRST(&sc->sc_queue) == NULL) {
-   if (LIST_FIRST(&sc->sc_queue) == NULL)
-   sc->sc_queuelast = xs;
-   LIST_INSERT_HEAD(&sc->sc_queue, xs, free_list);
-   return;
-   }
-   LIST_INSERT_AFTER(sc->sc_queuelast, xs, free_list);
-   sc->sc_queuelast = xs;
-}
-
-/*
- * Pull a command off the front of the driver queue.
- */
-struct scsi_xfer *
-gdt_dequeue(struct gdt_softc *sc)
-{
-   struct scsi_xfer *xs;
-
-   xs = LIST_FIRST(&sc->sc_queue);
-   if (xs == NULL)
-   return (NULL);
-   LIST_REMOVE(xs, free_list);
-
-   if (LIST_FIRST(&sc->sc_queue) == NULL)
-   sc->sc_queuelast = NULL;
-
-   return (xs);
-}
-
-/*
  * Start a SCSI operation on a cache device.
  * XXX Polled operation is not yet complete.  What kind of locking do we need?
  */
@@ -576,18 +508,13 @@ gdt_scsi_cmd(struct scsi_xfer *xs)
 {
struct scsi_link *link = xs->sc_link;
struct gdt_softc *sc = link->adapter_softc;
-   u_int8_t target = link->target;
struct gdt_ccb *ccb;
-#if 0
-   struct gdt_ucmd *ucmd;
-#endif
-   u_int32_t blockno, blockcnt;
struct scsi_rw 

cac(4) iopoolification - test now or forever hold your peace

[Kenneth R Westerback]

This has been posted a few times with no feedback I can remember. This is
a last chance to test before you become involuntary testers! It will be
committed very soon, with c2k11 on the horizon to deal with any fallout.

 Ken


Index: ic/cac.c
===
RCS file: /cvs/src/sys/dev/ic/cac.c,v
retrieving revision 1.42
diff -u -p -r1.42 cac.c
--- ic/cac.c12 Oct 2010 00:53:32 -  1.42
+++ ic/cac.c13 Oct 2010 11:09:09 -
@@ -103,9 +103,9 @@ struct scsi_adapter cac_switch = {
cac_scsi_cmd, cacminphys, 0, 0,
 };
 
-struct cac_ccb *cac_ccb_alloc(struct cac_softc *, int);
+void   *cac_ccb_alloc(void *);
 void   cac_ccb_done(struct cac_softc *, struct cac_ccb *);
-void   cac_ccb_free(struct cac_softc *, struct cac_ccb *);
+void   cac_ccb_free(void *, void *);
 intcac_ccb_poll(struct cac_softc *, struct cac_ccb *, int);
 intcac_ccb_start(struct cac_softc *, struct cac_ccb *);
 intcac_cmd(struct cac_softc *sc, int command, void *data, int datasize,
@@ -156,6 +156,8 @@ cac_init(struct cac_softc *sc, int start
 
SIMPLEQ_INIT(&sc->sc_ccb_free);
SIMPLEQ_INIT(&sc->sc_ccb_queue);
+   mtx_init(&sc->sc_ccb_mtx, IPL_BIO);
+   scsi_iopool_init(&sc->sc_iopool, sc, cac_ccb_alloc, cac_ccb_free);
 
 size = sizeof(struct cac_ccb) * CAC_MAX_CCBS;
 
@@ -204,7 +206,9 @@ cac_init(struct cac_softc *sc, int start
}
 
ccb->ccb_paddr = sc->sc_ccbs_paddr + i * sizeof(struct cac_ccb);
+   mtx_enter(&sc->sc_ccb_mtx);
SIMPLEQ_INSERT_TAIL(&sc->sc_ccb_free, ccb, ccb_chain);
+   mtx_leave(&sc->sc_ccb_mtx);
}
 
/* Start firmware background tasks, if needed. */
@@ -245,6 +249,7 @@ cac_init(struct cac_softc *sc, int start
sc->sc_link.openings = CAC_MAX_CCBS / sc->sc_nunits;
if (sc->sc_link.openings < 4 )
sc->sc_link.openings = 4;
+   sc->sc_link.pool = &sc->sc_iopool;
 
bzero(&saa, sizeof(saa));
saa.saa_sc_link = &sc->sc_link;
@@ -344,11 +349,18 @@ cac_cmd(struct cac_softc *sc, int comman
command, drive, blkno, data, datasize, flags, xs);
 #endif
 
-   if ((ccb = cac_ccb_alloc(sc, 0)) == NULL) {
-#ifdef CAC_DEBUG
-   printf("%s: unable to alloc CCB\n", sc->sc_dv.dv_xname);
-#endif
-   return (ENOMEM);
+   if (xs) {
+   ccb = xs->io;
+   /*
+* The xs may have been restarted by the scsi layer, so
+* ensure the ccb starts in the proper state.
+*/
+   ccb->ccb_flags = 0;
+   } else {
+   /* Internal command. Need to get our own ccb. */
+   ccb = scsi_io_get(&sc->sc_iopool, SCSI_POLL | SCSI_NOSLEEP);
+   if (ccb == NULL)
+   return (EBUSY);
}
 
if ((flags & (CAC_CCB_DATA_IN | CAC_CCB_DATA_OUT)) != 0) {
@@ -396,11 +408,9 @@ cac_cmd(struct cac_softc *sc, int comman
ccb->ccb_xs = xs;
 
if (!xs || xs->flags & SCSI_POLL) {
-
/* Synchronous commands musn't wait. */
if ((*sc->sc_cl->cl_fifo_full)(sc)) {
-   cac_ccb_free(sc, ccb);
-   rv = ENOMEM; /* Causes XS_NO_CCB, i/o is retried. */
+   rv = EBUSY;
} else {
ccb->ccb_flags |= CAC_CCB_ACTIVE;
(*sc->sc_cl->cl_submit)(sc, ccb);
@@ -409,6 +419,9 @@ cac_cmd(struct cac_softc *sc, int comman
} else
rv = cac_ccb_start(sc, ccb);
 
+   if (xs == NULL)
+   scsi_io_put(&sc->sc_iopool, ccb);
+
return (rv);
 }
 
@@ -419,8 +432,9 @@ int
 cac_ccb_poll(struct cac_softc *sc, struct cac_ccb *wantccb, int timo)
 {
struct cac_ccb *ccb;
-   int s, t = timo * 100;
+   int t;
 
+   t = timo * 100;
do {
for (; t--; DELAY(10))
if ((ccb = (*sc->sc_cl->cl_completed)(sc)) != NULL)
@@ -429,9 +443,7 @@ cac_ccb_poll(struct cac_softc *sc, struc
printf("%s: timeout\n", sc->sc_dv.dv_xname);
return (EBUSY);
}
-   s = splbio();
cac_ccb_done(sc, ccb);
-   splx(s);
} while (ccb != wantccb);
 
return (0);
@@ -439,17 +451,27 @@ cac_ccb_poll(struct cac_softc *sc, struc
 
 /*
  * Enqueue the specified command (if any) and attempt to start all enqueued
- * commands.  Must be called at splbio.
+ * commands.
  */
 int
 cac_ccb_start(struct cac_softc *sc, struct cac_ccb *ccb)
 {
-   if (ccb != NULL)
+   if (ccb != NULL) {
+   mtx_enter(&sc->sc_ccb_mtx);
SIMPLEQ_INSERT_TAIL(&sc->sc_ccb_queue, ccb, ccb_chain);
+   mtx_leave(&sc->sc_ccb_mtx);
+   }
 
-   while ((ccb = SIMPLEQ_FIRST(&sc->sc_ccb_queue)) != NULL &&
-   !(*sc->sc_cl->c

Re: fsck_ffs diff needs testing

[Otto Moerbeek]

On Thu, Apr 07, 2011 at 02:34:27PM +0200, Benny Lofgren wrote:

> On 2011-04-07 11.08, Otto Moerbeek wrote:
> > Hi,
> > 
> > I got little feedeback on this diff posed in a rather long thread, so
> > I am posting it again.
> > 
> > Please test this, it makes fsck_ffs much faster (especially with -p)
> > and less memory hungry in a lot of cases.
> 
> I've run it on a variety of file systems now and first of all, it seems
> to work without regressions. It also looks like it has about 2/3 of its
> previous memory footprint. However, I see very little increase in speed:

Were your filesystems mounted with softdep? Also, the most gain is
realized with ffs1 filesystems.

> 
> Unpatched, run with time /sbin/fsck_ffs -pf /dev/rraid0[adefghi]:
[snip]
> 1m20.35s real 0m2.57s user 0m4.29s system
> 
> Patched, run with time /root/fsck_ffs -pf /dev/rraid0[adefghi]:
> 
[snip]
> 1m18.52s real 0m1.32s user 0m3.85s system
> 
> The file systems are organized like this:
> 
> skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0a
> # newfs command for /dev/rraid0a
> newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
> 525856 /dev/rraid0a
> skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0d
> # newfs command for /dev/rraid0d
> newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
> 4197120 /dev/rraid0d
> skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0e
> # newfs command for /dev/rraid0e
> newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
> 8390400 /dev/rraid0e
> skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0f
> # newfs command for /dev/rraid0f
> newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
> 16780800 /dev/rraid0f
> skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0g
> # newfs command for /dev/rraid0g
> newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
> 41944320 /dev/rraid0g
> skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0h
> # newfs command for /dev/rraid0h
> newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
> 12583680 /dev/rraid0h
> skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0i
> # newfs command for /dev/rraid0i
> newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
> 7857920 /dev/rraid0i
> skynet:~/fsck_ffs_patch#
> Btw, I noticed a small change in this diff compared to the one you posted
> in the previous discussion thread. I assume this is the correct one to use?

Yes, though that's the most recent version.

-Otto
> 
> skynet:~# diff fsck_ffs.patch fsck_ffs_2.patch
> 158c158
> < +++ inode.c   31 Mar 2011 16:34:27 -
> ---
> > +++ inode.c   4 Apr 2011 09:16:36 -
> 203c203
> < + info[i].ino_state = USTATE;
> ---
> > + SET_ISTATE(i, USTATE);
> 
> 
> Regards,
> 
> /Benny

Re: rthreads: fix sharing of signal stacks and actions

[Philip Guenther]

On Wed, Apr 6, 2011 at 8:16 PM, Brad  wrote:
> I take it this PF diff was not supposed to be in there.. ?
>
>> Index: sys/net/pf.c

Yep.  Not even the right thing.  I'll reverse that chunk so I don't do
a thib and accidentally commit it...


Philip

Re: http gzip support for ftp

[Martynas Venckus]

> Delivered-To: marty...@venck.us
> Received: by 10.100.109.13 with SMTP id h13cs81395anc;
> Sun, 9 Jan 2011 14:09:58 -0800 (PST)
> Received: by 10.42.176.2 with SMTP id bc2mr3471559icb.517.1294610998158;
> Sun, 09 Jan 2011 14:09:58 -0800 (PST)
> Return-Path: 
> Received: from shear.ucar.edu (lists.openbsd.org [192.43.244.163])
> by mx.google.com with ESMTP id
f5si189964icu.33.2011.01.09.14.09.56;
> Sun, 09 Jan 2011 14:09:57 -0800 (PST)
> Received-SPF: pass (google.com: manual fallback record for domain of
owner-tech+m23...@openbsd.org designates 192.43.244.163 as permitted sender)
client-ip=192.43.244.163;
> Authentication-Results: mx.google.com; spf=pass (google.com: manual fallback
record for domain of owner-tech+m23...@openbsd.org designates 192.43.244.163
as permitted sender) smtp.mail=owner-tech+m23...@openbsd.org; dkim=pass (test
mode) header.i=@gmail.com
> Received: from openbsd.org (localhost.ucar.edu [127.0.0.1])
>   by shear.ucar.edu (8.14.3/8.14.3) with ESMTP id p09M9ZNr021431;
>   Sun, 9 Jan 2011 15:09:35 -0700 (MST)
> Received: from mail-qw0-f49.google.com (mail-qw0-f49.google.com
[209.85.216.49])
>   by shear.ucar.edu (8.14.3/8.14.3) with ESMTP id p09M8Qo7030584
>   for ; Sun, 9 Jan 2011 15:08:27 -0700 (MST)
> Received: by qwj9 with SMTP id 9so18728829qwj.8
>   for ; Sun, 09 Jan 2011 14:08:26 -0800 (PST)
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:received:received:date:from:to:cc:subject
:in-reply-to:message-id:references:user-agent:mime-version :content-type;
bh=h/uSItba1mLjBNAbFHi24e9uIaFGrvE/zyzh9me7yYw=;
b=XL2MRc5mQPtKcLk0xcUbEGn9qdUnrl6SeDWu1vs3q6WxC/wpfV2rgJanu5AiWpbf49
wtVrJKYpS9dy1CelkCIVzlg+RPUqnv32G3++umRivu257SvjpOOslVewDoQhQWObt2Ge
rOSbU0xTYAxK1Ed/VpudyiJchjG2z31yWyH+E=
> DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=date:from:to:cc:subject:in-reply-to:message-id:references
:user-agent:mime-version:content-type;
b=vy/Cr6z1/nOya7/ja1dbvBm4ImoKOvIBVNnuY9F9pk7/nk4nX79tDrpqDzmhuQAxtM
NUIjTiMhF4Iqu1yDpP9CxDFrltopI0N2v6zlVhte2HPPW3pumugdFX8PZAuyr8+H+Nxi
TDNAfVeIOfemJkkd/DClpRrGh+GwyqEa8ab+Q=
> Received: by 10.224.11.20 with SMTP id r20mr26905601qar.51.1294610906191;
Sun, 09 Jan 2011 14:08:26 -0800 (PST)
> Received: from mini.t3rl.org (cpe-74-66-19-205.nyc.res.rr.com
[74.66.19.205])
>   by mx.google.com with ESMTPS id nb15sm16014404qcb.2.2011.01.09.14.08.24
(version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 09 Jan 2011 14:08:25 -0800 (PST)
> Date: Sun, 9 Jan 2011 17:08:22 -0500 (EST)
> From: Ted Unangst 
> To: Ted Unangst 
> cc: tech@openbsd.org
> Subject: Re: http gzip support for ftp
> In-Reply-To: 
> Message-ID: 
> References: 
> User-Agent: Alpine 2.00 (BSO 1167 2008-08-23)
> MIME-Version: 1.0
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> List-Help: 
> List-Owner: 
> List-Post: 
> List-Subscribe: 
> List-Unsubscribe: 
> X-Loop: tech@openbsd.org
> Precedence: list
> Sender: owner-t...@openbsd.org
>
> On Sun, 9 Jan 2011, Ted Unangst wrote:
>
> > Downloading things can go a lot faster if the server and client support
> > http compression.  This is easily added to the ftp program's http
support.
>
> poopers, I hard coded gzipped to 1 by accident.  3rd time's a charm.
> Please test, as there are obviously lots of different web servers out
> there.
>
> Index: Makefile
> ===
> RCS file: /home/tedu/cvs/src/usr.bin/ftp/Makefile,v
> retrieving revision 1.25
> diff -u -r1.25 Makefile
> --- Makefile  5 May 2009 19:35:30 -   1.25
> +++ Makefile  9 Jan 2011 21:14:51 -
> @@ -17,8 +17,8 @@
>
>  CPPFLAGS+= -DINET6
>
> -LDADD+=  -ledit -lcurses -lutil -lssl -lcrypto
> -DPADD+=  ${LIBEDIT} ${LIBCURSES} ${LIBUTIL}
> +LDADD+=  -ledit -lcurses -lutil -lssl -lcrypto -lz
> +DPADD+=  ${LIBEDIT} ${LIBCURSES} ${LIBUTIL} ${LIBZ}
>  LDSTATIC= ${STATIC}
>
>  #COPTS+= -Wall -Wconversion -Wstrict-prototypes -Wmissing-prototypes
> Index: fetch.c
> ===
> RCS file: /home/tedu/cvs/src/usr.bin/ftp/fetch.c,v
> retrieving revision 1.103
> diff -u -r1.103 fetch.c
> --- fetch.c   25 Aug 2010 20:32:37 -  1.103
> +++ fetch.c   9 Jan 2011 22:07:12 -
> @@ -63,6 +63,7 @@
>  #ifndef SMALL
>  #include 
>  #include 
> +#include 
>  #else /* !SMALL */
>  #define SSL void
>  #endif /* !SMALL */
> @@ -167,6 +168,80 @@
>   return (epath);
>  }
>
> +#ifndef SMALL

Please put this at the end of the file, to avoid yet-another #ifndef
SMALL block.

> +static size_t
> +chunked_read(FILE *fin, SSL *ssl, unsigned char *buf, size_t amt,
> +int chunked, int gzipped)
> +{
> + static int chunksize;
> + static int zinit;
> + static z_stream zctx;
> +  

Re: fsck_ffs diff needs testing

[Benny Lofgren]

On 2011-04-07 11.08, Otto Moerbeek wrote:
> Hi,
> 
> I got little feedeback on this diff posed in a rather long thread, so
> I am posting it again.
> 
> Please test this, it makes fsck_ffs much faster (especially with -p)
> and less memory hungry in a lot of cases.

I've run it on a variety of file systems now and first of all, it seems
to work without regressions. It also looks like it has about 2/3 of its
previous memory footprint. However, I see very little increase in speed:

Unpatched, run with time /sbin/fsck_ffs -pf /dev/rraid0[adefghi]:

/dev/rraid0a: 2874 files, 82005 used, 46810 free (866 frags, 5743
blocks, 0.7% fragmentation)
/dev/rraid0d: 1477 files, 144486 used, 886745 free (553 frags, 110774
blocks, 0.1% fragmentation)
/dev/rraid0e: 224749 files, 1624996 used, 438155 free (48771 frags,
48673 blocks, 2.4% fragmentation)
/dev/rraid0f: 9437 files, 103157 used, 4024794 free (3370 frags, 502678
blocks, 0.1% fragmentation)
/dev/rraid0g: 498655 files, 6190187 used, 4128604 free (17188 frags,
513927 blocks, 0.2% fragmentation)
/dev/rraid0h: 90459 files, 445770 used, 2649301 free (20357 frags,
328618 blocks, 0.7% fragmentation)
/dev/rraid0i: 35896 files, 666529 used, 1266782 free (9006 frags, 157222
blocks, 0.5% fragmentation)

1m20.35s real 0m2.57s user 0m4.29s system

Patched, run with time /root/fsck_ffs -pf /dev/rraid0[adefghi]:

/dev/rraid0a: 2874 files, 82005 used, 46810 free (866 frags, 5743
blocks, 0.7% fragmentation)
/dev/rraid0d: 1477 files, 144486 used, 886745 free (553 frags, 110774
blocks, 0.1% fragmentation)
/dev/rraid0e: 224749 files, 1624996 used, 438155 free (48771 frags,
48673 blocks, 2.4% fragmentation)
/dev/rraid0f: 9437 files, 103157 used, 4024794 free (3370 frags, 502678
blocks, 0.1% fragmentation)
/dev/rraid0g: 498655 files, 6190187 used, 4128604 free (17188 frags,
513927 blocks, 0.2% fragmentation)
/dev/rraid0h: 90459 files, 445770 used, 2649301 free (20357 frags,
328618 blocks, 0.7% fragmentation)
/dev/rraid0i: 35896 files, 666529 used, 1266782 free (9006 frags, 157222
blocks, 0.5% fragmentation)

1m18.52s real 0m1.32s user 0m3.85s system

The file systems are organized like this:

skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0a
# newfs command for /dev/rraid0a
newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
525856 /dev/rraid0a
skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0d
# newfs command for /dev/rraid0d
newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
4197120 /dev/rraid0d
skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0e
# newfs command for /dev/rraid0e
newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
8390400 /dev/rraid0e
skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0f
# newfs command for /dev/rraid0f
newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
16780800 /dev/rraid0f
skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0g
# newfs command for /dev/rraid0g
newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
41944320 /dev/rraid0g
skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0h
# newfs command for /dev/rraid0h
newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
12583680 /dev/rraid0h
skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0i
# newfs command for /dev/rraid0i
newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
7857920 /dev/rraid0i
skynet:~/fsck_ffs_patch#

Btw, I noticed a small change in this diff compared to the one you posted
in the previous discussion thread. I assume this is the correct one to use?

skynet:~# diff fsck_ffs.patch fsck_ffs_2.patch
158c158
< +++ inode.c   31 Mar 2011 16:34:27 -
---
> +++ inode.c   4 Apr 2011 09:16:36 -
203c203
< + info[i].ino_state = USTATE;
---
> + SET_ISTATE(i, USTATE);


Regards,

/Benny

> Note that to force a check with -p you need to unmount the filesystem,
> mosty practical is  do it in single user mode:
> 
> # shutdown now
> ..
> # umount -a
> # fsck -pf
> 
> (Don't forget the unmount!)
> 
> Other way: pull the plug on a machine and let it reboot. That is a
> more realistic check and it is safe because you already backup up all
> your data, right? 
> 
>   -Otto
>   
> Index: dir.c
> ===
> RCS file: /cvs/src/sbin/fsck_ffs/dir.c,v
> retrieving revision 1.24
> diff -u -p -r1.24 dir.c
> --- dir.c 27 Oct 2009 23:59:32 -  1.24
> +++ dir.c 4 Apr 2011 09:15:49 -
> @@ -443,8 +443,8 @@ linkup(ino_t orphan, ino_t parentdir)
>   idesc.id_type = ADDR;
>   idesc.id_func = pass4check;
>   idesc.id_number = oldlfdir;
> - adjust(&idesc, lncntp[oldlfdir] + 1);
> - lncntp[oldlfdir] = 0;
> + adjust(&idesc, ILNCOUNT(oldlfdir) + 1);
> + ILNCOUNT(oldlfdir) = 0;
>   dp = ginode(lfdir);
>   }
>   if (GET_ISTATE(lfdir) != DFOUND) {
> @@ -457,7 +457,7 @@ linkup(ino_t orphan, ino_t parentdir)

Re: resurect and fix bce(4)

[Janne Johansson]

2011/4/3 Claudio Jeker 

> bce(4) was turned off because of limitations in the DMA engine that allows
> the chip to access only 1G of memory. On systems with more then 1G of
> memory hilarity ensued.
>
> Now I rewrote the driver to use bcopy() to copy the mbufs into a savely
> allocated DMA memory buffer. So the chip will now work with any ammount of
> memory in the machine. It works for me so if you own a bce(4) please test.
>
>
FWIW, my loaner laptop from the job works fine with this, giving me bce0
back.

(I used to limit ram to 1G when I needed bce before, don't have to anymore.
I don't care
for the performance drop, its far above "0" now)

-- 
 To our sweethearts and wives.  May they never meet. -- 19th century toast

Re: fsck_ffs diff needs testing

[Kenneth R Westerback]

On Thu, Apr 07, 2011 at 11:08:05AM +0200, Otto Moerbeek wrote:
> Hi,
> 
> I got little feedeback on this diff posed in a rather long thread, so
> I am posting it again.
> 
> Please test this, it makes fsck_ffs much faster (especially with -p)
> and less memory hungry in a lot of cases.
> 
> Note that to force a check with -p you need to unmount the filesystem,
> mosty practical is  do it in single user mode:
> 
> # shutdown now
> ..
> # umount -a
> # fsck -pf
> 
> (Don't forget the unmount!)
> 
> Other way: pull the plug on a machine and let it reboot. That is a
> more realistic check and it is safe because you already backup up all
> your data, right? 

I went the unplug route on the i386 box and amd64 box I have here, and
the diff seems to work. Reads ok. I say go for it.

 Ken

> 
>   -Otto
>   
> Index: dir.c
> ===
> RCS file: /cvs/src/sbin/fsck_ffs/dir.c,v
> retrieving revision 1.24
> diff -u -p -r1.24 dir.c
> --- dir.c 27 Oct 2009 23:59:32 -  1.24
> +++ dir.c 4 Apr 2011 09:15:49 -
> @@ -443,8 +443,8 @@ linkup(ino_t orphan, ino_t parentdir)
>   idesc.id_type = ADDR;
>   idesc.id_func = pass4check;
>   idesc.id_number = oldlfdir;
> - adjust(&idesc, lncntp[oldlfdir] + 1);
> - lncntp[oldlfdir] = 0;
> + adjust(&idesc, ILNCOUNT(oldlfdir) + 1);
> + ILNCOUNT(oldlfdir) = 0;
>   dp = ginode(lfdir);
>   }
>   if (GET_ISTATE(lfdir) != DFOUND) {
> @@ -457,7 +457,7 @@ linkup(ino_t orphan, ino_t parentdir)
>   printf("\n\n");
>   return (0);
>   }
> - lncntp[orphan]--;
> + ILNCOUNT(orphan)--;
>   if (lostdir) {
>   if ((changeino(orphan, "..", lfdir) & ALTERED) == 0 &&
>   parentdir != (ino_t)-1)
> @@ -465,7 +465,7 @@ linkup(ino_t orphan, ino_t parentdir)
>   dp = ginode(lfdir);
>   DIP_SET(dp, di_nlink, DIP(dp, di_nlink) + 1);
>   inodirty();
> - lncntp[lfdir]++;
> + ILNCOUNT(lfdir)++;
>   pwarn("DIR I=%u CONNECTED. ", orphan);
>   if (parentdir != (ino_t)-1) {
>   printf("PARENT WAS I=%u\n", parentdir);
> @@ -476,7 +476,7 @@ linkup(ino_t orphan, ino_t parentdir)
>* fixes the parent link count so that fsck does
>* not need to be rerun.
>*/
> - lncntp[parentdir]++;
> + ILNCOUNT(parentdir)++;
>   }
>   if (preen == 0)
>   printf("\n");
> @@ -636,7 +636,7 @@ allocdir(ino_t parent, ino_t request, in
>   DIP_SET(dp, di_nlink, 2);
>   inodirty();
>   if (ino == ROOTINO) {
> - lncntp[ino] = DIP(dp, di_nlink);
> + ILNCOUNT(ino) = DIP(dp, di_nlink);
>   cacheino(dp, ino);
>   return(ino);
>   }
> @@ -650,8 +650,8 @@ allocdir(ino_t parent, ino_t request, in
>   inp->i_dotdot = parent;
>   SET_ISTATE(ino, GET_ISTATE(parent));
>   if (GET_ISTATE(ino) == DSTATE) {
> - lncntp[ino] = DIP(dp, di_nlink);
> - lncntp[parent]++;
> + ILNCOUNT(ino) = DIP(dp, di_nlink);
> + ILNCOUNT(parent)++;
>   }
>   dp = ginode(parent);
>   DIP_SET(dp, di_nlink, DIP(dp, di_nlink) + 1);
> Index: extern.h
> ===
> RCS file: /cvs/src/sbin/fsck_ffs/extern.h,v
> retrieving revision 1.10
> diff -u -p -r1.10 extern.h
> --- extern.h  25 Jun 2007 19:59:55 -  1.10
> +++ extern.h  4 Apr 2011 09:15:49 -
> @@ -54,6 +54,7 @@ int ftypeok(union dinode *);
>  void getpathname(char *, size_t, ino_t, ino_t);
>  void inocleanup(void);
>  void inodirty(void);
> +struct inostat *inoinfo(ino_t);
>  int  linkup(ino_t, ino_t);
>  int  makeentry(ino_t, ino_t, char *);
>  void pass1(void);
> Index: fsck.h
> ===
> RCS file: /cvs/src/sbin/fsck_ffs/fsck.h,v
> retrieving revision 1.23
> diff -u -p -r1.23 fsck.h
> --- fsck.h10 Jun 2008 23:10:29 -  1.23
> +++ fsck.h4 Apr 2011 09:15:49 -
> @@ -66,6 +66,19 @@ union dinode {
>  #define BUFSIZ 1024
>  #endif
>  
> +/*
> + * Each inode on the file system is described by the following structure.
> + * The linkcnt is initially set to the value in the inode. Each time it
> + * is found during the descent in passes 2, 3, and 4 the count is
> + * decremented. Any inodes whose count is non-zero after pass 4 needs to
> + * have its link count adjusted by the value remaining in ino_linkcnt.
> + */
> +struct inostat {
> + charino_state;  /* state of inode, see below */
> + charino_type;   /* type of inode */
> + short   ino_linkcnt;/* number of links not found */
> +};
> +
>  #define  USTATE  01

Re: vnds considerd harmful.

[Thordur Bjornsson]

On Wed, Apr 06, 2011 at 04:25:15PM -0400, Jonathan Thornburg wrote:
> In ,
> Thordur Bjornsson  wrote:
> > Now that I've disallowed swapping to vnd's the purpose
> > of vnd (vs svnd) is suspect, it serves no purpose other
> > then providing a different way of doing what svnd does
> > (which imo, isn't even better).
> > 
> > So, nuke vnds (keep svnds though!).
> > 
> > This will make svndXn the same as vndXn etc. The idea is
> > that in a few releases we'll simply remove the svnd0 notes.
 ^ <- nodes.

With this diff svnd0 == vnd0 in your /dev.
 
> Could you clarify the semantics of the "in a few releases" plan?
> That is, are you proposing that the "in a few releases" OpenBSD will have
> (a) vnd == today's svnd,
bingo.

> (b) vnd == today's vnd,
> (c) vnd == some sort of merging of today's vnd and today's svnd, or
> (d) something else which hasn't occured to me yet
 
> I sort of think you're proposing (a), but I'm not entirely sure that I'm
> parsing your wording correctly...  [Hmm, I wonder if my failure-to-parse
> is related to a recent bout of perl hashes holding references to anonymous
> hashes holding references to anonymous lists. :) ]

So, yeah. vnd's will become today's svnd0's and the old style
bypassing of the buffer cache is gone (leaving only svnd0s).

Then in a few releases, the svnd device nodes will be removed.

fsck_ffs diff needs testing

[Otto Moerbeek]

Hi,

I got little feedeback on this diff posed in a rather long thread, so
I am posting it again.

Please test this, it makes fsck_ffs much faster (especially with -p)
and less memory hungry in a lot of cases.

Note that to force a check with -p you need to unmount the filesystem,
mosty practical is  do it in single user mode:

# shutdown now
..
# umount -a
# fsck -pf

(Don't forget the unmount!)

Other way: pull the plug on a machine and let it reboot. That is a
more realistic check and it is safe because you already backup up all
your data, right? 

-Otto

Index: dir.c
===
RCS file: /cvs/src/sbin/fsck_ffs/dir.c,v
retrieving revision 1.24
diff -u -p -r1.24 dir.c
--- dir.c   27 Oct 2009 23:59:32 -  1.24
+++ dir.c   4 Apr 2011 09:15:49 -
@@ -443,8 +443,8 @@ linkup(ino_t orphan, ino_t parentdir)
idesc.id_type = ADDR;
idesc.id_func = pass4check;
idesc.id_number = oldlfdir;
-   adjust(&idesc, lncntp[oldlfdir] + 1);
-   lncntp[oldlfdir] = 0;
+   adjust(&idesc, ILNCOUNT(oldlfdir) + 1);
+   ILNCOUNT(oldlfdir) = 0;
dp = ginode(lfdir);
}
if (GET_ISTATE(lfdir) != DFOUND) {
@@ -457,7 +457,7 @@ linkup(ino_t orphan, ino_t parentdir)
printf("\n\n");
return (0);
}
-   lncntp[orphan]--;
+   ILNCOUNT(orphan)--;
if (lostdir) {
if ((changeino(orphan, "..", lfdir) & ALTERED) == 0 &&
parentdir != (ino_t)-1)
@@ -465,7 +465,7 @@ linkup(ino_t orphan, ino_t parentdir)
dp = ginode(lfdir);
DIP_SET(dp, di_nlink, DIP(dp, di_nlink) + 1);
inodirty();
-   lncntp[lfdir]++;
+   ILNCOUNT(lfdir)++;
pwarn("DIR I=%u CONNECTED. ", orphan);
if (parentdir != (ino_t)-1) {
printf("PARENT WAS I=%u\n", parentdir);
@@ -476,7 +476,7 @@ linkup(ino_t orphan, ino_t parentdir)
 * fixes the parent link count so that fsck does
 * not need to be rerun.
 */
-   lncntp[parentdir]++;
+   ILNCOUNT(parentdir)++;
}
if (preen == 0)
printf("\n");
@@ -636,7 +636,7 @@ allocdir(ino_t parent, ino_t request, in
DIP_SET(dp, di_nlink, 2);
inodirty();
if (ino == ROOTINO) {
-   lncntp[ino] = DIP(dp, di_nlink);
+   ILNCOUNT(ino) = DIP(dp, di_nlink);
cacheino(dp, ino);
return(ino);
}
@@ -650,8 +650,8 @@ allocdir(ino_t parent, ino_t request, in
inp->i_dotdot = parent;
SET_ISTATE(ino, GET_ISTATE(parent));
if (GET_ISTATE(ino) == DSTATE) {
-   lncntp[ino] = DIP(dp, di_nlink);
-   lncntp[parent]++;
+   ILNCOUNT(ino) = DIP(dp, di_nlink);
+   ILNCOUNT(parent)++;
}
dp = ginode(parent);
DIP_SET(dp, di_nlink, DIP(dp, di_nlink) + 1);
Index: extern.h
===
RCS file: /cvs/src/sbin/fsck_ffs/extern.h,v
retrieving revision 1.10
diff -u -p -r1.10 extern.h
--- extern.h25 Jun 2007 19:59:55 -  1.10
+++ extern.h4 Apr 2011 09:15:49 -
@@ -54,6 +54,7 @@ int   ftypeok(union dinode *);
 void   getpathname(char *, size_t, ino_t, ino_t);
 void   inocleanup(void);
 void   inodirty(void);
+struct inostat *inoinfo(ino_t);
 intlinkup(ino_t, ino_t);
 intmakeentry(ino_t, ino_t, char *);
 void   pass1(void);
Index: fsck.h
===
RCS file: /cvs/src/sbin/fsck_ffs/fsck.h,v
retrieving revision 1.23
diff -u -p -r1.23 fsck.h
--- fsck.h  10 Jun 2008 23:10:29 -  1.23
+++ fsck.h  4 Apr 2011 09:15:49 -
@@ -66,6 +66,19 @@ union dinode {
 #define BUFSIZ 1024
 #endif
 
+/*
+ * Each inode on the file system is described by the following structure.
+ * The linkcnt is initially set to the value in the inode. Each time it
+ * is found during the descent in passes 2, 3, and 4 the count is
+ * decremented. Any inodes whose count is non-zero after pass 4 needs to
+ * have its link count adjusted by the value remaining in ino_linkcnt.
+ */
+struct inostat {
+   charino_state;  /* state of inode, see below */
+   charino_type;   /* type of inode */
+   short   ino_linkcnt;/* number of links not found */
+};
+
 #defineUSTATE  01  /* inode not allocated */
 #defineFSTATE  02  /* inode is file */
 #defineDSTATE  03  /* inode is directory */
@@ -73,12 +86,20 @@ union dinode {
 #defineDCLEAR  05  /* directory is to be cleared */
 #defineFCLEAR  06  /* file