Re: vga diff for testing
* Mark Kettenis mark.kette...@xs4all.nl [130304 02:10]: In order to be able to support a framebuffer console on i386/amd64 I'd like to reorder some code such that wsdisaplay(4) attaches to vga(4) *after* drm(4). Since I don't have any hardware with radeondrm(4) I'd appreciate it if people with access to such hardware would test the diff below. Just check that your vga text glass console and X still work. Still work. OpenBSD 5.3-current (kernel) #25: Mon Mar 4 02:34:03 MSK 2013 r...@watashi.plhk.ru:/usr/obj/kernel cpu0: Genuine Intel(R) CPU T2400 @ 1.83GHz (GenuineIntel 686-class) 1.83 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF real mem = 3219517440 (3070MB) avail mem = 3156656128 (3010MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 03/21/11, BIOS32 rev. 0 @ 0xfd6b0, SMBIOS rev. 2.4 @ 0xe0010 (68 entries) bios0: vendor LENOVO version 79ETE7WW (2.27 ) date 03/21/2011 bios0: LENOVO 2008ZBF acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET SLIC BOOT SSDT SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) LURT(S3) DURT(S3) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 166MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Genuine Intel(R) CPU T2400 @ 1.83GHz (GenuineIntel 686-class) 1.83 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpimcfg0 at acpi0 addr 0xf000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (AGP_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus 3 (EXP1) acpiprt4 at acpi0: bus 4 (EXP2) acpiprt5 at acpi0: bus 12 (EXP3) acpiprt6 at acpi0: bus 21 (PCI1) acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpipwrres0 at acpi0: PUBS acpitz0 at acpi0: critical temperature is 127 degC acpitz1 at acpi0: critical temperature is 99 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model COMPATIBLE serial 29687 type LION oem PSPSP acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK not docked (0) bios0: ROM list: 0xc/0xfe00 0xd/0x1000 0xd1000/0x1000 0xdc000/0x4000! 0xe/0x1! cpu0: Enhanced SpeedStep 1829 MHz: speeds: 1833, 1333, 1000 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82945GM Host rev 0x03 ppb0 at pci0 dev 1 function 0 Intel 82945GM PCIE rev 0x03: apic 1 int 16 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 ATI Radeon Mobility X1400 rev 0x00 radeondrm0 at vga1: apic 1 int 16 drm0 at radeondrm0 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) azalia0 at pci0 dev 27 function 0 Intel 82801GB HD Audio rev 0x02: msi azalia0: codecs: Analog Devices AD1981HD, 0x/0x, using Analog Devices AD1981HD audio0 at azalia0 ppb1 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x02: apic 1 int 20 pci2 at ppb1 bus 2 em0 at pci2 dev 0 function 0 Intel PRO/1000MT (82573L) rev 0x00: msi, address 00:16:41:e0:54:df ppb2 at pci0 dev 28 function 1 Intel 82801GB PCIE rev 0x02: apic 1 int 21 pci3 at ppb2 bus 3 wpi0 at pci3 dev 0 function 0 Intel PRO/Wireless 3945ABG rev 0x02: msi, MoW2, address 00:19:d2:03:ed:9d ppb3 at pci0 dev 28 function 2 Intel 82801GB PCIE rev 0x02: apic 1 int 22 pci4 at ppb3 bus 4 ppb4 at pci0 dev 28 function 3 Intel 82801GB PCIE rev 0x02: apic 1 int 23 pci5 at ppb4 bus 12 uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x02: apic 1 int 16 uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x02: apic 1 int 17 uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x02: apic 1 int 18 uhci3 at pci0 dev 29 function 3 Intel 82801GB USB rev 0x02: apic 1 int 19 ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x02: apic 1 int 19 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb5 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0xe2 pci6 at ppb5 bus 21 cbb0 at pci6 dev 0 function 0 TI PCI1510 CardBus rev 0x00: apic 1 int 16 cardslot0 at cbb0 slot 0 flags 0 cardbus0 at cardslot0: bus 22 device 0 cacheline 0x8, lattimer 0xb0 pcmcia0 at cardslot0 ichpcib0 at pci0 dev 31 function 0 Intel 82801GBM LPC rev 0x02: PM disabled pciide0 at pci0 dev 31 function 1 Intel 82801GB IDE rev 0x02: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility atapiscsi0 at
Re: vga diff for testing
Date: Sun, 3 Mar 2013 22:39:46 +0100 (CET) From: Mark Kettenis mark.kette...@xs4all.nl In order to be able to support a framebuffer console on i386/amd64 I'd like to reorder some code such that wsdisaplay(4) attaches to vga(4) *after* drm(4). Since I don't have any hardware with radeondrm(4) I'd appreciate it if people with access to such hardware would test the diff below. Just check that your vga text glass console and X still work. Thanks folks. I think enough people have tested this. Which means I'm looking for ok's now. Index: vga_pci.c === RCS file: /cvs/src/sys/dev/pci/vga_pci.c,v retrieving revision 1.69 diff -u -p -r1.69 vga_pci.c --- vga_pci.c 8 Oct 2012 21:47:50 - 1.69 +++ vga_pci.c 3 Mar 2013 21:34:59 - @@ -249,8 +249,6 @@ vga_pci_attach(struct device *parent, st } #endif printf(\n); - sc-sc_vc = vga_common_attach(self, pa-pa_iot, pa-pa_memt, - WSDISPLAY_TYPE_PCIVGA); vga_pci_bar_init(sc, pa); @@ -294,6 +292,9 @@ vga_pci_attach(struct device *parent, st #if NDRM 0 config_found_sm(self, aux, NULL, drmsubmatch); #endif + + sc-sc_vc = vga_common_attach(self, pa-pa_iot, pa-pa_memt, + WSDISPLAY_TYPE_PCIVGA); } int
Re: Add Soekris comBIOS detection to bios(4) on i386/amd64
* Matt Dainty m...@bodgit-n-scarper.com [2013-02-20 19:30:43]:
Attached are two patches for bios(4) on i386 amd64 that add support
for detecting the comBIOS on Soekris hardware, which then fills in the
hw.vendor hw.product sysctl variables as this hardware lacks any
SMBIOS to provide them. The idea is then these can be used in the
GPIO/LED driver for the net6501 I posted a while ago to simplify the
match logic.
I've tested this with a net6501 amd64 so I would appreciate testing
on any other Soekris hardware under i386; net4501, net4801 net5501.
I'm lacking a test report for a net4801, however as I've had reports
of success for all other Soekris board types, I'd be surprised if it
didn't work.
Also any other hardware that lacks SMBIOS and in the case of i386
doesn't need to disable probing of SMBIOS with flags 0x0008.
I would still appreciate some testing on other systems that lack any
SMBIOS, just to make sure it doesn't cause problems there. However as
this code walks over the same area of memory, I would again be
surprised if this caused problems when the SMBIOS probe didn't.
Matt
--- sys/arch/amd64/amd64/bios.c.orig Tue Feb 19 01:56:56 2013
+++ sys/arch/amd64/amd64/bios.c Wed Feb 20 08:37:12 2013
@@ -95,6 +95,7 @@
vaddr_t va;
paddr_t pa, end;
u_int8_t *p;
+ int smbiosrev = 0;
/* see if we have SMBIOS extentions */
for (p = ISA_HOLE_VADDR(SMBIOS_START);
@@ -137,6 +138,10 @@
printf(: SMBIOS rev. %d.%d @ 0x%lx (%d entries),
hdr-majrev, hdr-minrev, hdr-addr, hdr-count);
+ smbiosrev = hdr-majrev * 100 + hdr-minrev;
+ if (hdr-minrev 10)
+ smbiosrev = hdr-majrev * 100 + hdr-minrev * 10;
+
bios.cookie = 0;
if (smbios_find_table(SMBIOS_TYPE_BIOS, bios)) {
sb = bios.tblhdr;
@@ -158,6 +163,39 @@
break;
}
printf(\n);
+
+ /* No SMBIOS extensions, go looking for Soekris comBIOS */
+ if (!smbiosrev) {
+ const char *signature = Soekris Engineering;
+
+ for (p = ISA_HOLE_VADDR(SMBIOS_START);
+ p = (u_int8_t *)ISA_HOLE_VADDR(SMBIOS_END -
+ (strlen(signature) - 1)); p++)
+ if (!memcmp(p, signature, strlen(signature))) {
+ hw_vendor = malloc(strlen(signature) + 1,
+ M_DEVBUF, M_NOWAIT);
+ if (hw_vendor)
+ strlcpy(hw_vendor, signature,
+ strlen(signature) + 1);
+ p += strlen(signature);
+ break;
+ }
+
+ for (; hw_vendor
+ p = (u_int8_t *)ISA_HOLE_VADDR(SMBIOS_END - 6); p++)
+ /*
+ * Search only for net6501 in the comBIOS as that's
+ * the only Soekris platform that can run amd64
+ */
+ if (!memcmp(p, net6501, 7)) {
+ hw_prod = malloc(8, M_DEVBUF, M_NOWAIT);
+ if (hw_prod) {
+ memcpy(hw_prod, p, 7);
+ hw_prod[7] = '\0';
+ }
+ break;
+ }
+ }
#if NACPI 0
{
--- sys/arch/i386/i386/bios.c.origTue Feb 19 06:36:42 2013
+++ sys/arch/i386/i386/bios.c Wed Feb 20 08:58:17 2013
@@ -330,6 +330,43 @@
printf(\n);
+ /* No SMBIOS extensions, go looking for Soekris comBIOS */
+ if (!(flags BIOSF_SMBIOS) !smbiosrev) {
+ const char *signature = Soekris Engineering;
+
+ for (va = ISA_HOLE_VADDR(SMBIOS_START);
+ va = (u_int8_t *)ISA_HOLE_VADDR(SMBIOS_END -
+ (strlen(signature) - 1)); va++)
+ if (!memcmp((u_int8_t *)va, signature,
+ strlen(signature))) {
+ hw_vendor = malloc(strlen(signature) + 1,
+ M_DEVBUF, M_NOWAIT);
+ if (hw_vendor)
+ strlcpy(hw_vendor, signature,
+ strlen(signature) + 1);
+ va += strlen(signature);
+ break;
+ }
+
+ for (; hw_vendor
+ va = (u_int8_t *)ISA_HOLE_VADDR(SMBIOS_END - 6); va++)
+ /*
+ * Search for net(4(5xx|801)|[56]501) which matches
+ * the strings found in the comBIOS images
+ */
+ if (!memcmp((u_int8_t *)va, net45xx, 7) ||
+
touch(1) doesn't act as expected: One for JMC
Snip from the manpage describing the format used to apply a date to a file: ccyy Year. mm Month: a number from 1 to 12. dd Day: a number from 1 to 31. T Either the capital letter `T' or a single space. HH Hour: a number from 0 to 23. MM Minute: a number from 0 to 59. SS Second: a number from 0 to 60 (permitting a leap second). Result of using a single space instead of T: # touch -d 2013-03-01 12:34:56 test touch: out of range or illegal time specification: -MM-DDThh:mm:ss[.frac][Z] Of course it is obvious to experienced hands that the space needs to be escaped but it's not so obvious to beginners. Particularly when the documentation shows the same string in the syntax as is shown in the error message - always with the T. I told the victim to pretend that the T was the only valid char in that space because it's easier to type one char than two. jmc, care to comment? *** NOTE *** Please DO NOT CC me. I am 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.
Re: touch(1) doesn't act as expected: One for JMC
Rod Whitworth glis...@witworx.com writes: Snip from the manpage describing the format used to apply a date to a file: ccyy Year. mm Month: a number from 1 to 12. dd Day: a number from 1 to 31. T Either the capital letter `T' or a single space. HH Hour: a number from 0 to 23. MM Minute: a number from 0 to 59. SS Second: a number from 0 to 60 (permitting a leap second). Result of using a single space instead of T: # touch -d 2013-03-01 12:34:56 test touch: out of range or illegal time specification: -MM-DDThh:mm:ss[.frac][Z] Of course it is obvious to experienced hands that the space needs to be escaped but it's not so obvious to beginners. Particularly when the documentation shows the same string in the syntax as is shown in the error message - always with the T. I don't have an opinion about whether a change is needed, but here's the POSIX wording[1]: If the T time designator is replaced by a space for the -d date_time option-argument, the space must be quoted to prevent the shell from splitting the argument. I told the victim to pretend that the T was the only valid char in that space because it's easier to type one char than two. I'd say that protecting strings from the shell would better be done using single or double quotes rather than a backslash (when possible). jmc, care to comment? *** NOTE *** Please DO NOT CC me. I am 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. Using the Mail-Followup-To[2] header and indenting ( 80 chars) this part of your mails would help. [1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/touch.html [2] http://cr.yp.to/proto/replyto.html -- Jérémie Courrèges-Anglas GPG Key fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
Re: Add Soekris comBIOS detection to bios(4) on i386/amd64
On Mon, 4 Mar 2013 06:02:19 -0500 Matt Dainty m...@bodgit-n-scarper.com wrote:
* Matt Dainty m...@bodgit-n-scarper.com [2013-02-20 19:30:43]:
Attached are two patches for bios(4) on i386 amd64 that add support
for detecting the comBIOS on Soekris hardware, which then fills in the
hw.vendor hw.product sysctl variables as this hardware lacks any
SMBIOS to provide them. The idea is then these can be used in the
GPIO/LED driver for the net6501 I posted a while ago to simplify the
match logic.
I've tested this with a net6501 amd64 so I would appreciate testing
on any other Soekris hardware under i386; net4501, net4801 net5501.
I'm lacking a test report for a net4801, however as I've had reports
of success for all other Soekris board types, I'd be surprised if it
didn't work.
Hi,
I can confirm that your patch works for i386 on net4501:
# sysctl hw
hw.machine=i386
hw.model=Geode(TM) Integrated Processor by National Semi (Geode by NSC
586-class)
hw.ncpu=1
hw.byteorder=1234
hw.pagesize=4096
...
hw.cpuspeed=267
hw.vendor=Soekris Engineering
hw.product=net4801
hw.version=1
hw.physmem=133754880
hw.usermem=133742592
hw.ncpufound=1
hw.allowpowerdown=1
Gerhard
Also any other hardware that lacks SMBIOS and in the case of i386
doesn't need to disable probing of SMBIOS with flags 0x0008.
I would still appreciate some testing on other systems that lack any
SMBIOS, just to make sure it doesn't cause problems there. However as
this code walks over the same area of memory, I would again be
surprised if this caused problems when the SMBIOS probe didn't.
Matt
--- sys/arch/amd64/amd64/bios.c.origTue Feb 19 01:56:56 2013
+++ sys/arch/amd64/amd64/bios.c Wed Feb 20 08:37:12 2013
@@ -95,6 +95,7 @@
vaddr_t va;
paddr_t pa, end;
u_int8_t *p;
+ int smbiosrev = 0;
/* see if we have SMBIOS extentions */
for (p = ISA_HOLE_VADDR(SMBIOS_START);
@@ -137,6 +138,10 @@
printf(: SMBIOS rev. %d.%d @ 0x%lx (%d entries),
hdr-majrev, hdr-minrev, hdr-addr, hdr-count);
+ smbiosrev = hdr-majrev * 100 + hdr-minrev;
+ if (hdr-minrev 10)
+ smbiosrev = hdr-majrev * 100 + hdr-minrev * 10;
+
bios.cookie = 0;
if (smbios_find_table(SMBIOS_TYPE_BIOS, bios)) {
sb = bios.tblhdr;
@@ -158,6 +163,39 @@
break;
}
printf(\n);
+
+ /* No SMBIOS extensions, go looking for Soekris comBIOS */
+ if (!smbiosrev) {
+ const char *signature = Soekris Engineering;
+
+ for (p = ISA_HOLE_VADDR(SMBIOS_START);
+ p = (u_int8_t *)ISA_HOLE_VADDR(SMBIOS_END -
+ (strlen(signature) - 1)); p++)
+ if (!memcmp(p, signature, strlen(signature))) {
+ hw_vendor = malloc(strlen(signature) + 1,
+ M_DEVBUF, M_NOWAIT);
+ if (hw_vendor)
+ strlcpy(hw_vendor, signature,
+ strlen(signature) + 1);
+ p += strlen(signature);
+ break;
+ }
+
+ for (; hw_vendor
+ p = (u_int8_t *)ISA_HOLE_VADDR(SMBIOS_END - 6); p++)
+ /*
+* Search only for net6501 in the comBIOS as that's
+* the only Soekris platform that can run amd64
+*/
+ if (!memcmp(p, net6501, 7)) {
+ hw_prod = malloc(8, M_DEVBUF, M_NOWAIT);
+ if (hw_prod) {
+ memcpy(hw_prod, p, 7);
+ hw_prod[7] = '\0';
+ }
+ break;
+ }
+ }
#if NACPI 0
{
--- sys/arch/i386/i386/bios.c.orig Tue Feb 19 06:36:42 2013
+++ sys/arch/i386/i386/bios.c Wed Feb 20 08:58:17 2013
@@ -330,6 +330,43 @@
printf(\n);
+ /* No SMBIOS extensions, go looking for Soekris comBIOS */
+ if (!(flags BIOSF_SMBIOS) !smbiosrev) {
+ const char *signature = Soekris Engineering;
+
+ for (va = ISA_HOLE_VADDR(SMBIOS_START);
+ va = (u_int8_t *)ISA_HOLE_VADDR(SMBIOS_END -
+ (strlen(signature) - 1)); va++)
+ if (!memcmp((u_int8_t *)va, signature,
+ strlen(signature))) {
+ hw_vendor = malloc(strlen(signature) + 1,
+ M_DEVBUF, M_NOWAIT);
+ if (hw_vendor)
+ strlcpy(hw_vendor, signature,
+ strlen(signature) + 1);
+ va += strlen(signature);
+
Re: Add Soekris comBIOS detection to bios(4) on i386/amd64
On Mon, 4 Mar 2013 15:18:45 +0100 Gerhard Roth gerhard_r...@genua.de wrote:
On Mon, 4 Mar 2013 06:02:19 -0500 Matt Dainty m...@bodgit-n-scarper.com
wrote:
* Matt Dainty m...@bodgit-n-scarper.com [2013-02-20 19:30:43]:
Attached are two patches for bios(4) on i386 amd64 that add support
for detecting the comBIOS on Soekris hardware, which then fills in the
hw.vendor hw.product sysctl variables as this hardware lacks any
SMBIOS to provide them. The idea is then these can be used in the
GPIO/LED driver for the net6501 I posted a while ago to simplify the
match logic.
I've tested this with a net6501 amd64 so I would appreciate testing
on any other Soekris hardware under i386; net4501, net4801 net5501.
I'm lacking a test report for a net4801, however as I've had reports
of success for all other Soekris board types, I'd be surprised if it
didn't work.
Hi,
I can confirm that your patch works for i386 on net4501:
# sysctl hw
hw.machine=i386
hw.model=Geode(TM) Integrated Processor by National Semi (Geode by NSC
586-class)
hw.ncpu=1
hw.byteorder=1234
hw.pagesize=4096
...
hw.cpuspeed=267
hw.vendor=Soekris Engineering
hw.product=net4801
hw.version=1
hw.physmem=133754880
hw.usermem=133742592
hw.ncpufound=1
hw.allowpowerdown=1
Gerhard
Sorry,
stupid me mixed up 4801 and 4501 :(
But as you see from the sysctl output, I tested on 4801. So this should
fill up your gap.
Gerhard
Also any other hardware that lacks SMBIOS and in the case of i386
doesn't need to disable probing of SMBIOS with flags 0x0008.
I would still appreciate some testing on other systems that lack any
SMBIOS, just to make sure it doesn't cause problems there. However as
this code walks over the same area of memory, I would again be
surprised if this caused problems when the SMBIOS probe didn't.
Matt
--- sys/arch/amd64/amd64/bios.c.orig Tue Feb 19 01:56:56 2013
+++ sys/arch/amd64/amd64/bios.c Wed Feb 20 08:37:12 2013
@@ -95,6 +95,7 @@
vaddr_t va;
paddr_t pa, end;
u_int8_t *p;
+ int smbiosrev = 0;
/* see if we have SMBIOS extentions */
for (p = ISA_HOLE_VADDR(SMBIOS_START);
@@ -137,6 +138,10 @@
printf(: SMBIOS rev. %d.%d @ 0x%lx (%d entries),
hdr-majrev, hdr-minrev, hdr-addr, hdr-count);
+ smbiosrev = hdr-majrev * 100 + hdr-minrev;
+ if (hdr-minrev 10)
+ smbiosrev = hdr-majrev * 100 + hdr-minrev * 10;
+
bios.cookie = 0;
if (smbios_find_table(SMBIOS_TYPE_BIOS, bios)) {
sb = bios.tblhdr;
@@ -158,6 +163,39 @@
break;
}
printf(\n);
+
+ /* No SMBIOS extensions, go looking for Soekris comBIOS */
+ if (!smbiosrev) {
+ const char *signature = Soekris Engineering;
+
+ for (p = ISA_HOLE_VADDR(SMBIOS_START);
+ p = (u_int8_t *)ISA_HOLE_VADDR(SMBIOS_END -
+ (strlen(signature) - 1)); p++)
+ if (!memcmp(p, signature, strlen(signature))) {
+ hw_vendor = malloc(strlen(signature) + 1,
+ M_DEVBUF, M_NOWAIT);
+ if (hw_vendor)
+ strlcpy(hw_vendor, signature,
+ strlen(signature) + 1);
+ p += strlen(signature);
+ break;
+ }
+
+ for (; hw_vendor
+ p = (u_int8_t *)ISA_HOLE_VADDR(SMBIOS_END - 6); p++)
+ /*
+ * Search only for net6501 in the comBIOS as that's
+ * the only Soekris platform that can run amd64
+ */
+ if (!memcmp(p, net6501, 7)) {
+ hw_prod = malloc(8, M_DEVBUF, M_NOWAIT);
+ if (hw_prod) {
+ memcpy(hw_prod, p, 7);
+ hw_prod[7] = '\0';
+ }
+ break;
+ }
+ }
#if NACPI 0
{
--- sys/arch/i386/i386/bios.c.origTue Feb 19 06:36:42 2013
+++ sys/arch/i386/i386/bios.c Wed Feb 20 08:58:17 2013
@@ -330,6 +330,43 @@
printf(\n);
+ /* No SMBIOS extensions, go looking for Soekris comBIOS */
+ if (!(flags BIOSF_SMBIOS) !smbiosrev) {
+ const char *signature = Soekris Engineering;
+
+ for (va = ISA_HOLE_VADDR(SMBIOS_START);
+ va = (u_int8_t *)ISA_HOLE_VADDR(SMBIOS_END -
+ (strlen(signature) - 1)); va++)
+ if (!memcmp((u_int8_t *)va, signature,
+ strlen(signature))) {
+ hw_vendor = malloc(strlen(signature) + 1,
+ M_DEVBUF, M_NOWAIT);
+
Re: [PATCH] mlockall() problem in OpenBSD 5.2
Hi, just wanted to notice that the difference in locking and resource counting algorithms is not fixed yet. That means that mlockall() in 5.3 is still broken. Given that src tree is unlocked now, is there any chance that it will be fixed? By the way, we're using the patched version of uvm_map_pageable_all() for a long time now and haven't noticed any problems. Thanks! On Sunday 09 December 2012 00:26:35 Ariane van der Steldt wrote: Ilya Bakulin does point out a serious bug in the vmmap code however: the resource counting algorithms and locking algorithm count differently. The code ought to be in sync; if no developer is going to fix the commit-part of the code, I would seriously recommend putting Ilya's diff in. signature.asc Description: This is a digitally signed message part.
[PATCH] snmpd readonly mode
Hi list,
We have a small issue with snmpd daemon in OpenBSD.
If people use SNMPv2c, they should explicitly set read-write community name
to some [probably random-generated] string, because otherwise everybody is
able to alter values of some SNMP nodes (the default value for read-write
community is private, which is not very secure, probably).
Attached is the patch that adds new configuration file parameter,
nowrite, with values yes and no, that disallows any write
attempts to any SNMP node regardless of specified read-write community string.
$ snmpset -c private -v2c 127.0.0.1 system.sysContact.0 s SOME_CRAP
Error in packet.
Reason: (readOnly) The two parties used do not have access to use the
specified SNMP PDU.
Failed object: SNMPv2-MIB::sysContact.0
Hope you will find it useful.
// Ilya
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/snmpd/parse.y,v
retrieving revision 1.23
diff -u -r1.23 parse.y
--- parse.y 17 Sep 2012 19:00:06 - 1.23
+++ parse.y 2 Feb 2013 11:34:01 -
@@ -117,7 +117,7 @@
%token LISTEN ON
%token SYSTEM CONTACT DESCR LOCATION NAME OBJECTID SERVICES RTFILTER
%token READONLY READWRITE OCTETSTRING INTEGER COMMUNITY TRAP RECEIVER
-%token SECLEVEL NONE AUTH ENC USER AUTHKEY ENCKEY ERROR
+%token SECLEVEL NONE AUTH ENC USER AUTHKEY ENCKEY ERROR NOWRITE
%token v.string STRING
%token v.number NUMBER
%type v.string hostcmn
@@ -244,6 +244,12 @@
| SECLEVEL seclevel {
conf-sc_min_seclevel = $2;
}
+ | NOWRITE yesno {
+ if ($2 == 1)
+conf-nowrite = 1;
+ else
+conf-nowrite = 0;
+ }
| USER STRING {
const char *errstr;
user = usm_newuser($2, errstr);
@@ -493,6 +499,7 @@
{ location, LOCATION },
{ name, NAME },
{ none, NONE },
+ { nowrite, NOWRITE },
{ oid, OBJECTID },
{ on, ON },
{ read-only, READONLY },
Index: snmpd.conf.5
===
RCS file: /cvs/src/usr.sbin/snmpd/snmpd.conf.5,v
retrieving revision 1.21
diff -u -r1.21 snmpd.conf.5
--- snmpd.conf.5 18 Sep 2012 10:03:45 - 1.21
+++ snmpd.conf.5 2 Feb 2013 11:34:01 -
@@ -95,6 +95,14 @@
.Ar private .
.Pp
.It Xo
+.Ic nowrite
+.Pq Ic yes \*(Ba\ no
+.Xc
+If set to
+.Ic yes ,
+disallow any SNMP write requests, regardless of read-write community.
+.Pp
+.It Xo
.Ic filter-routes
.Pq Ic yes \*(Ba\ no
.Xc
Index: snmpd.h
===
RCS file: /cvs/src/usr.sbin/snmpd/snmpd.h,v
retrieving revision 1.39
diff -u -r1.39 snmpd.h
--- snmpd.h 1 Oct 2012 11:36:55 - 1.39
+++ snmpd.h 2 Feb 2013 11:34:02 -
@@ -420,6 +420,7 @@
int sc_rtfilter;
int sc_min_seclevel;
+ int nowrite;
};
/* control.c */
Index: snmpe.c
===
RCS file: /cvs/src/usr.sbin/snmpd/snmpe.c,v
retrieving revision 1.32
diff -u -r1.32 snmpe.c
--- snmpe.c 29 Nov 2012 14:53:24 - 1.32
+++ snmpe.c 2 Feb 2013 11:34:02 -
@@ -697,7 +697,7 @@
ber_free_elements(c);
goto varfail;
case SNMP_C_SETREQ:
- if (mps_setreq(b, o) == 0)
+ if (env-nowrite == 0 mps_setreq(b, o) == 0)
break;
msg-sm_error = SNMP_ERROR_READONLY;
goto varfail;
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH] snmpd readonly mode
On Mon, 4 Mar 2013 15:56:36 +0100 Ilya Bakulin ilya_baku...@genua.de wrote: Hi list, We have a small issue with snmpd daemon in OpenBSD. If people use SNMPv2c, they should explicitly set read-write community name to some [probably random-generated] string, because otherwise everybody is able to alter values of some SNMP nodes (the default value for read-write community is private, which is not very secure, probably). Attached is the patch that adds new configuration file parameter, nowrite, with values yes and no, that disallows any write attempts to any SNMP node regardless of specified read-write community string. $ snmpset -c private -v2c 127.0.0.1 system.sysContact.0 s SOME_CRAP Error in packet. Reason: (readOnly) The two parties used do not have access to use the specified SNMP PDU. Failed object: SNMPv2-MIB::sysContact.0 Hope you will find it useful. // Ilya Just a little bike-shedding: - The term readonly seems more common to me than nowrite. - All members of struct snmpd have a 'sc_' prefix. You should stick to that style. Gerhard
re(4) ip header checksum offloading
Hi tech@,
Calculating the IP header checksum on Realtek 8168 is broken when the
packet has IP options.
FreeBSD mentions only the 8168C and 8168C_SPIN2 but the 8168CP is the
one we have.
http://svnweb.freebsd.org/base/stable/8/sys/dev/re/if_re.c?r1=219112r2=219114
Solution is to disable IP checksum offloading.
ok?
bluhm
Index: dev/ic/re.c
===
RCS file: /mount/cvsdev/cvs/openbsd/src/sys/dev/ic/re.c,v
retrieving revision 1.139
diff -u -p -r1.139 re.c
--- dev/ic/re.c 9 May 2012 13:30:12 - 1.139
+++ dev/ic/re.c 1 Mar 2013 18:22:30 -
@@ -1139,8 +1139,21 @@ re_attach(struct rl_softc *sc, const cha
m_clsetwms(ifp, MCLBYTES, 2, RL_RX_DESC_CNT);
- ifp-if_capabilities = IFCAP_VLAN_MTU | IFCAP_CSUM_IPv4 |
- IFCAP_CSUM_TCPv4 | IFCAP_CSUM_UDPv4;
+ /*
+* RTL8168/8111C generates wrong IP checksummed frame if the
+* packet has IP options so disable TX IP checksum offloading.
+*/
+ switch (sc-sc_hwrev) {
+ case RL_HWREV_8168C:
+ case RL_HWREV_8168C_SPIN2:
+ case RL_HWREV_8168CP:
+ ifp-if_capabilities = IFCAP_VLAN_MTU |
+ IFCAP_CSUM_TCPv4 | IFCAP_CSUM_UDPv4;
+ break;
+ default:
+ ifp-if_capabilities = IFCAP_VLAN_MTU | IFCAP_CSUM_IPv4 |
+ IFCAP_CSUM_TCPv4 | IFCAP_CSUM_UDPv4;
+ }
#if NVLAN 0
ifp-if_capabilities |= IFCAP_VLAN_HWTAGGING;
Re: out of memory errors seen on several AnonCVS servers
On Sun, Mar 03, 2013 at 22:17, Stuart Henderson wrote: On 2013/03/03 17:11, Ted Unangst wrote: On Sun, Mar 03, 2013 at 16:16, Stuart Henderson wrote: Summary of off-list mail exchange: anoncvs.usa consistently has a realloc failure in xenocara/font/misc-misc/18x18ja.bdf, some other servers have a failure the first time checking this file out when it's part of the whole directory, but resuming or checking out individually does work. amd64? Use i386. :) or opencvs. The problems in opencvs are more insidious. You only have to check the file out once, then it works. As far as I know. Haven't done a full x11 checkout on amd64 for a while.
Re: out of memory errors seen on several AnonCVS servers
On 2013/03/04 10:47, Ted Unangst wrote: On Sun, Mar 03, 2013 at 22:17, Stuart Henderson wrote: On 2013/03/03 17:11, Ted Unangst wrote: On Sun, Mar 03, 2013 at 16:16, Stuart Henderson wrote: Summary of off-list mail exchange: anoncvs.usa consistently has a realloc failure in xenocara/font/misc-misc/18x18ja.bdf, some other servers have a failure the first time checking this file out when it's part of the whole directory, but resuming or checking out individually does work. amd64? Use i386. :) or opencvs. The problems in opencvs are more insidious. You only have to check the file out once, then it works. As far as I know. Haven't done a full x11 checkout on amd64 for a while. The client arch and software doesn't make a difference, the problem is on the server side. Problems seen when using opencvs server-side include giving out the wrong file version, and giving a checkout which can't reliably be used against a server running original CVS.
Re: out of memory errors seen on several AnonCVS servers
On Mon, Mar 04, 2013 at 15:55, Stuart Henderson wrote: The client arch and software doesn't make a difference, the problem is on the server side. Problems seen when using opencvs server-side include giving out the wrong file version, and giving a checkout which can't reliably be used against a server running original CVS. hmmm, it's been a long time, but when I ran into this problem (like 2005), the client arch made all the difference. Or maybe back then the servers were all i386, too, and both client and server needed to be 32 bit? i.e., what used to be a client problem is now a server and client problem.
Re: out of memory errors seen on several AnonCVS servers
On 2013/03/04 11:13, Ted Unangst wrote: On Mon, Mar 04, 2013 at 15:55, Stuart Henderson wrote: The client arch and software doesn't make a difference, the problem is on the server side. Problems seen when using opencvs server-side include giving out the wrong file version, and giving a checkout which can't reliably be used against a server running original CVS. hmmm, it's been a long time, but when I ran into this problem (like 2005), the client arch made all the difference. Or maybe back then the servers were all i386, too, and both client and server needed to be 32 bit? i.e., what used to be a client problem is now a server and client problem. yes, that's older - stsp fixed one problem with it since then... - PatchSet 254 Date: 2009/12/14 21:15:55 Author: stsp Branch: HEAD Tag: OPENBSD_4_7_BASE Log: Fix cvs [update aborted]: out of memory; can not reallocate 5242880 bytes when checking out xenocara from a server running OpenBSD/amd64. While processing RCS deltas, don't allocate twice as much memory as needed when copying a line vector to a vector which has less lines. Also, when switching back from a branch to trunk while searching an RCS file for a revision, free the trunklines vector immediately after lines saved in it have been copied back into the currentlines vector. Somehow, these two changes together make the problem go away. ok tobias@, this has been a serious annoyance sthen@, sure deraadt@ Members: src/rcs.c:1.22-1.23 - Hmm. Looking at the number of bytes in the error message which matches what's seen on anoncvs.usa and differs to my server... Todd, does the copy in your chroot pre-date this commit?
Re: [PATCH] snmpd readonly mode
On Monday 04 March 2013 16:13:09 Gerhard Roth wrote: Just a little bike-shedding: - The term readonly seems more common to me than nowrite. I didn't use readonly because there is already a keyword read-only with the token name READONLY, and I didn't want to introduce yet another readonly* variable :-) - All members of struct snmpd have a 'sc_' prefix. You should stick to that style. Gerhard Agree, not using sc_ is bad. // Ilya
Re: [PATCH] snmpd readonly mode
On Mon, 4 Mar 2013 17:28:17 +0100 Ilya Bakulin ilya_baku...@genua.de wrote: On Monday 04 March 2013 16:13:09 Gerhard Roth wrote: Just a little bike-shedding: - The term readonly seems more common to me than nowrite. I didn't use readonly because there is already a keyword read-only with the token name READONLY, and I didn't want to introduce yet another readonly* variable :-) Hi Ilya, how about using the existing 'read-write' keyword? read-write [no | community string] Gerhard - All members of struct snmpd have a 'sc_' prefix. You should stick to that style. Gerhard Agree, not using sc_ is bad. // Ilya
Re: out of memory errors seen on several AnonCVS servers
On Mon, 04 Mar 2013 16:19:56 GMT, Stuart Henderson wrote: Hmm. Looking at the number of bytes in the error message which matches what's seen on anoncvs.usa and differs to my server... Todd, does the copy in your chroot pre-date this commit? The cvs binary may not have had that fix on anoncvs.usa. I've updated and rebuilt the cvs binary which should fix it. - todd
Re: out of memory errors seen on several AnonCVS servers
On Mon, Mar 04, 2013 at 16:19, Stuart Henderson wrote: yes, that's older - stsp fixed one problem with it since then... Oh, missed that. Good to know. Hmm. Looking at the number of bytes in the error message which matches what's seen on anoncvs.usa and differs to my server... Todd, does the copy in your chroot pre-date this commit? Sweet. One problem solved. Sounds like the remaining issue is internal fragmentation, possibly exacerbated by randomization. How old is your cvs binary? I'm wondering if the realloc fixes I made last release have any effect. And of course, I think you can always up the ulimit.
Re: out of memory errors seen on several AnonCVS servers
On Mon, Mar 04, 2013 at 11:13:22AM -0500, Ted Unangst wrote: On Mon, Mar 04, 2013 at 15:55, Stuart Henderson wrote: The client arch and software doesn't make a difference, the problem is on the server side. Problems seen when using opencvs server-side include giving out the wrong file version, and giving a checkout which can't reliably be used against a server running original CVS. hmmm, it's been a long time, but when I ran into this problem (like 2005), the client arch made all the difference. Ditto. Ken Or maybe back then the servers were all i386, too, and both client and server needed to be 32 bit? i.e., what used to be a client problem is now a server and client problem.
Re: out of memory errors seen on several AnonCVS servers
I believe this problem ought to be fixed over the next few hours as mirrors pull updated files.
Secrets of Buffer Cache Enlargement.
You too can have a GIANT buffer cache etc. etc...
After much bug fighting in the midlayer and now uvm over the last 6
months in a number of places, I think it's about time to shop this
around again.
This will only make a difference on amd64 - if you have 4 GB or more
of RAM. What it does is allows the high (non-DMA reachable) memory to
be used for buffer cache pages. It will use your set buffer
cache percentage of both dma'able, and above dma'able pages for the
cache, migrating the oldest cache pages into high memory. pages
are flipped back into dma'able memory if they are needed for IO.
Notwithstanding that it only matters on amd64, it does change how
the world works a bit, and therefore requires testing everywhere. It
has survived multiple make build/make release test cycles now on my
machines (amd64,i386,zaurus,sparc,sparc64,hppa) (with various settings
of bufcachepercent) and is running on my NFS server
(bufcachepercent=90) without any complaints throughout that - it's
been running on my laptop for a long time now.
If you try it, and have troubles (i.e. any new regressions), please
ensure you have your machine's console accessible (check to see if you
have ddb.console=1 in /etc/sysctl.conf) and if you have problems
please try to get
trace
ps
show bcstats
show uvm
from ddb if at all possible.
Please let me know how you do with it, and most importantly what
you try it on/with.
-Bob
(diff also in ~beck/viagra.diff6 on cvs)
Index: sys/kern/kern_sysctl.c
===
RCS file: /cvs/src/sys/kern/kern_sysctl.c,v
retrieving revision 1.231
diff -u -p -r1.231 kern_sysctl.c
--- sys/kern/kern_sysctl.c 11 Feb 2013 11:11:42 - 1.231
+++ sys/kern/kern_sysctl.c 4 Mar 2013 23:00:45 -
@@ -110,6 +110,7 @@ extern struct disklist_head disklist;
extern fixpt_t ccpu;
extern long numvnodes;
extern u_int mcllivelocks;
+extern psize_t b_dmapages_total, b_highpages_total, b_dmamaxpages;
extern void nmbclust_update(void);
@@ -565,8 +566,8 @@ kern_sysctl(int *name, u_int namelen, vo
return (sysctl_int(oldp, oldlenp, newp, newlen,
rthreads_enabled));
case KERN_CACHEPCT: {
- u_int64_t dmapages;
- int opct, pgs;
+ psize_t pgs;
+ int opct;
opct = bufcachepercent;
error = sysctl_int(oldp, oldlenp, newp, newlen,
bufcachepercent);
@@ -576,9 +577,11 @@ kern_sysctl(int *name, u_int namelen, vo
bufcachepercent = opct;
return (EINVAL);
}
- dmapages = uvm_pagecount(dma_constraint);
if (bufcachepercent != opct) {
- pgs = bufcachepercent * dmapages / 100;
+ pgs = (b_highpages_total + b_dmapages_total)
+ * bufcachepercent / 100;
+ b_dmamaxpages = b_dmapages_total * bufcachepercent
+ / 100;
bufadjust(pgs); /* adjust bufpages */
bufhighpages = bufpages; /* set high water mark */
}
Index: sys/kern/spec_vnops.c
===
RCS file: /cvs/src/sys/kern/spec_vnops.c,v
retrieving revision 1.69
diff -u -p -r1.69 spec_vnops.c
--- sys/kern/spec_vnops.c 20 Jun 2012 17:30:22 - 1.69
+++ sys/kern/spec_vnops.c 10 Feb 2013 19:04:12 -
@@ -457,7 +457,9 @@ spec_strategy(void *v)
struct vop_strategy_args *ap = v;
struct buf *bp = ap-a_bp;
int maj = major(bp-b_dev);
-
+
+ if (!ISSET(bp-b_flags, B_DAQ) ISSET(bp-b_flags, B_BC))
+ panic(bogus buf %p passed to spec_strategy, bp);
if (LIST_FIRST(bp-b_dep) != NULL)
buf_start(bp);
Index: sys/kern/vfs_bio.c
===
RCS file: /cvs/src/sys/kern/vfs_bio.c,v
retrieving revision 1.146
diff -u -p -r1.146 vfs_bio.c
--- sys/kern/vfs_bio.c 17 Feb 2013 17:39:29 - 1.146
+++ sys/kern/vfs_bio.c 4 Mar 2013 23:00:45 -
@@ -69,6 +69,10 @@
#defineBQ_CLEAN1 /* LRU queue with clean buffers
*/
TAILQ_HEAD(bqueues, buf) bufqueues[BQUEUES];
+TAILQ_HEAD(bqda, buf) bufqueue_da;
+struct uvm_constraint_range high_constraint;
+psize_t b_dmapages_total, b_highpages_total, b_dmamaxpages;
+int needda;
int nobuffers;
int needbuffer;
struct bio_ops bioops;
@@ -157,8 +161,12 @@ buf_put(struct buf *bp)
LIST_REMOVE(bp, b_list);
bcstats.numbufs--;
+ if (ISSET(bp-b_flags, B_DAQ)) {
+ TAILQ_REMOVE(bufqueue_da, bp, b_qda);
+ CLR(bp-b_flags, B_DAQ);
+ }
if (buf_dealloc_mem(bp) != 0)
- return;
+return;
pool_put(bufpool, bp);
}
@@ -168,12 +176,21 @@ buf_put(struct
PF divert(4) bugfix: recalculate checksums on packet reinjection
Brief background: divert(4) sockets can be used to send packets to a
userspace program. The program can inspect the packets and decide to
either reinject them back into the kernel or drop them.
According to the divert(4) man page, The packets' checksums are
recalculated upon reinjection. This makes sense, because the userspace
program could have modified the packet.
However, in my tests, I found that the checksums are not actually
recalculated upon reinjection. I ran into this bug when trying to use
divert-packet PF rules together with nat-to and rdr-to, e.g.:
match out on em5 inet nat-to (em5:0)
pass out on em5 proto tcp to port 80 divert-packet port 700
pass in on em5 proto tcp to port 22 divert-packet port 700 rdr-to
192.168.30.8
With the above rules, inbound packets would drop and netstat -p ip -s
shows that bad header checksums consistently increments by one for
every inbound packet.
The diff below fixes this bug by making divert(4) recalculate the IP(v4)
and TCP/UDP/ICMP/ICMPv6 checksums of reinjected packets on both IPv4 and
IPv6 (done with a ton of help and feedback from blambert@ who reviewed
many versions of this diff, thank you!).
If you are using divert(4), could you please test this diff to ensure
that it does not break your setup? Note that this diff only applies to
divert-packet PF rules, not divert-to/divert-reply.
I am also looking for feedback from developers to review the approach
and code that was used to fix this bug.
Thank you,
Lawrence
Index: netinet/ip_divert.c
===
RCS file: /cvs/src/sys/netinet/ip_divert.c,v
retrieving revision 1.10
diff -u -p -r1.10 ip_divert.c
--- netinet/ip_divert.c 21 Oct 2012 13:06:03 - 1.10
+++ netinet/ip_divert.c 4 Mar 2013 16:14:33 -
@@ -37,6 +37,9 @@
#include netinet/ip_var.h
#include netinet/in_pcb.h
#include netinet/ip_divert.h
+#include netinet/tcp.h
+#include netinet/udp.h
+#include netinet/ip_icmp.h
struct inpcbtable divbtable;
struct divstat divstat;
@@ -83,8 +86,12 @@ divert_output(struct mbuf *m, ...)
struct sockaddr_in *sin;
struct socket *so;
struct ifaddr *ifa;
- int s, error = 0;
+ int s, error = 0, p_hdrlen = 0;
va_list ap;
+ struct ip *ip;
+ u_int16_t off, csum = 0;
+ u_int8_t nxt;
+ size_t p_off = 0;
va_start(ap, m);
inp = va_arg(ap, struct inpcb *);
@@ -102,15 +109,68 @@ divert_output(struct mbuf *m, ...)
sin = mtod(nam, struct sockaddr_in *);
so = inp-inp_socket;
+ /* Do basic sanity checks. */
+ if (m-m_pkthdr.len sizeof(struct ip))
+ goto fail;
+ if ((m = m_pullup(m, sizeof(struct ip))) == NULL) {
+ /* m_pullup() has freed the mbuf, so just return. */
+ divstat.divs_errors++;
+ return (ENOBUFS);
+ }
+ ip = mtod(m, struct ip *);
+ if (ip-ip_v != IPVERSION)
+ goto fail;
+ off = ip-ip_hl 2;
+ if (off sizeof(struct ip) || ntohs(ip-ip_len) off ||
+ m-m_pkthdr.len ntohs(ip-ip_len))
+ goto fail;
+
+ /*
+* Recalculate IP and protocol checksums since the userspace application
+* may have modified the packet prior to reinjection.
+*/
+ ip-ip_sum = 0;
+ ip-ip_sum = in_cksum(m, off);
+ nxt = ip-ip_p;
+ switch (ip-ip_p) {
+ case IPPROTO_TCP:
+ p_hdrlen = sizeof(struct tcphdr);
+ p_off = offsetof(struct tcphdr, th_sum);
+ break;
+ case IPPROTO_UDP:
+ p_hdrlen = sizeof(struct udphdr);
+ p_off = offsetof(struct udphdr, uh_sum);
+ break;
+ case IPPROTO_ICMP:
+ p_hdrlen = sizeof(struct icmp);
+ p_off = offsetof(struct icmp, icmp_cksum);
+ nxt = 0;
+ break;
+ default:
+ /* nothing */
+ break;
+ }
+ if (p_hdrlen) {
+ if (m-m_pkthdr.len off + p_hdrlen)
+ goto fail;
+
+ if ((error = m_copyback(m, off + p_off, sizeof(csum), csum,
M_NOWAIT)))
+ goto fail;
+ csum = in4_cksum(m, nxt, off, m-m_pkthdr.len - off);
+ if (ip-ip_p == IPPROTO_UDP csum == 0)
+ csum = 0x;
+ if ((error = m_copyback(m, off + p_off, sizeof(csum), csum,
M_NOWAIT)))
+ goto fail;
+ }
+
m-m_pkthdr.pf.flags |= PF_TAG_DIVERTED_PACKET;
if (sin-sin_addr.s_addr != INADDR_ANY) {
ipaddr.sin_addr = sin-sin_addr;
ifa = ifa_ifwithaddr(sintosa(ipaddr), m-m_pkthdr.rdomain);
if (ifa == NULL) {
- divstat.divs_errors++;
- m_freem(m);
- return (EADDRNOTAVAIL);
+ error =
Re: write(2) man page
On 02/24/2013 05:34 PM, Sachidananda wrote: Ted, On Sunday 24 February 2013 10:10 AM, Ted Unangst wrote: On Sun, Feb 24, 2013 at 09:12, Sachidananda wrote: Also, for the record, it's open that seeks to the end. You can open a file with O_APPEND and seek back to the beginning, and write will not seek to the end again. My observation is, if I open(2) the file with O_APPEND it seeks to the end. And I lseek back to the beginning and write(2) to it, write does seek back to the end and write the data at the end. No, I apologize. I'm the one who's wrong. The O_APPEND flag is sticky, and continues to affect the file even after seeking. This probably is worth documenting. The current write man page is misleading, even. Checking the source, pwrite is not affected by the flag. That'd be worth mentioning too. Attaching patch for review. Hi, Any thoughts on this? -sac
Re: touch(1) doesn't act as expected: One for JMC
On Mon, Mar 04, 2013 at 10:19:11PM +1100, Rod Whitworth wrote: Snip from the manpage describing the format used to apply a date to a file: ccyy Year. mm Month: a number from 1 to 12. dd Day: a number from 1 to 31. T Either the capital letter `T' or a single space. HH Hour: a number from 0 to 23. MM Minute: a number from 0 to 59. SS Second: a number from 0 to 60 (permitting a leap second). Result of using a single space instead of T: # touch -d 2013-03-01 12:34:56 test touch: out of range or illegal time specification: -MM-DDThh:mm:ss[.frac][Z] Of course it is obvious to experienced hands that the space needs to be escaped but it's not so obvious to beginners. Particularly when the documentation shows the same string in the syntax as is shown in the error message - always with the T. I told the victim to pretend that the T was the only valid char in that space because it's easier to type one char than two. jmc, care to comment? i don;t much like describing shell behaviour in other pages, but we do do it in other pages, and i agree this one seems particularly likely to catch folks out. fix coming... jmc
