Re: i386 install bug on recent snap

2014-02-22 Thread Kenneth Westerback
On 21 February 2014 23:31, Rod Whitworth glis...@witworx.com wrote:
 I can see why this one goes unnoticed.

 When I grab a snapshot and install on a test machine I make a practice
 of deleting the k partition because I don't need it and it takes ages
 to newfs it. (Slow Atom box)

 Today it caught me. Going through the usual accept defaults (as much as
 possible) I hit enter to leave the whole disk for OpenBSD and then
 chose E when the partition choices came up.
 entered d k cr
 then q cr
 Write new label? [y] appeared and as usual I hit cr
 To my surprise I was looking at the fdisk choices section again.

 What I missed at first was the Segmentation fault message crammed in
 between the partition stuff and the fdisk stuff.

 So I just left the k partition in  and all went well.

 Completely repeatable.

Indeed. The 'q' then 'y' seem to be the key. If I say 'w', 'q' (which
is my habitual exiting technique) then there does not seem to be a seg
fault.

Likely fallout from the tweaking of mount point code I did a few days ago.

 Ken


 dmesg:


 OpenBSD 5.5-beta (GENERIC.MP) #237: Tue Feb 18 16:19:26 MST 2014
 t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
 cpu0: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (GenuineIntel 686-class)
 1.80 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,MWAI
 T,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF
 real mem  = 2137223168 (2038MB)
 avail mem = 2090397696 (1993MB)
 mainbus0 at root
 bios0 at mainbus0: AT/286+ BIOS, date 06/23/11, BIOS32 rev. 0 @
 0xf0010, SMBIOS rev. 2.6 @ 0xfc8b0 (23 entries)
 bios0: vendor American Megatrends Inc. version 080015 date 06/23/2011
 bios0: Standard XS35
 acpi0 at bios0: rev 2
 acpi0: sleep states S0 S3 S4 S5
 acpi0: tables DSDT FACP APIC MCFG SLIC OEMB HPET GSCI
 acpi0: wakeup devices P0P1(S4) AZAL(S3) P0P4(S4) P0P5(S4) JLAN(S3)
 P0P6(S4) P0P7(S4) P0P8(S4) P0P9(S4) USB0(S3) USB1(S3) USB2(S3) USB3(S3)
 EUSB(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
 cpu0: apic clock running at 199MHz
 cpu0: mwait min=64, max=64, C-substates=0.1.0.0.0, IBE
 cpu1 at mainbus0: apid 2 (application processor)
 cpu1: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (GenuineIntel 686-class)
 1.80 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,MWAI
 T,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF
 cpu2 at mainbus0: apid 1 (application processor)
 cpu2: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (GenuineIntel 686-class)
 1.80 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,MWAI
 T,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF
 cpu3 at mainbus0: apid 3 (application processor)
 cpu3: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (GenuineIntel 686-class)
 1.80 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,MWAI
 T,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF
 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins
 ioapic0: misconfigured as apic 3, remapped to apid 4
 acpimcfg0 at acpi0 addr 0xe000, bus 0-255
 acpihpet0 at acpi0: 14318179 Hz
 acpiprt0 at acpi0: bus 0 (PCI0)
 acpiprt1 at acpi0: bus 3 (P0P1)
 acpiprt2 at acpi0: bus 1 (P0P4)
 acpiprt3 at acpi0: bus 2 (P0P5)
 acpiprt4 at acpi0: bus -1 (P0P6)
 acpiprt5 at acpi0: bus -1 (P0P7)
 acpiprt6 at acpi0: bus -1 (P0P8)
 acpiprt7 at acpi0: bus -1 (P0P9)
 acpiec0 at acpi0
 acpicpu0 at acpi0
 acpicpu1 at acpi0
 acpicpu2 at acpi0
 acpicpu3 at acpi0
 acpitz0 at acpi0: critical temperature is 104 degC
 acpibtn0 at acpi0: SLPB
 acpibtn1 at acpi0: PWRB
 acpivideo0 at acpi0: GFX0
 acpivout0 at acpivideo0: LCD_
 bios0: ROM list: 0xc/0xda00! 0xce000/0x1800! 0xcf800/0x1000
 pci0 at mainbus0 bus 0: configuration mode 1 (bios)
 0:31:2: mem address conflict 0xfc00/0x400
 pchb0 at pci0 dev 0 function 0 Intel Pineview DMI rev 0x02
 vga1 at pci0 dev 2 function 0 Intel Pineview Video rev 0x02
 intagp0 at vga1
 agp0 at intagp0: aperture at 0xd000, size 0x1000
 inteldrm0 at vga1
 drm0 at inteldrm0
 inteldrm0: 1024x768
 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
 wsdisplay0: screen 1-5 added (std, vt100 emulation)
 Intel Pineview Video rev 0x02 at pci0 dev 2 function 1 not configured
 azalia0 at pci0 dev 27 function 0 Intel 82801GB HD Audio rev 0x02:
 msi
 azalia0: codecs: IDT 92HD81B1X
 audio0 at azalia0
 ppb0 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x02: apic 4
 int 16
 pci1 at ppb0 bus 1
 ppb1 at pci0 dev 28 function 1 Intel 82801GB PCIE rev 0x02: apic 4
 int 17
 pci2 at ppb1 bus 2
 JMicron SD/MMC rev 0x80 at pci2 

Re: i386 install bug on recent snap

2014-02-22 Thread Kenneth Westerback
On 22 February 2014 07:03, Kenneth Westerback kwesterb...@gmail.com wrote:
 On 21 February 2014 23:31, Rod Whitworth glis...@witworx.com wrote:
 I can see why this one goes unnoticed.

 When I grab a snapshot and install on a test machine I make a practice
 of deleting the k partition because I don't need it and it takes ages
 to newfs it. (Slow Atom box)

 Today it caught me. Going through the usual accept defaults (as much as
 possible) I hit enter to leave the whole disk for OpenBSD and then
 chose E when the partition choices came up.
 entered d k cr
 then q cr
 Write new label? [y] appeared and as usual I hit cr
 To my surprise I was looking at the fdisk choices section again.

 What I missed at first was the Segmentation fault message crammed in
 between the partition stuff and the fdisk stuff.

 So I just left the k partition in  and all went well.

 Completely repeatable.

 Indeed. The 'q' then 'y' seem to be the key. If I say 'w', 'q' (which
 is my habitual exiting technique) then there does not seem to be a seg
 fault.

 Likely fallout from the tweaking of mount point code I did a few days ago.

  Ken

Which should now be reverted so the next snap should be back to
previous behaviour.

 Ken



Re: exp() / expl() on Linux and OpenBSD (expl() bug?)

2014-02-22 Thread Miod Vallat
  A fix has been committed, but there's still a problem on loongson with
  libm updated:

[...]

 This is definitely a problem in gdtoa. The values are always computed
 the same, but do not get printed correctly, as shown by this modified
 test program. Both lines should print 0.606531 for the long doubles, but
 don't always; this smells like an uninitialized value somewhere.

Well, it turned out this was caused by the program stack being aligned
to an 8 byte boundary, instead of a 16 byte boundary, causing long
double variables on the stack to be misaligned 50% of the time.

This has been fixed now.

Miod