Serial console on Sunix 40XX (PCI)
I'm trying to setup a serial console. My RS-232 is an old PCIcard.
I tried this way:
boot> set tty com4
/etc/ttys:
tty00 "/usr/libexec/getty std.9600" vt220 on secure
tty04 "/usr/libexec/getty std.9600" vt220 on secure
but can't connect to console and the system doesn't boot.
What am I doing wrong?
# dmesg
OpenBSD 5.6 (GENERIC.MP) #1: Wed Feb 11 11:23:16 CET 2015
r...@samba56.prac:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz ("GenuineIntel" 686-class) 3.38 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,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,LAHF,PERF,ITSC
real mem = 3487911936 (3326MB)
avail mem = 3418468352 (3260MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 08/24/10, BIOS32 rev. 0 @ 0xfa810, SMBIOS
rev. 2.4 @ 0xf0100 (39 entries)
bios0: vendor Award Software International, Inc. version "F2" date 08/24/2010
bios0: Gigabyte Technology Co., Ltd. X58-USB3
acpi0 at bios0: rev 0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP MCFG EUDS MATS TAMG APIC SSDT
acpi0: wakeup devices PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) PEX5(S5)
HUB0(S5) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) USBE(S3)
USE2(S3) AZAL(S5) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0 addr 0xf000, bus 0-63
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 134MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.0, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz ("GenuineIntel" 686-class) 3.24 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,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,LAHF,PERF,ITSC
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz ("GenuineIntel" 686-class) 3.24 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,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,LAHF,PERF,ITSC
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz ("GenuineIntel" 686-class) 3.24 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,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,LAHF,PERF,ITSC
cpu4 at mainbus0: apid 1 (application processor)
cpu4: Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz ("GenuineIntel" 686-class) 3.24 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,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,LAHF,PERF,ITSC
cpu5 at mainbus0: apid 3 (application processor)
cpu5: Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz ("GenuineIntel" 686-class) 3.24 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,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,LAHF,PERF,ITSC
cpu6 at mainbus0: apid 5 (application processor)
cpu6: Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz ("GenuineIntel" 686-class) 3.24 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,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,LAHF,PERF,ITSC
cpu7 at mainbus0: apid 7 (application processor)
cpu7: Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz ("GenuineIntel" 686-class) 3.24 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,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,LAHF,PERF,ITSC
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 2
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEX0)
acpiprt2 at acpi0: bus -1 (PEX1)
acpiprt3 at acpi0: bus -1 (PEX2)
acpiprt4 at acpi0: bus -1 (PEX3)
acpiprt5 at acpi0: bus -1 (PEX4)
acpiprt6 at acpi0: bus -1 (PEX5)
acpiprt7 at acpi0: bus 4 (HUB0)
acpicpu0 at acpi0: PSS
acpicpu1 at acpi0: PSS
acpicpu2 at acpi0: PSS
acpicpu3 at acpi0: PSS
acpicpu4 at acpi0: PSS
acpicpu5 at acpi0: PSS
acpicpu6 at acpi0: PSS
acpicpu7 at acpi0: PSS
acpibtn0 at acpi0: PWRB
bios0: ROM list: 0xc/0xe400! 0xd/0x2a00!
cpu0: Enhanced SpeedStep 3239 MHz: speeds: 3193, 3192, 3059, 2926, 2793, 2660,
2527, 2394, 2261, 2128, 1995, 1862,
pf on 5.6: rule counter with proto esp not working
Hi, I failed to setup a queue on outgoing esp traffic and noticed that the rule counters are all 0 and do not advance: @155 pass out quick on vlan2 inet proto esp from any to set ( queue vpn ) keep state (if-bound) [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 28769 State Creations: 0 ] This is the IPSEC gateway. On the IPSEC client, it works: @284 pass in quick on pppoe0 inet proto esp from some.gateway to (pppoe0:1) keep state (if-bound) [ Evaluations: 434 Packets: 11134879 Bytes: 8621504380 States: 1 ] [ Inserted: uid 0 pid 2528 State Creations: 1 ] I could not find any preceding rule with proto esp (or empty proto). What am I doing wrong? Axel PS: Cross posted from p...@benzedrine.cx, where mail did not show up --- PGP-Key:29E99DD6 ☀ +49 151 2300 9283 ☀ computing @ chaos claudius
Re: Installing OpenBSD 5.6 using a USB Flash drive
Did anyone install OpenBSD 5.6 from a USB Flash drive? Please help... > From: afyous...@hotmail.com > To: misc@openbsd.org > Subject: Re: Installing OpenBSD 5.6 using a USB Flash drive > Date: Sat, 14 Feb 2015 19:30:05 + > > Ok, I did. > Please let me know if it works. > > > To: afyous...@hotmail.com > > Subject: Re: Installing OpenBSD 5.6 using a USB Flash drive > > From: pe...@bsdly.net > > Date: Sat, 14 Feb 2015 20:15:04 +0100 > > > > A Y writes: > > > > > I only click on the 'reply' tab, in outlook.com, to reply. Isn't > > > this what I am supposed to do? This is my very first email, so, I > > > guess, there is much to learn. > > > > See if there isn't a Cc: field or something similar. Or simply type > > misc@openbsd.org in place of my address. > > > > - P > > > > -- > > Peter N. M. Hansteen, member of the first RFC 1149 implementation team > > http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ > > "Remember to set the evil bit on all malicious network traffic" > > delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: postgresql-server exiting abnormally after upgrade to -snapshot
On 2015-02-15, Hugo Osvaldo Barrera wrote: > > Am I mistaken in understanding that this is an issue with postgresql itself, > and not a local configuration error? Correct. > I tried building postgres with debug symbols (I added the flags described > here[1] to the ports Makefile), but the backtrace is still useless: Please would you rebuild from the original port like this: make clean=all make DEBUG="-O0 -g" repackage && sudo make reinstall and see if this gives a better backtrace.
Re: Installing OpenBSD 5.6 using a USB Flash drive
Am 2015-02-16 15:36, schrieb A Y: Did anyone install OpenBSD 5.6 from a USB Flash drive? Please help... You have already booted from drive, now you only need to select this drive device during installation. You need help exactly with what?
Any experience with D-Link DGS-1100 and static trunk aggregation?
I've just ordered a D-Link DGS-1100 series low-end managed switch and am wondering if anyone has used one of these with either a roundrobin or loadbalance trunk(4) configuration. The DGS-1200 series supports LACP, but the 1100 only supports an undefined "static trunk aggregation" method. The CAVEATS section of trunk(4) states that roundrobin and loadbalance require 802.3ad static link aggregation. D-Link excluded 802.3ad from its list of standards for this switch, but that may be to avoid customer confusion as 802.3ad is also LACP. It is my understanding [1] that this switch usesthe Realtek rtl8389m controller. In 2006 years ago, Reyk mentioned [2] that most of the switches that then supported static trunking methods were using loadbalance-friendly mechanisms. But I perceive this to be a significantly lower-end switch. Has anyone deployed an aggregation trunk with one of these things? -- [1] http://andreas.jakum.net/blog/2012/10/27/new-switch-d-link-dgs-1100-16 [2] http://marc.info/?l=openbsd-misc&m=114842183400156
Re: Anybody replace the disk drive in a Lemote Fuloong?
On Mon, Jan 26, 2015 at 02:28:35PM +0100, Otto Moerbeek wrote: > Unscrew the four screws on the side VGA connector side. Slide the > logic board out. Unscrew the three black screws that hold the disk > bracket. The screws are unmarked but they are near R164, C174 and U32. > You can then slide the disk and bracket out of the connector. Replace > the disk in the bracket and reverse the steps. It's a 5 minute job when somebody points out which screws are the right ones and you find the right tiny screwdriver. Back on the air! Thanks, Otto! /jl -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary/ \http://www.mutt.org attachments / \ Code Blue or Go Home! Encrypted email preferred PGP Key 2048R/DA65BC04
autoinstall + sitexx-hostname.tgz
Hi, i am using pxe boot with autoinstall and a hostname specific tgz file in the sets to deploy many similar Firewalls. i tell the installer how to configure at least one nic, to download the sets. i use dhcp for that. after that everything works as expected until the install is done and machine restarts. in my custom site57-fw1.tgz is a /etc/hostname.vio0. it says "up". i was wondering why in the filesystem of fw1 /etc/hostname.vio0 says "dhcp". i can only think the installer filling the file, after my site.tgz gets extracted. i am not absolutely sure if that's whats happening but if that's the case i'm not sure if that is intended behavior. i could of course add another nic just for pxe booting or put something in the install.site script, but maybe there is a better solution. Jan
Re: Any experience with D-Link DGS-1100 and static trunk aggregation?
On 2015-02-16, Josh Grosse wrote: > I've just ordered a D-Link DGS-1100 series low-end managed switch and > am wondering if anyone has used one of these with either a roundrobin > or loadbalance trunk(4) configuration. Not this particular switch, but there isn't much that can go wrong with statically configured link aggregation like this. If it's like the earlier D-Link web-managed switch that I had, it might be fussy about the browser used to configure it, if you have problems then try Firefox.
Re: postgresql-server exiting abnormally after upgrade to -snapshot
On 2015-02-16 16:24, Stuart Henderson wrote: > On 2015-02-15, Hugo Osvaldo Barrera wrote: > > > > Am I mistaken in understanding that this is an issue with postgresql itself, > > and not a local configuration error? > > Correct. > > > I tried building postgres with debug symbols (I added the flags described > > here[1] to the ports Makefile), but the backtrace is still useless: > > Please would you rebuild from the original port like this: > > make clean=all > make DEBUG="-O0 -g" repackage && sudo make reinstall > > and see if this gives a better backtrace. > Thanks a lot, it did. I was unaware of make DEBUG, and had been editing the Makefile with no success. (gdb) bt #0 0x110a2815b92a in kill () at :2 #1 0x110a28195119 in abort () at /usr/src/lib/libc/stdlib/abort.c:53 #2 0x110a2816a238 in memcpy (dst0=0xfb8d4, src0=0x6, length=0) at /usr/src/lib/libc/string/memcpy.c:65 #3 0x11080cf8d1b1 in check_ip (raddr=0x110a899f7918, addr=0x110a899f9058, mask=0x110a899f9158) at hba.c:704 #4 0x11080cf90a04 in check_hba (port=0x110a899f7800) at hba.c:1718 #5 0x11080cf91d34 in hba_getauthmethod (port=0x110a899f7800) at hba.c:2256 #6 0x11080cf88eb3 in ClientAuthentication (port=0x110a899f7800) at auth.c:307 #7 0x11080d1edf5d in PerformAuthentication (port=0x110a899f7800) at postinit.c:223 #8 0x11080d1eeae7 in InitPostgres (in_dbname=0x110af4508c00 "virtstart-dev", dboid=0, username=0x110af4508be0 "virtstart-dev", out_dbname=0x0) at postinit.c:688 #9 0x11080d0a3eb1 in PostgresMain (argc=1, argv=0x110af4508c20, dbname=0x110af4508c00 "virtstart-dev", username=0x110af4508be0 "virtstart-dev") at postgres.c:3749 #10 0x11080d033537 in BackendRun (port=Could not find the frame base for "BackendRun". ) at postmaster.c:4155 #11 0x11080d032be8 in BackendStartup (port=0x110a899f7800) at postmaster.c:3829 #12 0x11080d02f2d0 in ServerLoop () at postmaster.c:1597 #13 0x11080d02e968 in PostmasterMain (argc=3, argv=0x7f7d9658) at postmaster.c:1244 #14 0x11080cf96dc8 in main (argc=Could not find the frame base for "main". ) at main.c:228 Current language: auto; currently asm This doesn't say much to me though. I guess my best shot is to post this at the postgresql list, right? Thanks, -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: postgresql-server exiting abnormally after upgrade to -snapshot
On 2015/02/16 17:19, Hugo Osvaldo Barrera wrote: > (gdb) bt Was this backtrace from a new coredump, or was it from one created by the old binary? (if the latter, please could you remove the old coredump and get it to crash again and send a fresh backtrace?)
Re: postgresql-server exiting abnormally after upgrade to -snapshot
On 2015-02-16 21:02, Stuart Henderson wrote: > On 2015/02/16 17:19, Hugo Osvaldo Barrera wrote: > > (gdb) bt > > Was this backtrace from a new coredump, or was it from one created by > the old binary? (if the latter, please could you remove the old coredump > and get it to crash again and send a fresh backtrace?) > My pg_hba is the stock one (since it had also been deleted): http://sprunge.us/ZdQI It was a brand-new core dump, since I had deleted /var/postgresql right before generating it. I regenerated it just to be sure, and it's the same: (gdb) bt #0 0x110a2815b92a in kill () at :2 #1 0x110a28195119 in abort () at /usr/src/lib/libc/stdlib/abort.c:53 #2 0x110a2816a238 in memcpy (dst0=0xf81bf, src0=0x6, length=0) at /usr/src/lib/libc/string/memcpy.c:65 #3 0x11080cf8d1b1 in check_ip (raddr=0x110abc279918, addr=0x110a899f9058, mask=0x110a899f9158) at hba.c:704 #4 0x11080cf90a04 in check_hba (port=0x110abc279800) at hba.c:1718 #5 0x11080cf91d34 in hba_getauthmethod (port=0x110abc279800) at hba.c:2256 #6 0x11080cf88eb3 in ClientAuthentication (port=0x110abc279800) at auth.c:307 #7 0x11080d1edf5d in PerformAuthentication (port=0x110abc279800) at postinit.c:223 #8 0x11080d1eeae7 in InitPostgres (in_dbname=0x110ad7782be0 "virtstart-dev", dboid=0, username=0x110ad7782bc0 "virtstart-dev", out_dbname=0x0) at postinit.c:688 #9 0x11080d0a3eb1 in PostgresMain (argc=1, argv=0x110ad7782c00, dbname=0x110ad7782be0 "virtstart-dev", username=0x110ad7782bc0 "virtstart-dev") at postgres.c:3749 #10 0x11080d033537 in BackendRun (port=Could not find the frame base for "BackendRun". ) at postmaster.c:4155 #11 0x11080d032be8 in BackendStartup (port=0x110abc279800) at postmaster.c:3829 #12 0x11080d02f2d0 in ServerLoop () at postmaster.c:1597 #13 0x11080d02e968 in PostmasterMain (argc=3, argv=0x7f7d9658) at postmaster.c:1244 #14 0x11080cf96dc8 in main (argc=Could not find the frame base for "main". ) at main.c:228 Current language: auto; currently asm Thanks, -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: postgresql-server exiting abnormally after upgrade to -snapshot
On 2015-02-16 20:44, Stuart Henderson wrote: > > Thanks a lot, it did. I was unaware of make DEBUG, and had been editing the > > Makefile with no success. > > The missing piece is that, normally, binaries get stripped of their > debug symbols in the "fake install" stage. Passing the flags in via DEBUG > (in most cases) avoids this step. > > Could you let me have a copy of your pg_hba.conf please? Looking at the > trace and code it's a bit odd and I'd like to try and replicate it here if > I can .. > After submitting the backtrace upstream (eg: to the pgsql list), it would seem that it's an issue on the postgres codebase, triggered by the OpenBSD upgrade (apparently), but nonetheless an issue in pg itself: http://www.postgresql.org/message-id/16513.1424120...@sss.pgh.pa.us I'll post back (for posterity's sake) once I have a permanent fix. Thanks a bunch for helping be track the issue down and getting a proper backtrace. -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: postgresql-server exiting abnormally after upgrade to -snapshot
On 2015/02/16 21:02, Stuart Henderson wrote: > On 2015/02/16 17:19, Hugo Osvaldo Barrera wrote: > > (gdb) bt > > Was this backtrace from a new coredump, or was it from one created by > the old binary? (if the latter, please could you remove the old coredump > and get it to crash again and send a fresh backtrace?) > OK, replicated it here now...
Re: postgresql-server exiting abnormally after upgrade to -snapshot
On Mon, Feb 16, 2015 at 2:19 PM, Hugo Osvaldo Barrera wrote: > On 2015-02-16 16:24, Stuart Henderson wrote: > > On 2015-02-15, Hugo Osvaldo Barrera wrote: > > > > > > Am I mistaken in understanding that this is an issue with postgresql > itself, > > > and not a local configuration error? > > > > Correct. > > > > > I tried building postgres with debug symbols (I added the flags > described > > > here[1] to the ports Makefile), but the backtrace is still useless: > > > > Please would you rebuild from the original port like this: > > > > make clean=all > > make DEBUG="-O0 -g" repackage && sudo make reinstall > > > > and see if this gives a better backtrace. > > > > Thanks a lot, it did. I was unaware of make DEBUG, and had been editing the > Makefile with no success. > > (gdb) bt > #0 0x110a2815b92a in kill () at :2 > #1 0x110a28195119 in abort () at /usr/src/lib/libc/stdlib/abort.c:53 > #2 0x110a2816a238 in memcpy (dst0=0xfb8d4, src0=0x6, length=0) at > /usr/src/lib/libc/string/memcpy.c:65 > #3 0x11080cf8d1b1 in check_ip (raddr=0x110a899f7918, > addr=0x110a899f9058, mask=0x110a899f9158) at hba.c:704 > #4 0x11080cf90a04 in check_hba (port=0x110a899f7800) at hba.c:1718 > #5 0x11080cf91d34 in hba_getauthmethod (port=0x110a899f7800) at > hba.c:2256 > #6 0x11080cf88eb3 in ClientAuthentication (port=0x110a899f7800) at > auth.c:307 > #7 0x11080d1edf5d in PerformAuthentication (port=0x110a899f7800) at > postinit.c:223 > #8 0x11080d1eeae7 in InitPostgres (in_dbname=0x110af4508c00 > "virtstart-dev", dboid=0, > username=0x110af4508be0 "virtstart-dev", out_dbname=0x0) at > postinit.c:688 > #9 0x11080d0a3eb1 in PostgresMain (argc=1, argv=0x110af4508c20, > dbname=0x110af4508c00 "virtstart-dev", > username=0x110af4508be0 "virtstart-dev") at postgres.c:3749 > #10 0x11080d033537 in BackendRun (port=Could not find the frame base > for > "BackendRun". > ) at postmaster.c:4155 > #11 0x11080d032be8 in BackendStartup (port=0x110a899f7800) at > postmaster.c:3829 > #12 0x11080d02f2d0 in ServerLoop () at postmaster.c:1597 > #13 0x11080d02e968 in PostmasterMain (argc=3, argv=0x7f7d9658) at > postmaster.c:1244 > #14 0x11080cf96dc8 in main (argc=Could not find the frame base for > "main". > ) at main.c:228 > Current language: auto; currently asm > > This doesn't say much to me though. I guess my best shot is to post this at > the > postgresql list, right? > > Thanks, > http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/libpq/hba.c;h=9cde6a21ce99003102dc9303288001d24e3ba2b6;hb=HEAD#l703 One of these are the offending lines... Refer to http://www.tedunangst.com/flak/post/memcpy-vs-memmove Guys, please correct me if I am wrong. There might be more such bugs in postgres, not sure why others are not hitting those.
Re: postgresql-server exiting abnormally after upgrade to -snapshot
Please try the diff below. It fixes the "backwards memcpy" problem easily noticeable with psql -h ::1. $OpenBSD$ --- src/backend/libpq/hba.c.origMon Feb 16 21:53:21 2015 +++ src/backend/libpq/hba.c Mon Feb 16 21:54:44 2015 @@ -700,8 +700,8 @@ check_ip(SockAddr *raddr, struct sockaddr * addr, stru struct sockaddr_storage addrcopy, maskcopy; - memcpy(&addrcopy, &addr, sizeof(addrcopy)); - memcpy(&maskcopy, &mask, sizeof(maskcopy)); + memcpy(&addrcopy, addr, addr->sa_len); + memcpy(&maskcopy, mask, mask->sa_len); pg_promote_v4_to_v6_addr(&addrcopy); pg_promote_v4_to_v6_mask(&maskcopy); -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: postgresql-server exiting abnormally after upgrade to -snapshot
j...@wxcvbn.org (Jérémie Courrèges-Anglas) writes: > Please try the diff below. It fixes the "backwards memcpy" problem > easily noticeable with psql -h ::1. Updated diff. Thanks to Stuart for reminding me that netmasks sa_len values can be much surprising. $OpenBSD$ --- src/backend/libpq/hba.c.origMon Feb 16 21:53:21 2015 +++ src/backend/libpq/hba.c Mon Feb 16 23:08:38 2015 @@ -700,8 +700,13 @@ check_ip(SockAddr *raddr, struct sockaddr * addr, stru struct sockaddr_storage addrcopy, maskcopy; - memcpy(&addrcopy, &addr, sizeof(addrcopy)); - memcpy(&maskcopy, &mask, sizeof(maskcopy)); + memcpy(&addrcopy, addr, sizeof(struct sockaddr_in)); + /* +* On some OSes, if mask is obtained from eg. getifaddrs(3), sa_len +* can vary wildly. We already know that addr->sa_family == AF_INET, +* so just use sizeof(struct sockaddr_in). +*/ + memcpy(&maskcopy, mask, sizeof(struct sockaddr_in)); pg_promote_v4_to_v6_addr(&addrcopy); pg_promote_v4_to_v6_mask(&maskcopy); -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Any experience with D-Link DGS-1100 and static trunk aggregation?
On 2015-02-16 14:43, Stuart Henderson wrote: On 2015-02-16, Josh Grosse wrote: I've just ordered a D-Link DGS-1100 series low-end managed switch and am wondering if anyone has used one of these with either a roundrobin or loadbalance trunk(4) configuration. Not this particular switch, but there isn't much that can go wrong with statically configured link aggregation like this. If it's like the earlier D-Link web-managed switch that I had, it might be fussy about the browser used to configure it, if you have problems then try Firefox. Thanks, Stuart. I'll breathe easier. The Manual I found at their website listed a whole bunch of standard browsers by name and release, so I'm not worried regarding the management interface. (I've also discovered a "B" version of the hardware exists, which is a completely different switch, and supports STP and LACP. With a lot of luck, my supplier might have shipped the "B" variant to me.
Re: postgresql-server exiting abnormally after upgrade to -snapshot
worked out with jca and lteo, this fixes this issue (which only occurs
when there's an ipv6 connection) for me.
Index: Makefile
===
RCS file: /cvs/ports/databases/postgresql/Makefile,v
retrieving revision 1.198
diff -u -p -r1.198 Makefile
--- Makefile6 Feb 2015 09:01:21 - 1.198
+++ Makefile16 Feb 2015 22:37:23 -
@@ -10,6 +10,7 @@ COMMENT-plpython=Python procedural langu
# in case a dump before / restore after pkg_add -u is required!
VERSION= 9.4.1
+REVISION-server= 0
DISTNAME= postgresql-${VERSION}
PKGNAME-main= postgresql-client-${VERSION}
PKGNAME-server=postgresql-server-${VERSION}
Index: patches/patch-src_backend_libpq_hba_c
===
RCS file: patches/patch-src_backend_libpq_hba_c
diff -N patches/patch-src_backend_libpq_hba_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_backend_libpq_hba_c 16 Feb 2015 22:37:23 -
@@ -0,0 +1,21 @@
+$OpenBSD$
+
+Fix crash when connecting over IPv6. "backwards memcpy" logged but it's worse.
+Don't copy the whole space for a sockaddr_storage, at this point in the
+code the addr/mask are known to be a sockaddr_in. Not using sa_len because
+in some cases mask->sa_len is too short (suspect this may be an issue
+related to http://marc.info/?l=openbsd-tech&m=138089192205849&w=2).
+
+--- src/backend/libpq/hba.c.orig Mon Feb 2 20:42:55 2015
src/backend/libpq/hba.cMon Feb 16 22:13:26 2015
+@@ -700,8 +700,8 @@ check_ip(SockAddr *raddr, struct sockaddr * addr, stru
+ struct sockaddr_storage addrcopy,
+ maskcopy;
+
+- memcpy(&addrcopy, &addr, sizeof(addrcopy));
+- memcpy(&maskcopy, &mask, sizeof(maskcopy));
++ memcpy(&addrcopy, addr, sizeof(struct sockaddr_in));
++ memcpy(&maskcopy, mask, sizeof(struct sockaddr_in));
+ pg_promote_v4_to_v6_addr(&addrcopy);
+ pg_promote_v4_to_v6_mask(&maskcopy);
+
Re: postgresql-server exiting abnormally after upgrade to -snapshot
Jérémie Courrèges-Anglas wrote: > Please try the diff below. It fixes the "backwards memcpy" problem > easily noticeable with psql -h ::1. > > $OpenBSD$ > --- src/backend/libpq/hba.c.orig Mon Feb 16 21:53:21 2015 > +++ src/backend/libpq/hba.c Mon Feb 16 21:54:44 2015 > @@ -700,8 +700,8 @@ check_ip(SockAddr *raddr, struct sockaddr * addr, stru > struct sockaddr_storage addrcopy, > maskcopy; > > - memcpy(&addrcopy, &addr, sizeof(addrcopy)); > - memcpy(&maskcopy, &mask, sizeof(maskcopy)); > + memcpy(&addrcopy, addr, addr->sa_len); > + memcpy(&maskcopy, mask, mask->sa_len); > pg_promote_v4_to_v6_addr(&addrcopy); > pg_promote_v4_to_v6_mask(&maskcopy); How did this ever work? You're changing the source too. This isn't just a "backwards" memcpy, it was an overflow.
Re: postgresql-server exiting abnormally after upgrade to -snapshot
On 2015-02-16 23:21, Jérémie Courrèges-Anglas wrote: > j...@wxcvbn.org (Jérémie Courrèges-Anglas) writes: > > > Please try the diff below. It fixes the "backwards memcpy" problem > > easily noticeable with psql -h ::1. > > Updated diff. Thanks to Stuart for reminding me that netmasks sa_len > values can be much surprising. > > $OpenBSD$ > --- src/backend/libpq/hba.c.orig Mon Feb 16 21:53:21 2015 > +++ src/backend/libpq/hba.c Mon Feb 16 23:08:38 2015 > @@ -700,8 +700,13 @@ check_ip(SockAddr *raddr, struct sockaddr * addr, stru > struct sockaddr_storage addrcopy, > maskcopy; > > - memcpy(&addrcopy, &addr, sizeof(addrcopy)); > - memcpy(&maskcopy, &mask, sizeof(maskcopy)); > + memcpy(&addrcopy, addr, sizeof(struct sockaddr_in)); > + /* > + * On some OSes, if mask is obtained from eg. getifaddrs(3), > sa_len > + * can vary wildly. We already know that addr->sa_family == > AF_INET, > + * so just use sizeof(struct sockaddr_in). > + */ > + memcpy(&maskcopy, mask, sizeof(struct sockaddr_in)); > pg_promote_v4_to_v6_addr(&addrcopy); > pg_promote_v4_to_v6_mask(&maskcopy); > I can confirm that this works. The server has been up and running with no issues during a few hours. Will anybody be submiting this upstream? Thanks for all your help! -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Clonable BPF diff
Hi, I was pointed to a diff that was posted on tech@ a couple of years back by sthen@ which was created by mikeb@, there was a brief discussion regarding the patch & then nothing, I was wondering if it's worth revisiting / continuing the dialogue to reach a conclusion. http://marc.info/?t=13540511943&r=1&w=3 The discussion came about through me discovering that if your device nodes are not numbered sequentially, processes which rely on those device nodes fail to start, in this case I'd somehow managed to screw up how i'd invoked jot when creating additional bpf(4) nodes to cover the requirements for dhcpd to bind to all necessary interfaces. Functionality like this would be cool to have as it's one less thing that needs to be handled on a new build. Regards, Sevan / Venture37
