Re: sparc64/ binary packages (pkg_add) linked on wrong libraries
My bad, I just realized I was on -current. Please ignore my submission earlier today. Thank you, Michel
sparc64/ binary packages (pkg_add) linked on wrong libraries
>Synopsis: pkg_add doesn't work on 5.8/sparc64, argues about >missing libs >Category: system library sparc64 >Environment: System : OpenBSD 5.8 Details : OpenBSD 5.8-current (GENERIC.MP) #830: Wed Nov 11 12:48:03 MST 2015 dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/GENERIC.MP Architecture: OpenBSD.sparc64 Machine : sparc64 >Description: Here I tried "pkg_add curl": # pkg_add curl quirks-2.114 signed on 2015-08-24T19:30:12Z Can't install libiconv-1.14p3 because of libraries |library c.80.1 not found | /usr/lib/libc.so.84.1 (system): bad major Can't install gettext-0.19.5.1: can't resolve libiconv-1.14p3 Can't install gettext-0.19.5.1: can't resolve libiconv-1.14p3 Can't install libidn-1.32: can't resolve libiconv-1.14p3,gettext-0.19.5.1 Can't install curl-7.43.0: can't resolve libiconv-1.14p3,gettext-0.19.5.1,libidn-1.32 But other packages do the same, "pkg_add wget" for example: # pkg_add wget quirks-2.114 signed on 2015-08-24T19:30:12Z Can't install libiconv-1.14p3 because of libraries |library c.80.1 not found | /usr/lib/libc.so.84.1 (system): bad major Can't install gettext-0.19.5.1: can't resolve libiconv-1.14p3 Can't install gettext-0.19.5.1: can't resolve libiconv-1.14p3 Can't install libidn-1.32: can't resolve libiconv-1.14p3,gettext-0.19.5.1 Can't install libidn-1.32: can't resolve libiconv-1.14p3,gettext-0.19.5.1 Can't install libunistring-0.9.5: can't resolve libiconv-1.14p3 Can't install libpsl-0.7.1p1: can't resolve libidn-1.32,libiconv-1.14p3,gettext-0.19.5.1,libunistring-0.9.5 Can't install pcre-8.37p1 because of libraries Can't install wget-1.16.3p0: can't resolve pcre-8.37p1,libpsl-0.7.1p1,libidn-1.32,libiconv-1.14p3,gettext-0.19.5.1 >How-To-Repeat: It is a fresh install, from the CD I downloaded and burned yesterday night. I tried using a different PKG_PATH off different mirrors, same thing. export PKG_PATH=http://ftp.openbsd.org/pub/OpenBSD/5.8/packages/`machine -a`/ export PKG_PATH=http://openbsd.cs.toronto.edu/pub/OpenBSD/5.8/packages/`machine -a`/ # uname -a OpenBSD flowerpot.cloud.pico 5.8 GENERIC.MP#830 sparc64 # machine -a sparc64 # ls -al /usr/lib/libc.so.* -r--r--r-- 1 root bin 3259462 Nov 11 13:57 /usr/lib/libc.so.84.1 >Fix: N/A dmesg: OpenBSD 5.8-current (GENERIC.MP) #830: Wed Nov 11 12:48:03 MST 2015 dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/GENERIC.MP real mem = 4294967296 (4096MB) avail mem = 4204855296 (4010MB) warning: no entropy supplied by boot loader mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root: Sun Fire V210 cpu0 at mainbus0: SUNW,UltraSPARC-IIIi (rev 3.4) @ 1336 MHz cpu0: physical 32K instruction (32 b/l), 64K data (32 b/l), 1024K external (64 b/l) cpu1 at mainbus0: SUNW,UltraSPARC-IIIi (rev 3.4) @ 1336 MHz cpu1: physical 32K instruction (32 b/l), 64K data (32 b/l), 1024K external (64 b/l) "memory-controller" at mainbus0 not configured "memory-controller" at mainbus0 not configured schizo0 at mainbus0: "Tomatillo", version 4, ign 7c0, bus B 0 to 0 schizo0: dvma map c000-dfff pci0 at schizo0 bge0 at pci0 dev 2 function 0 "Broadcom BCM5704C" rev 0x00, BCM5704 A3 (0x2003): ivec 0x7c8, address 00:03:ba:be:ac:f1 brgphy0 at bge0 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0 bge1 at pci0 dev 2 function 1 "Broadcom BCM5704C" rev 0x00, BCM5704 A3 (0x2003): ivec 0x7c9, address 00:03:ba:be:ac:f2 brgphy1 at bge1 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0 schizo1 at mainbus0: "Tomatillo", version 4, ign 780, bus A 0 to 0 schizo1: dvma map c000-dfff pci1 at schizo1 ebus0 at pci1 dev 7 function 0 "Acer Labs M1533 ISA" rev 0x00 "flashprom" at ebus0 addr 0-f, 290-290 not configured rtc0 at ebus0 addr 70-71: m5819p pcfiic0 at ebus0 addr 320-321 ivec 0x2e iic0 at pcfiic0 "SUNW,i2c-imax" at iic0 addr 0xb not configured "SUNW,i2c-imax" at iic0 addr 0xc not configured spdmem0 at iic0 addr 0x5b: 512MB DDR SDRAM registered ECC PC2300CL2.5 spdmem1 at iic0 addr 0x5c: 512MB DDR SDRAM registered ECC PC2300CL2.5 spdmem2 at iic0 addr 0x5d: 512MB DDR SDRAM registered ECC PC2300CL2.5 spdmem3 at iic0 addr 0x5e: 512MB DDR SDRAM registered ECC PC2300CL2.5 spdmem4 at iic0 addr 0x63: 512MB DDR SDRAM registered ECC PC2300CL2.5 spdmem5 at iic0 addr 0x64: 512MB DDR SDRAM registered ECC PC2300CL2.5 spdmem6 at iic0 addr 0x65: 512MB DDR SDRAM registered ECC PC2300CL2.5 spdmem7 at iic0 addr 0x66: 512MB DDR SDRAM registered ECC PC2300CL2.5 "ds1307" at iic0 addr 0x68 not configured "pca9555" at iic0 addr 0x22 not configured "pca9555" at iic0 addr 0x23 not configured "pca9555" at iic0 addr 0x34 not configured "pca9556" at iic0 addr 0x38 not configured power0 at ebus0 addr 800-82f ivec 0x20 com0 at ebus0 addr 3f8-3ff ivec 0x2c: ns16550a, 16 byte fifo com0: console com1 at ebus0 addr 2e8-2ef ivec 0x2c: ns16550a, 16 byte fifo "rmc-comm" at ebus0 addr 3e8-3ef ivec 0x2c not configured alipm0 at pci1 dev 6
Re: 5.8 kernel 1305 crashes during boot on i386/VIA
clip
> > OpenBSD 5.8-current (GENERIC) #1305: Fri Nov 6 05:20:32 MST 2015
> > dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> > cpu0: VIA Esther processor 1500MHz ("CentaurHauls" 686-class) 1.51
> > GHz
> > cpu0:
> > FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,APIC,SEP,MTRR,PGE,CMOV,PAT,CFLUSH,ACPI,MMX,
> > \
> > FXSR,SSE,SSE2,TM,PBE,NXE,SSE3,EST,TM2 real mem = 1005010944
> > (958MB)
> > avail mem = 973246464 (928MB)
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: date 05/16/06, BIOS32 rev. 0 @ 0xfb570, SMBIOS
> > rev. 2.3 @
> > 0xf (34 entries)
> > bios0: vendor Phoenix Technologies, LTD version "6.00 PG" date
> > 05/16/2006
> > acpi at bios0 function 0x0 not configured
. end clip
I am running 5.8 GENERIC patched on a Via C7-D without issue
OpenBSD 5.8 (GENERIC) #1: Mon Nov 9 12:41:23 PST 2015
j...@rabbit.home.yak:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: VIA Esther processor 1500MHz ("CentaurHauls" 686-class) 1.50 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,CMOV,PAT,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE,NXE,SSE3,EST,TM2
real mem = 2011242496 (1918MB)
avail mem = 1958539264 (1867MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 08/22/07, BIOS32 rev. 0 @ 0xfdd44, SMBIOS rev.
2.4 @ 0x77ee7000 (42 entries)
bios0: vendor FIC version "1.0D-V 08-8A20" date 08/22/2007
bios0: Everex Systems, Inc. Everex StepNote Series
acpi0 at bios0: rev 0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC MCFG SLIC
acpi0: wakeup devices LID_(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3)
USB5(S3) AZAC(S3) Z00C(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
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
I do get a transient message at initial boot about a buggy acpi table
but no show stoppers. There may be something else ?acpi settings in
bios?.
--
Re: dhclient spams me with no buffer space
On 11 November 2015 at 21:52, Ted Unangst wrote: > On my X1 carbon, I unplugged the ethernet cable and switched to wireless. I > had a forgotten dhclient running for some time. > > ifconfig reports the following: > > ifconfig em0 > em0: flags=8843 mtu 1500 > lladdr 54:ee:75:3c:17:cb > priority: 0 > media: Ethernet autoselect (none) > status: no carrier > > dhclient however spammed me with messages like the following: > > Nov 11 13:07:53 carbolite dhclient[24723]: DHCPDISCOVER on em0 - interval 10 > Nov 11 13:07:53 carbolite dhclient[24723]: send_packet: No buffer space > available > Nov 11 13:08:03 carbolite dhclient[24723]: DHCPDISCOVER on em0 - interval 1 > Nov 11 13:08:03 carbolite dhclient[24723]: send_packet: No buffer space > available > Nov 11 13:08:04 carbolite dhclient[24723]: No acceptable DHCPOFFERS received. > Nov 11 13:08:04 carbolite dhclient[24723]: No working leases in persistent > database - sleeping. > Nov 11 13:13:04 carbolite dhclient[24723]: DHCPDISCOVER on em0 - interval 3 > Nov 11 13:13:04 carbolite dhclient[24723]: send_packet: No buffer space > available > Nov 11 13:13:07 carbolite dhclient[24723]: DHCPDISCOVER on em0 - interval 4 > > My expectation is that dhclient should observe a status of no carrier and > cease attempts to continue blasting packets. > Fix committed. Ken
RCS is confused if latest revision is empty file
System: 5.8-current/amd64 RCS gets confused if the latest revision is an empty file: checking out any other revision will only produce empty files. Here's an example: $ rm -f foo foo,v $ echo hello world > foo $ ci -i -t-bla -l foo foo,v <-- foo initial revision: 1.1 done $ echo bonjour le monde > foo $ ci -msecond -l foo foo,v <-- foo revision 1.2 (locked) done $ : > foo $ ci -mthird -l foo # empty file foo,v <-- foo revision 1.3 (locked) done $ co -p1.1 foo # older revisions check out as empty! foo,v --> standard output revision 1.1 done $ co -p1.2 foo foo,v --> standard output revision 1.2 done Now we commit a non-empty revision on top: $ echo hallo welt > foo $ ci -mfourth -l foo foo,v <-- foo revision 1.4 (locked) done $ co -p1.1 foo # older revisions check out correctly! foo,v --> standard output revision 1.1 hello world done $ co -p1.2 foo foo,v --> standard output revision 1.2 bonjour le monde done $ co -p1.3 foo foo,v --> standard output revision 1.3 done $ co -p1.4 foo foo,v --> standard output revision 1.4 hallo welt done This bug also affects rcsdiff(1), which in turn causes CVSweb to display empty diffs, which is how I noticed. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Recent checkin to bge broke my Broadcom ethernet
> Date: Thu, 12 Nov 2015 08:14:08 + > From: Miod Vallat > > > >Fix: > > Reverting src/sys/dev/pci/if_bge.c to rev 1.371 and if_bgereg.h to > > 1.128 and > > rebuilding the kernel allows the interface to work correctly. > > Does the following diff (on top of HEAD, thus if_bge 1.372 and > if_bgereg.h 1.129) help? Miod, I really think you should back out that commit. It still think it's wrong. The magic number needs to be written into SRAM. The documentation for the various chips is pretty clear on that. Your diff changed things such that it writes it to some random undocumented hardware register. That makes no sense. Obviously there is something wrong with the old code as well. Possibly Apple used a different firmware for the onboard interfaces that isn't happy with the way we write the magic value. Since the magic value has something to do with PXE booting, perhaps simply skipping that write is a viable workaround for macppc. > Index: if_bge.c > === > RCS file: /OpenBSD/src/sys/dev/pci/if_bge.c,v > retrieving revision 1.372 > diff -u -p -r1.372 if_bge.c > --- if_bge.c 10 Nov 2015 20:23:50 - 1.372 > +++ if_bge.c 11 Nov 2015 19:45:38 - > @@ -3221,7 +3221,10 @@ bge_reset(struct bge_softc *sc) >* When firmware finishes its initialization it will >* write ~BGE_SRAM_FW_MB_MAGIC to the same location. >*/ > - write_op(sc, BGE_SOFTWARE_GENCOMM, BGE_MAGIC_NUMBER); > + if (write_op == bge_writereg_ind) > + bge_writereg_ind(sc, BGE_SOFTWARE_GENCOMM, BGE_MAGIC_NUMBER); > + else > + bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM, BGE_MAGIC_NUMBER); > > reset = BGE_MISCCFG_RESET_CORE_CLOCKS | BGE_32BITTIME_66MHZ; > > >
Re: Recent checkin to bge broke my Broadcom ethernet
> >Fix: > Reverting src/sys/dev/pci/if_bge.c to rev 1.371 and if_bgereg.h to > 1.128 and > rebuilding the kernel allows the interface to work correctly. Does the following diff (on top of HEAD, thus if_bge 1.372 and if_bgereg.h 1.129) help? Index: if_bge.c === RCS file: /OpenBSD/src/sys/dev/pci/if_bge.c,v retrieving revision 1.372 diff -u -p -r1.372 if_bge.c --- if_bge.c10 Nov 2015 20:23:50 - 1.372 +++ if_bge.c11 Nov 2015 19:45:38 - @@ -3221,7 +3221,10 @@ bge_reset(struct bge_softc *sc) * When firmware finishes its initialization it will * write ~BGE_SRAM_FW_MB_MAGIC to the same location. */ - write_op(sc, BGE_SOFTWARE_GENCOMM, BGE_MAGIC_NUMBER); + if (write_op == bge_writereg_ind) + bge_writereg_ind(sc, BGE_SOFTWARE_GENCOMM, BGE_MAGIC_NUMBER); + else + bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM, BGE_MAGIC_NUMBER); reset = BGE_MISCCFG_RESET_CORE_CLOCKS | BGE_32BITTIME_66MHZ;
