Re: tanf returns NaN for large inputs
With numpy/i386 we don't fix any of the currently broken tests and
surprisingly one new regression is introduced:
-13 failed, 10900 passed, 88 skipped, 108 deselected, 19 xfailed, 2
xpassed, 5 warnings in 206.14 seconds
+14 failed, 10899 passed, 88 skipped, 108 deselected, 19 xfailed, 2
xpassed, 5 warnings in 205.49 seconds
The new breakage is due to a test that checks for errors that <= 2
ulps using sin on 32-bit floats vs sin on 64-bit floats (shown below).
Still, it may be worth committing the proposed change and then
separately seeing if we can improve the C versions of these functions.
___ TestAVXFloat32Transcendental.test_sincos_float32 ___
self =
def test_sincos_float32(self):
np.random.seed(42)
N = 100
M = np.int_(N/20)
index = np.random.randint(low=0, high=N, size=M)
x_f32 = np.float32(np.random.uniform(low=-100.,high=100.,size=N))
# test coverage for elements > 117435.992f for which glibc is used
x_f32[index] = np.float32(10E+10*np.random.rand(M))
x_f64 = np.float64(x_f32)
> assert_array_max_ulp(np.sin(x_f32), np.float32(np.sin(x_f64)), maxulp=2)
E AssertionError: Arrays are not almost equal up to 2 ULP (max
difference is 65 ULP)
M = 5
N = 100
index = array([121958, 671155, 131932, ..., 738271, 310195, 233966])
self =
x_f32 = array([-10.577719, -35.353283, -97.29114 , ..., -80.99214
, -42.875526,
-87.8052 ], dtype=float32)
x_f64 = array([-10.57771873, -35.35328293, -97.2911377 , ..., -80.99214172,
-42.87552643, -87.80519867])
On Sun, Jan 9, 2022 at 4:57 PM Greg Steuck wrote:
>
> Daniel Dickman writes:
>
> > Here's the link to the commit Mark referenced:
> > https://github.com/NetBSD/src/commit/4f9e11b0dddf04640fe0553a9133a471af613627
> >
> > And then the actual implementations were removed in this commit:
> > https://github.com/NetBSD/src/commit/870f792ccadb412e522f37caec6028b0076a871b
> >
> > So I guess this is the list of functions to remove, Mark?
> >
> > I'm testing this on i386 with numpy to see if regress tests improve.
> >
> > s_cos.S
> > s_cosf.S
> > s_sin.S
> > s_sinf.S
> > s_tan.S
> > s_tanf.S
>
> This improves one of the regress tests mbuhl@ added. This one now
> passes:
>
> modified regress/lib/libm/msun/Makefile
> @@ -58,7 +58,6 @@ FAILING+= run-ctrig_test-1
> FAILING+= run-exponential_test-1
> FAILING+= run-invtrig_test-7
> FAILING+= run-next_test-{1,2,4}
> -FAILING+= run-trig_test-3
> . elif ${MACHINE} == arm64
> FAILING+= run-cexp_test-{1,7}
> FAILING+= run-ctrig_test-{1,5}
>
> But one new test is reported broken:
>
> run-trig_test-2
> 2 tests the accuracy of these functions over the primary range
> ./trig_test -r 2
>
> trig_test.c:257: 'fpequal_cs(_x, _y, 1)' evaluated to false
> *** Error 1 in . (Makefile:143 'run-trig_test-2')
> FAILED
>
> So, some attention is needed in this area.
>
> Thanks
> Greg
Re: tanf returns NaN for large inputs
On Sun, Jan 9, 2022 at 4:18 PM Mark Kettenis wrote: > > > From: Greg Steuck > > Date: Sun, 09 Jan 2022 12:47:14 -0800 > > > > Greg Steuck writes: > > > > > This was reduced from a ghc test. The results of the program differ > > > between OpenBSD 7.0-current-amd64 and a couple of other systems: > > > > Thanks to phessler@ for testing on arm64 where the bug doesn't happen. > > This patch makes OpenBSD-amd64 work the rest of the systems. I added > > i386 as it was also similarly broken (but didn't test the change yet). > > As I said on icb, NetBSD removed all of the x86 assembly sin/cos/tan > implementations because: > > "The x87 hardware uses a bad approximation to pi for argument reduction" > > So I think we should use the software fallbacks for all of these > functions (and remove the broken assembly implementations). > > I don't think it makes sense to just remove tanf() and leave the > others in place. > > Here's the link to the commit Mark referenced: https://github.com/NetBSD/src/commit/4f9e11b0dddf04640fe0553a9133a471af613627 And then the actual implementations were removed in this commit: https://github.com/NetBSD/src/commit/870f792ccadb412e522f37caec6028b0076a871b So I guess this is the list of functions to remove, Mark? I'm testing this on i386 with numpy to see if regress tests improve. s_cos.S s_cosf.S s_sin.S s_sinf.S s_tan.S s_tanf.S
Re: 2 freezes in 24h on lenovo T480 with 1st october snapshot
> On Oct 4, 2019, at 9:56 AM, Solene Rapenne wrote: > > Hi, > > did someone else did experience freezes issues recently? I had two freezes in > one day. > > First time I was doing heavy CPU use and assumed something went wrong, or heat > I don't know. Second time, I was thinking about typing something in a mail, > the > system was totally idle. Hi Solene, I’m not sure if this is related but I’m seeing console freezes on my i386 laptop. I’m not using X, just the console. And I believe I’ve experienced these freezes with and without drm enabled. The symptoms for me are the keyboard stops working for certain letters. And then the console freezes completely shortly after that. I’m able to recover from this by switching to a different console and then doing “kill -9” on the stuck ksh process. When your system freezes, are you able to switch to a different console? Or can you still ssh into it? I’m not sure if it’s a hardware issue on my end or some bug and wasn’t exactly sure how to debug this as I can’t reproduce easily. Things I tried: 1) using historical kernels, but all the kernels I tried so far don’t solve the problem. 2) ktracing the ksh processes on each console to see if there’s something obvious that triggers the problem. I’m working on getting some traces but I haven’t managed so far because the freezes are so random. Things I’m thinking of trying: 1) installing a different OS to check if it’s a hardware problem. 2) reinstalling 6.4 and 6.5 to see if I see the same problem. If yes then likely a hardware problem because I used those releases in the past without any issues.
Re: Dell T20 with Pentium G3220 needs "disable inteldrm"
> On Nov 2, 2018, at 12:59 AM, Daniel Dickman wrote: > > > >> On Oct 31, 2018, at 11:38 PM, Jonathan Gray wrote: >> >>> On Wed, Oct 31, 2018 at 10:16:40PM +0100, Christian Weisgerber wrote: >>> Jonathan Gray: >>> >>>> These machines appear to have a serial port so you should be able to get a >>>> proper trace with the console on serial. >>> >>> Right. What do you need? Here's the ddb trace after the uvm_fault: >> >> Ah yes, that has been seen before when trying to run i386 on a recent >> intel machine not seen with amd64. I ran into that when running i386 on >> an x230 (ivy bridge) with 8gb physram as well. Doesn't occur with machines >> that use inteldrm with intagp like x40. > > same problem here. > > dmesg at http://dickman.org/openbsd/dmesg/dmesg.dell seems like 6.2 doesn’t work, but 6.1 works. narrowing it down slightly: - kernel from 20170625 seems to work - kernel from 20170705 seems bad This period of time covers about 300 commits (ie. see git log a1ae353...e12511f). this range includes the big update to sync inteldrm to linux 4.4.70 that happened on july 1st, 2017. so i don’t have complete evidence, but i strongly suspect this is the commit in question: https://github.com/openbsd/src/commit/e0b53cee anything i should try?
Re: Dell T20 with Pentium G3220 needs "disable inteldrm"
> On Oct 31, 2018, at 11:38 PM, Jonathan Gray wrote: > >> On Wed, Oct 31, 2018 at 10:16:40PM +0100, Christian Weisgerber wrote: >> Jonathan Gray: >> >>> These machines appear to have a serial port so you should be able to get a >>> proper trace with the console on serial. >> >> Right. What do you need? Here's the ddb trace after the uvm_fault: > > Ah yes, that has been seen before when trying to run i386 on a recent > intel machine not seen with amd64. I ran into that when running i386 on > an x230 (ivy bridge) with 8gb physram as well. Doesn't occur with machines > that use inteldrm with intagp like x40. same problem here. dmesg at http://dickman.org/openbsd/dmesg/dmesg.dell
Re: uvm_fault - Stopped at pmap_remove_ptes_86
I am seeing the exact same crash with GENRIC.MP latest snap on i386. booting
with the GENRIC kernel works for me though.
On Apr 21, 2015, at 11:19 AM, Mark Patruck m...@wrapped.cx wrote:
I tried source updating my 3 weeks old i386 OpenBSD 5.7-current and
after booting the new kernel it crashed after fsck'ing. Just to make
sure, i did an update via latest snapshot, but it crashed again.
(full dmesg below)
OpenBSD 5.7-current (GENERIC.MP) #824: Mon Apr 20 23:23:30 MDT 2015
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Xeon(R) CPU E3-1230 v3 @ 3.30GHz (GenuineIntel 686-class)
3.30 GHz
setting tty flags
pf enabled
ddb.console: 0 - 1
starting network
uvm_fault(0xd0b89480, 0xcf9df000, 0, 1) - e
kernel: page fault trap, code=0
Stopped at pmap_remove_ptes_86+0x72: movl0(%edx),%eax
ddb{0}
ddb{0} trace
pmap_remove_ptes_86(daa25100,d45c4f30,cf9dfd60,77f58000,77f59000) at
pmap_remov
e_ptes_86+0x72
pmap_do_remove_86(daa25100,77f58000,77f59000,0,daa2a2bc) at
pmap_do_remove_86+0
xfc
pmap_remove(daa25100,77f58000,77f59000,d04fc9c9,d0ba7e60) at pmap_remove+0x28
uvm_unmap_kill_entry(daa26120,daa0a580,f54c1f2c,d050bdcd,daa0a580) at
uvm_unmap
_kill_entry+0xf8
uvm_map_teardown(daa26120,f54c1f14,2e770bc0,daa0b008,d03a23f0) at
uvm_map_teard
own+0xbc
uvmspace_free(daa26120,1,2e770bc0,f54c1f5c,d02032fa) at uvmspace_free+0x2e
uvm_exit(daa1c310,d0b23ac8,4,d09aac8e,0) at uvm_exit+0x15
reaper(daa2270c) at reaper+0xd0
ddb{0} ps
PID PPID PGRPUID S FLAGS WAIT COMMAND
30843 30854 30854 0 30x8b pause sh
30854 1 30854 0 30x8b pause sh
10796 0 0 0 3 0x14200 pgzerozerothread
20524 0 0 0 3 0x14200 aiodoned aiodoned
30711 0 0 0 3 0x14200 syncerupdate
295 0 0 0 3 0x14200 cleaner cleaner
*18600 0 0 0 7 0x14200reaper
8467 0 0 0 3 0x14200 pgdaemon pagedaemon
21165 0 0 0 3 0x14200 bored crypto
22401 0 0 0 3 0x14200 pftm pfpurge
21731 0 0 0 3 0x14200 usbtskusbtask
13690 0 0 0 3 0x14200 usbatsk usbatsk
1565 0 0 0 3 0x14200 bored sensors
11166 0 0 0 3 0x40014200 acpi0 acpi0
32510 0 0 0 7 0x40014200idle3
7402 0 0 0 7 0x40014200idle2
14316 0 0 0 7 0x40014200idle1
28105 0 0 0 3 0x14200 bored softnet
11715 0 0 0 3 0x14200 bored systqmp
6918 0 0 0 3 0x14200 bored systq
4056 0 0 0 3 0x40014200idle0
24258 0 0 0 3 0x14200 kmalloc kmthread
1 0 1 0 30x82 wait init
0 -1 0 0 3 0x10200 scheduler swapper
ddb{0} show registers
ds 0x10
es 0x10
fs 0x20
gs 0
edi 0x77f58000
esi 0x77f58000
Ebp 0xf54c1e2c
ebx 0x77f59000
edx 0xcf9dfd60PTmap+0x1dfd60
ecx 0xdaa25100end+0x9ddbe18
eax 0xd45c4f30end+0x397bc48
eip 0xd0564ab2pmap_remove_ptes_86+0x72
cs 0x8
eflags 0x10202
esp 0xf54c1de4
ss 0x10
pmap_remove_ptes_86+0x72: movl0(%edx),%eax
OpenBSD 5.7-current (GENERIC.MP) #824: Mon Apr 20 23:23:30 MDT 2015
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Xeon(R) CPU E3-1230 v3 @ 3.30GHz (GenuineIntel 686-class)
3.30 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,PAGE1GB,LONG,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM
real mem = 3715575808 (3543MB)
avail mem = 3642568704 (3473MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 04/13/12, SMBIOS rev. 2.7 @ 0xec090 (36 entries)
bios0: vendor American Megatrends Inc. version 1.1a date 12/03/2013
bios0: Supermicro X10SLH-F/X10SLM+-F
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT LPIT SSDT SSDT SSDT SSDT MCFG PRAD HPET
SSDT SSDT SPMI DMAR EINJ ERST HEST BERT
acpi0: wakeup devices PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4)
PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) GLAN(S4) EHC1(S4) EHC2(S4) XHC_(S4)
Re: [PATCH] New (?) blowfish format not supported by user(8)
On Tue, Feb 24, 2015 at 10:53 AM, dal...@safe-mail.net wrote: There is apparently a new blowfish format supported by bcrypt, denoted by the prefix $2b where the previous version used $2a. user(8) checks the length of the crypted password supplied to the -p option but does not understand the new ($2b) format: take a look at revision 1.100 of user.c. this should already be fixed, no? revision 1.100 date: 2014/08/27 06:51:35; author: sebastia; state: Exp; lines: +8 -5; commitid: 5lCymSA9cyXpQEk5; Add missing capability to handle new $2b version of blowfish password encryption for usermod and friends. OK millert@, seems reasonable for now tedu@
Re: error in man page find(1)
On Wed, Dec 3, 2014 at 5:41 PM, Ted Unangst t...@tedunangst.com wrote: On Wed, Dec 03, 2014 at 15:12, Theo de Raadt wrote: If you think my diff is too wordy, we could move the text around a bit, perhaps later in the section and say -and and -or are alternatives to -a and -o or such. For scripting stuff, we have tended to lean towards the portable approach, since such code gets used on other systems very often. Here's a revised diff against current. It just notes that the extension spellings are such. Index: find.1 === RCS file: /cvs/src/usr.bin/find/find.1,v retrieving revision 1.89 diff -u -p -r1.89 find.1 --- find.1 3 Dec 2014 19:39:57 - 1.89 +++ find.1 3 Dec 2014 22:40:18 - @@ -509,7 +509,6 @@ operator. It evaluates to true if the expression is false. .Pp .It Ar expression Cm -a Ar expression -.It Ar expression Cm -and Ar expression .It Ar expression expression The logical AND operator. As it is implied by the juxtaposition of two expressions it does not @@ -518,7 +517,6 @@ The expression evaluates to true if both The second expression is not evaluated if the first expression is false. .Pp .It Ar expression Cm -o Ar expression -.It Ar expression Cm -or Ar expression The logical OR operator. The expression evaluates to true if either the first or the second expression is true. @@ -529,6 +527,11 @@ Operators, primaries, and arguments to p arguments to .Nm find , i.e. they should be separated by whitespace. +.Pp +As an extension, the AND and OR operators may also be spelled +.Cm -and +and +.Cm -or . .Sh EXIT STATUS The .Nm I personally like jmc's existing version better. I feel like we typically document the whole command as implemented on .Ox, and note any extensions in the STANDARDS section as he's done. Deleting -and and -or from the OPERATORS sections feels a bit inconsistent/incomplete to me compared to other pages.
floppy doesn't work on sun4m
Floppy doesn't work on sparc/5.6. I tested 5.5 and -currrent and same behaviour. # dd if=floppy56.fs of=/dev/rfd0c bs=36b dd: /dev/rfd0c: Input/output error 1+0 records in 0+0 records out 0 bytes transferred in 3.629 secs (0 bytes/sec) Afte this, the dmesg shows: fd0c: hard error reading fsbn 0 fd0: controller status: state 17 (st0 70abnrml,seek_cmplt,equ_chck cyl 0) fd0c: hard error writing fsbn 0 of 0-35 fd0: controller status: state 17 (st0 70abnrml,seek_cmplt,equ_chck cyl 0) Here's an old bug report describing similar behaviour. It was marked as fixed but I don't have access to such an old release to confirm if it broke again since then. http://marc.info/?l=openbsd-bugsm=93776968628448w=2 fdformat does not seem to work either: # fdformat /dev/rfd0c Format 1440K floppy `/dev/rfd0c'? (y/n): y Processing EE^C The floppy works fine from Solaris and an OpenBSD install from floppy also works fine on this machine. So I think it's not a hardware issue.See below for disklabel and dmesg. ---[ disklabel fd0 ]-- # /dev/rfd0c: type: floppy disk: floppy disk label: fictitious duid: flags: vendor bytes/sector: 512 sectors/track: 18 tracks/cylinder: 2 sectors/cylinder: 36 cylinders: 80 total sectors: 2880 boundstart: 0 boundend: 2880 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] c: 28800 unused ---[ dmesg ]-- OpenBSD 5.6 (GENERIC) #94: Wed Aug 13 13:54:32 GMT 2014 m...@credogne.gentiane.org:/usr/src/sys/arch/sparc/compile/GENERIC real mem = 536313856 (511MB) avail mem = 521682944 (497MB) mainbus0 at root: SUNW,SPARCstation-20 cpu0 at mainbus0: RT620/625 @ 166 MHz, on-chip FPU cpu0: 512K byte write-back, 32 bytes/line, sw flush cache enabled obio0 at mainbus0 clock0 at obio0 addr 0xf120: mk48t08 (eeprom) timer0 at obio0 addr 0xf130: delay constant 54, frequency 200 Hz zs0 at obio0 addr 0xf110 pri 12, softpri 6 zstty0 at zs0 channel 0 zstty1 at zs0 channel 1 zs1 at obio0 addr 0xf100 pri 12, softpri 6 zskbd0 at zs1 channel 0: keyboard, type 5, layout 0x22 wskbd0 at zskbd0: console keyboard zsms0 at zs1 channel 1 wsmouse0 at zsms0 mux 0 fdc0 at obio0 addr 0xf170 pri 11, softpri 4: chip 82077 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec auxreg0 at obio0 addr 0xf180 power0 at obio0 addr 0xf1a01000 iommu0 at mainbus0 ioaddr 0xe000: version 0x3/0x1, page-size 4096, range 64MB sbus0 at iommu0: 25 MHz dma0 at sbus0 slot 15 offset 0x40: rev 2 esp0 at dma0 offset 0x80 pri 4: ESP200, 40MHz scsibus0 at esp0: 8 targets, initiator 7 sd0 at scsibus0 targ 3 lun 0: SEAGATE, ST373455LC, 0003 SCSI3 0/direct fixed naa.5000 sd0: 70007MB, 512 bytes/sector, 143374744 sectors cd0 at scsibus0 targ 6 lun 0: TOSHIBA, XM-4101TASUNSLCD, 0494 SCSI2 5/cdrom removable ledma0 at sbus0 slot 15 offset 0x400010: rev 2 le0 at ledma0 offset 0xc0 pri 6: address 08:00:20:xx:xx:xx le0: 16 receive buffers, 4 transmit buffers bpp0 at sbus0 slot 15 offset 0x480: DMA2 SUNW,DBRIe at sbus0 slot 14 offset 0x1 not configured hme0 at sbus0 slot 0 offset 0x8c0 pri 7: address 08:00:20:xx:xx:xx rev 34 luphy0 at hme0 phy 0: LU6612 10/100 PHY, rev. 1 luphy1 at hme0 phy 1: LU6612 10/100 PHY, rev. 1 ifmedia_match: multiple match for 0x20/0xfff, selected instance 0 hme1 at sbus0 slot 0 offset 0x8c1 pri 7: address 08:00:20:xx:xx:xx rev 34 luphy2 at hme1 phy 0: LU6612 10/100 PHY, rev. 1 luphy3 at hme1 phy 1: LU6612 10/100 PHY, rev. 1 ifmedia_match: multiple match for 0x20/0xfff, selected instance 0 hme2 at sbus0 slot 0 offset 0x8c2 pri 7: address 08:00:20:xx:xx:xx rev 34 luphy4 at hme2 phy 0: LU6612 10/100 PHY, rev. 1 luphy5 at hme2 phy 1: LU6612 10/100 PHY, rev. 1 ifmedia_match: multiple match for 0x20/0xfff, selected instance 0 hme3 at sbus0 slot 0 offset 0x8c3 pri 7: address 08:00:20:xx:xx:xx rev 34 luphy6 at hme3 phy 0: LU6612 10/100 PHY, rev. 1 luphy7 at hme3 phy 1: LU6612 10/100 PHY, rev. 1 ifmedia_match: multiple match for 0x20/0xfff, selected instance 0 cgsix0 at sbus0 slot 2 offset 0x0 pri 9: SUNW,501-2325, 1152x900, rev 11 wsdisplay0 at cgsix0 mux 1: console (std, sun emulation), using wskbd0 vscsi0 at root scsibus1 at vscsi0: 256 targets softraid0 at root scsibus2 at softraid0: 256 targets bootpath: /iommu@f,e000/sbus@f,e0001000/espdma@f,40/esp@f,80/sd@3,0 root on sd0a (1e9e20243ed765fe.a) swap on sd0b dump on sd0b
Re:
I would try the latest snapshot instead of 5.5 to see if this is
already fixed. A lot's changed since 5.5 so it's worth a try...
Be great if you could report back whether it works or not.
On Sat, Sep 6, 2014 at 3:50 PM, E. L. Evans V eleva...@gmail.com wrote:
Synopsis: unable to install 5.4, 5.5 on HP dc5800 PC
Category: misc
Environment:
System : OpenBSD 5.5
Details : OpenBSD 5.5
Architecture: OPENBSD
Machine:
Description:
INSTALL OpenBSD 5.5 via CD, select either redirect or no
redirect of console. Installation appears to proceed normally. Reboot.
Reboot fails with following error:
pci4 at ppb3 bus 4
em2 at pci4 dev 0 function 0 Intel 82571EB rev 0x06: apic 1 int 17,
address 00:1f:29:56:76:3f
em3 at pci4 dev 0 function 1 Intel 82571EB rev 0x06: apic 1 int 16,
address 00:1f:29:56:76:3e
vga1 at pci0 dev 2 function 0 Intel 82Q33 Video rev 0x02
intagp at vga1 not configured
inteldrm0 at vga1
drm0 at inteldrm0: couldn't find agp
uvm_fault(0x81daaf00, 0x20, 0, 1) - e
kernel: page fault trap, code=0
Stopped at drm_fb_helper_restore_fbdev_mode+0xd: movl
0x20(%rdi),%edx
drm_fb_helper_restore_fbdev_mode() at drm_fb_helper_restore_fbdev_mode+0xd
intel_fb_restore_mode() at intel_fb_restore_mode+0x33
drm_lastclose() at drm_lastclose+0x1f
drm_attach() at drm_attach+0x237
config_attach() at config_attach+0x1bc
end trace frame: 0x81ecbd30, count: 0
How-To-Repeat:
Reinstall, reboot. Further, this occurs on two of the
aforementioned PC's, and across various installation options, various
BIOS options.
Fix:
I do not have a fix
SENDBUG: Run sendbug as root if this is an ACPI report!
SENDBUG: dmesg and usbdevs are attached.
SENDBUG: Feel free to delete or use the -D flag if they contain
sensitive information.
dmesg:
ddb{0} dmesg
OpenBSD 5.5 (GENERIC.MP) #315: Wed Mar 5 09:37:46 MST 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3185242112 (3037MB)
avail mem = 3091902464 (2948MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xea7c0 (69 entries)
bios0: vendor Hewlett-Packard version 786F2 v01.04 date 01/31/2008
bios0: Hewlett-Packard HP Compaq dc5800 Microtower
acpi0 at bios0: rev 0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC ASF! MCFG TCPA SLIC HPET
acpi0: wakeup devices COM1(S4) COM2(S4) PCI0(S4) PEG1(S4) PEG2(S4)
IGBE(S4) PCX
1(S4) PCX2(S4) PCX5(S4) PCX6(S4) HUB_(S4) USB1(S3) USB2(S3) USB3(S3)
USB4(S3) U
SB5(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2992.93 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,C
FLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,
EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF
cpu0: 6MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 332MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2992.51 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,C
FLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,
EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF
cpu1: 6MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 1
acpimcfg0 at acpi0 addr 0xf400, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PEG1)
acpiprt2 at acpi0: bus -1 (PEG2)
acpiprt3 at acpi0: bus 32 (PCX1)
acpiprt4 at acpi0: bus 48 (PCX2)
acpiprt5 at acpi0: bus -1 (PCX5)
acpiprt6 at acpi0: bus -1 (PCX6)
acpiprt7 at acpi0: bus 7 (HUB_)
acpicpu0 at acpi0: C2, C1, PSS
acpicpu1 at acpi0: C2, C1, PSS
acpibtn0 at acpi0: PBTN
cpu0: Enhanced SpeedStep 2992 MHz: speeds: 3000, 1998 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 Intel 82Q33 Host rev 0x02
ppb0 at pci0 dev 1 function 0 Intel 82Q33 PCIE rev 0x02: msi
pci1 at ppb0 bus 1
ppb1 at pci1 dev 0 function 0 IDT 89HPES12N3A rev 0x0e
pci2 at ppb1 bus 2
ppb2 at pci2 dev 2 function 0 IDT 89HPES12N3A rev 0x0e
pci3 at ppb2 bus 3
em0 at pci3 dev 0 function 0 Intel 82571EB rev 0x06: apic 1 int 19,
address 0
0:1f:29:56:76:3d
em1 at pci3 dev 0 function 1 Intel 82571EB rev 0x06: apic 1 int 18,
address 0
0:1f:29:56:76:3c
ppb3 at pci2 dev 4 function 0 IDT 89HPES12N3A rev 0x0e
pci4 at ppb3 bus 4
em2 at pci4 dev 0 function 0 Intel 82571EB rev 0x06: apic 1 int 17,
address 0
0:1f:29:56:76:3f
em3 at pci4 dev 0 function 1 Intel 82571EB rev 0x06: apic 1 int 16,
address 0
