Re: Core firefox, was: (Re: alc0 watchdog timeout)

2019-06-26 Thread PengouinBSD 
I installed few days ago gdb:

(query is a personal alias for pkg_info -Q)
$ query gdb | grep installed
gdb-7.12.1p5 (installed)

$ gdb --version
GNU gdb 6.3

If I try with egdb:

$ egdb /usr/local/bin/firefox
firefox.core
   

GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-openbsd6.5".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/bin/firefox...(no debugging symbols
found)...done.

warning: Couldn't find general-purpose registers in core file.

warning: Couldn't find general-purpose registers in core file.
#0   in ?? ()
(gdb) bt
#0   in ?? ()
Backtrace stopped: not enough registers or memory available to unwind
further
(gdb) thread 1
[Switching to thread 1 (process 1)]
#0   in ?? ()
(gdb) thread 2
Unknown thread 2.
(gdb) thread 0
Invalid thread ID: 0
(gdb) q

No help more! :(


On 6/26/19 9:37 PM, Todd Mortimer wrote:
> Hmm. That’s obviously not very helpful. 
>
> Perhaps try ports gdb? It will install as egdb. 
>
>> On Jun 26, 2019, at 21:33, Stéphane HUC PengouinBSD  
>> wrote:
>>
>>> On 6/22/19 5:32 PM, Todd Mortimer wrote:
>>> On Sat, Jun 22, 2019 at 12:25:30PM +0200, Stephane HUC "PengouinBSD" wrote: 
>>> >> (...) >> >> Perhaps, for Firefox, it's a problem with pledge? >> >>
>> I see thoses messages in /var/log/messages - egual on 'dmesg': >> >> Jun
>> 22 11:21:21 ptb-z /bsd: firefox[1]: pledge "flock", syscall 92 >>
>> Jun 22 11:21:21 ptb-z /bsd: firefox[17962]: pledge "flock", syscall 92
 Jun 22 11:21:22 ptb-z /bsd: firefox[47501]: pledge "flock", syscall
>> 92 >> >> (...) >> >> firefox[68021]: pledge "flock", syscall 92 >>
>> firefox[22469]: pledge "flock", syscall 92 >> firefox[41244]: pledge
>> "flock", syscall 92 >> >> ??? > > This happens sometimes when firefox is
>> calling into some library that > hits these syscalls, and those syscalls
>> are not in the firefox pledge. > In my experience this is often some
>> uncommon code path through X, > usually related to which graphics driver
>> you are using, but it could be > anything. When I have this happen to
>> me, it is always on specific > websites that trigger some rendering
>> codepath through X that uses some > unusual way to allocate memory or
>> something. In your case, it could also > be some extension you have
>> loaded. > > You can pretty easily see what is going wrong: > > When a
>> firefox tab crashes you should have a firefox.core file lying > around
>> (usually in your $HOME, but it will be wherever you launched > firefox
>> from). Run gdb on /usr/local/bin/firefox, and then load up the > core
>> file. It will drop you into the spot where firefox was killed, and > you
>> can check the backtrace to see what code path took you to the system >
>> call that hasn't been pledged. > > In this instance, firefox is calling
>> fcntl, which is covered by the > "flock" pledge. You can add "flock" to
>> the > security.sandbox.pledge.content line in about:config and see if
>> that > makes it work for you. If you have at all modified the firefox
>> content > or main pledges from their defaults, you should check to see
>> if > reverting to their defaults helps ("flock" is in the main pledge by
>>> default, but not in the content pledge). > > Hope this helps.
>> Hi,
>>
>> Now, Firefox tab crash; as you wrote, I try gdb:
>>
>> $ gdb /usr/local/bin/firefox
>> GNU gdb 6.3
>> Copyright 2004 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and you are
>> welcome to change it and/or distribute copies of it under certain
>> conditions.
>> Type "show copying" to see the conditions.
>> There is absolutely no warranty for GDB.  Type "show warranty" for details.
>> This GDB was configured as "amd64-unknown-openbsd6.5"...(no debugging
>> symbols found)
>>
>> (gdb) core-file firefox.core
>> warning: Couldn't find general-purpose registers in core file.
>>
>> warning: Couldn't find general-purpose registers in core file.
>>
>> #0  0x in ?? ()
>> (gdb) backtrace
>> #0  0x in ?? ()
>> Cannot access memory at address 0x0
>> (gdb) q
>>
>> What do you want another?
>>
>>
>> -- 
>> ~ " Fully Basic System Distinguish Life! " ~ " Libre as a BSD " +=<<<
>> 
>> Stephane HUC as PengouinBSD or CIOTBSD
>> b...@stephane-huc.net
>>
>>
-- 
~ " Fully Basic System

Core firefox, was: (Re: alc0 watchdog timeout)

2019-06-26 Thread PengouinBSD 
On 6/22/19 5:32 PM, Todd Mortimer wrote:
> On Sat, Jun 22, 2019 at 12:25:30PM +0200, Stephane HUC "PengouinBSD" wrote: 
> >> (...) >> >> Perhaps, for Firefox, it's a problem with pledge? >> >>
I see thoses messages in /var/log/messages - egual on 'dmesg': >> >> Jun
22 11:21:21 ptb-z /bsd: firefox[1]: pledge "flock", syscall 92 >>
Jun 22 11:21:21 ptb-z /bsd: firefox[17962]: pledge "flock", syscall 92
>> Jun 22 11:21:22 ptb-z /bsd: firefox[47501]: pledge "flock", syscall
92 >> >> (...) >> >> firefox[68021]: pledge "flock", syscall 92 >>
firefox[22469]: pledge "flock", syscall 92 >> firefox[41244]: pledge
"flock", syscall 92 >> >> ??? > > This happens sometimes when firefox is
calling into some library that > hits these syscalls, and those syscalls
are not in the firefox pledge. > In my experience this is often some
uncommon code path through X, > usually related to which graphics driver
you are using, but it could be > anything. When I have this happen to
me, it is always on specific > websites that trigger some rendering
codepath through X that uses some > unusual way to allocate memory or
something. In your case, it could also > be some extension you have
loaded. > > You can pretty easily see what is going wrong: > > When a
firefox tab crashes you should have a firefox.core file lying > around
(usually in your $HOME, but it will be wherever you launched > firefox
from). Run gdb on /usr/local/bin/firefox, and then load up the > core
file. It will drop you into the spot where firefox was killed, and > you
can check the backtrace to see what code path took you to the system >
call that hasn't been pledged. > > In this instance, firefox is calling
fcntl, which is covered by the > "flock" pledge. You can add "flock" to
the > security.sandbox.pledge.content line in about:config and see if
that > makes it work for you. If you have at all modified the firefox
content > or main pledges from their defaults, you should check to see
if > reverting to their defaults helps ("flock" is in the main pledge by
> default, but not in the content pledge). > > Hope this helps.
Hi,

Now, Firefox tab crash; as you wrote, I try gdb:

$ gdb /usr/local/bin/firefox
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd6.5"...(no debugging
symbols found)

(gdb) core-file firefox.core
warning: Couldn't find general-purpose registers in core file.

warning: Couldn't find general-purpose registers in core file.

#0  0x in ?? ()
(gdb) backtrace
#0  0x in ?? ()
Cannot access memory at address 0x0
(gdb) q

What do you want another?


-- 
~ " Fully Basic System Distinguish Life! " ~ " Libre as a BSD " +=<<<

Stephane HUC as PengouinBSD or CIOTBSD
b...@stephane-huc.net

Re: alc0 watchdog timeout

2019-06-22 Thread Todd Mortimer 
On Sat, Jun 22, 2019 at 12:25:30PM +0200, Stephane HUC "PengouinBSD" wrote:
> HI
> 
> On 6.5-current:
> 
> As I wrote @ 1:46 AM, it seems OK!
> 
> But, I experiment some troubles on my connexion:
> 
> - unwanted SSH disconnections
> 
> - on X, with Firefox, tabs crashed always in same time.
> 
> Perhaps, for Firefox, it's a problem with pledge?
> 
> I see thoses messages in /var/log/messages - egual on 'dmesg':
> 
> Jun 22 11:21:21 ptb-z /bsd: firefox[1]: pledge "flock", syscall 92
> Jun 22 11:21:21 ptb-z /bsd: firefox[17962]: pledge "flock", syscall 92
> Jun 22 11:21:22 ptb-z /bsd: firefox[47501]: pledge "flock", syscall 92
> 
> (...)
> 
> firefox[68021]: pledge "flock", syscall 92
> firefox[22469]: pledge "flock", syscall 92
> firefox[41244]: pledge "flock", syscall 92
> 
> ???

This happens sometimes when firefox is calling into some library that
hits these syscalls, and those syscalls are not in the firefox pledge.
In my experience this is often some uncommon code path through X,
usually related to which graphics driver you are using, but it could be
anything. When I have this happen to me, it is always on specific
websites that trigger some rendering codepath through X that uses some
unusual way to allocate memory or something. In your case, it could also
be some extension you have loaded.

You can pretty easily see what is going wrong:

When a firefox tab crashes you should have a firefox.core file lying
around (usually in your $HOME, but it will be wherever you launched
firefox from). Run gdb on /usr/local/bin/firefox, and then load up the
core file. It will drop you into the spot where firefox was killed, and
you can check the backtrace to see what code path took you to the system
call that hasn't been pledged.

In this instance, firefox is calling fcntl, which is covered by the
"flock" pledge. You can add "flock" to the
security.sandbox.pledge.content line in about:config and see if that
makes it work for you. If you have at all modified the firefox content
or main pledges from their defaults, you should check to see if
reverting to their defaults helps ("flock" is in the main pledge by
default, but not in the content pledge).

Hope this helps.

Re: alc0 watchdog timeout

2019-06-22 Thread Stephane HUC "PengouinBSD" 
HI

On 6.5-current:

As I wrote @ 1:46 AM, it seems OK!

But, I experiment some troubles on my connexion:

- unwanted SSH disconnections

- on X, with Firefox, tabs crashed always in same time.

Perhaps, for Firefox, it's a problem with pledge?

I see thoses messages in /var/log/messages - egual on 'dmesg':

Jun 22 11:21:21 ptb-z /bsd: firefox[1]: pledge "flock", syscall 92
Jun 22 11:21:21 ptb-z /bsd: firefox[17962]: pledge "flock", syscall 92
Jun 22 11:21:22 ptb-z /bsd: firefox[47501]: pledge "flock", syscall 92

(...)

firefox[68021]: pledge "flock", syscall 92
firefox[22469]: pledge "flock", syscall 92
firefox[41244]: pledge "flock", syscall 92

???

On 6/22/19 6:27 AM, Kevin Lo wrote:
> On Fri, Jun 21, 2019 at 09:44:12PM +0200, Stephane HUC "PengouinBSD" wrote:
>> HI,
> Hi,
>
>> To communicate on Internet, with my laptop - a Dell Alienware 13 - I
>> use an external LAN Adapter USB to RJ. This run correcty!
>>
>> I did not notice / understood that the physical network card was managed
>> .
>>
>> $ grep alc0 dmesg.txt
>>
>> alc0 at pci2 dev 0 function 0 "Attansic Technology E2200" rev 0x10:
>> msi, address 34:e6:d7:1b:7f:14
>> atphy0 at alc0 phy 0: AR8035 10/100/1000 PHY, rev. 9
>>
>> But, if I configure inet and inet6 on hostname.alc0 file, either dhcp
>> or static informations, dmesg filled with "alc0: watchdog timeout" and
>> /var/log/messages grow up!
>>
>> Into /var/log/messages, as:
>> Jun 21 16:13:26 ptb-aw13zou /bsd: alc0: watchdog timeout
>> Jun 21 16:14:00 ptb-aw13zou /bsd: alc0: watchdog timeout
>> Jun 21 16:15:56 ptb-aw13zou last message repeated 5 times
>> Jun 21 16:25:39 ptb-aw13zou last message repeated 20 times
>> Jun 21 16:35:34 ptb-aw13zou last message repeated 21 times
>> Jun 21 16:45:57 ptb-aw13zou last message repeated 22 times
>> Jun 21 16:55:56 ptb-aw13zou last message repeated 19 times
>> Jun 21 17:05:46 ptb-aw13zou last message repeated 22 times
>> Jun 21 17:15:37 ptb-aw13zou last message repeated 22 times
>> Jun 21 17:25:30 ptb-aw13zou last message repeated 22 times
>> Jun 21 17:27:54 ptb-aw13zou last message repeated 4 times
>>
>> With 'dhcp', the system reply: "no lease".
>>
>> Someone can explain-me the reason (simply), please?!
>> (and, perhaps, found a solution…)
> I think this bug has been fixed in r1.48.  Please try -current, thanks.
>

Re: alc0 watchdog timeout

2019-06-21 Thread Kevin Lo 
On Fri, Jun 21, 2019 at 09:44:12PM +0200, Stephane HUC "PengouinBSD" wrote:
> 
> HI,

Hi,

> To communicate on Internet, with my laptop - a Dell Alienware 13 - I
> use an external LAN Adapter USB to RJ. This run correcty!
> 
> I did not notice / understood that the physical network card was managed
> .
> 
> $ grep alc0 dmesg.txt
> 
> alc0 at pci2 dev 0 function 0 "Attansic Technology E2200" rev 0x10:
> msi, address 34:e6:d7:1b:7f:14
> atphy0 at alc0 phy 0: AR8035 10/100/1000 PHY, rev. 9
> 
> But, if I configure inet and inet6 on hostname.alc0 file, either dhcp
> or static informations, dmesg filled with "alc0: watchdog timeout" and
> /var/log/messages grow up!
> 
> Into /var/log/messages, as:
> Jun 21 16:13:26 ptb-aw13zou /bsd: alc0: watchdog timeout
> Jun 21 16:14:00 ptb-aw13zou /bsd: alc0: watchdog timeout
> Jun 21 16:15:56 ptb-aw13zou last message repeated 5 times
> Jun 21 16:25:39 ptb-aw13zou last message repeated 20 times
> Jun 21 16:35:34 ptb-aw13zou last message repeated 21 times
> Jun 21 16:45:57 ptb-aw13zou last message repeated 22 times
> Jun 21 16:55:56 ptb-aw13zou last message repeated 19 times
> Jun 21 17:05:46 ptb-aw13zou last message repeated 22 times
> Jun 21 17:15:37 ptb-aw13zou last message repeated 22 times
> Jun 21 17:25:30 ptb-aw13zou last message repeated 22 times
> Jun 21 17:27:54 ptb-aw13zou last message repeated 4 times
> 
> With 'dhcp', the system reply: "no lease".
> 
> Someone can explain-me the reason (simply), please?!
> (and, perhaps, found a solution…)

I think this bug has been fixed in r1.48.  Please try -current, thanks.

Re: alc0 watchdog timeout

2019-06-21 Thread Stephane HUC "PengouinBSD" 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi, Brad.

With -current, it seems run correctly.

dhclient: ok

statics inet4 and inet6 seem to good.

Do you want some tests?

On 6/21/19 11:24 PM, Brad Smith wrote:
> Can you please try -current and let me know if it works any better? > > On 
> 6/21/2019 3:44 PM, Stephane HUC "PengouinBSD" wrote: >> HI, >>
>> To communicate on Internet, with my laptop - a Dell Alienware 13 - I
>> use an external LAN Adapter USB to RJ. This run correcty! >> >> I did
not notice / understood that the physical network card was managed >> .
>> >> $ grep alc0 dmesg.txt >> >> alc0 at pci2 dev 0 function 0
"Attansic Technology E2200" rev 0x10: >> msi, address 34:e6:d7:1b:7f:14
>> atphy0 at alc0 phy 0: AR8035 10/100/1000 PHY, rev. 9 >> >> But, if I
configure inet and inet6 on hostname.alc0 file, either dhcp >> or static
informations, dmesg filled with "alc0: watchdog timeout" and >>
/var/log/messages grow up! >> >> Into /var/log/messages, as: >> Jun 21
16:13:26 ptb-aw13zou /bsd: alc0: watchdog timeout >> Jun 21 16:14:00
ptb-aw13zou /bsd: alc0: watchdog timeout >> Jun 21 16:15:56 ptb-aw13zou
last message repeated 5 times >> Jun 21 16:25:39 ptb-aw13zou last
message repeated 20 times >> Jun 21 16:35:34 ptb-aw13zou last message
repeated 21 times >> Jun 21 16:45:57 ptb-aw13zou last message repeated
22 times >> Jun 21 16:55:56 ptb-aw13zou last message repeated 19 times
>> Jun 21 17:05:46 ptb-aw13zou last message repeated 22 times >> Jun 21
17:15:37 ptb-aw13zou last message repeated 22 times >> Jun 21 17:25:30
ptb-aw13zou last message repeated 22 times >> Jun 21 17:27:54
ptb-aw13zou last message repeated 4 times >> >> With 'dhcp', the system
reply: "no lease". >> >> Someone can explain-me the reason (simply),
please?! >> (and, perhaps, found a solution…) >> >>  >> >> My dmesg:
>> OpenBSD 6.5 (GENERIC.MP) #0: Wed Apr 24 23:38:54 CEST 2019 >> >>
r...@syspatch-65-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENER
>> IC.MP >> real mem = 8487260160 (8094MB) >> avail mem = 8220405760
(7839MB) >> mpath0 at root >> scsibus0 at mpath0: 256 targets >>
mainbus0 at root >> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec580 (74
entries) >> bios0: vendor Alienware version "A08" date 01/25/2018 >>
bios0: Alienware Alienware 13 >> acpi0 at bios0: rev 2 >> acpi0: sleep
states S0 S3 S4 S5 >> acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET
SSDT UEFI SSDT ASF! >> SLIC SSDT SSDT SSDT SSDT CSRT SSDT >> acpi0:
wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) >> PEG2(S4)
PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) >> PXSX(S4)
RP04(S4) RP05(S4) PEGP(S4) [...] >> 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) i5-4210U
CPU @ 1.70GHz, 799.46 MHz, 06-45-01 >> cpu0: >>
FPU,VME,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,SSE3,PCLMUL,DTES64,MWAIT,
>>
DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOV
>>
BE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAH
>>
F,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIB
>> P,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN >> cpu0: 256KB 64b/line
8-way L2 cache >> cpu0: smt 0, core 0, package 0 >> mtrr: Pentium Pro
MTRR support, 10 var ranges, 88 fixed ranges >> cpu0: apic clock running
at 99MHz >> cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
>> cpu1 at mainbus0: apid 2 (application processor) >> cpu1: Intel(R)
Core(TM) i5-4210U CPU @ 1.70GHz, 799.31 MHz, 06-45-01 >> cpu1: >>
FPU,VME,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,SSE3,PCLMUL,DTES64,MWAIT,
>>
DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOV
>>
BE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAH
>>
F,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIB
>> P,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN >> cpu1: 256KB 64b/line
8-way L2 cache >> cpu1: smt 0, core 1, package 0 >> cpu2 at mainbus0:
apid 1 (application processor) >> cpu2: Intel(R) Core(TM) i5-4210U CPU @
1.70GHz, 799.31 MHz, 06-45-01 >> cpu2: >>
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,
>>
CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HT

alc0 watchdog timeout

2019-06-21 Thread Stephane HUC "PengouinBSD" 
HI,

To communicate on Internet, with my laptop - a Dell Alienware 13 - I
use an external LAN Adapter USB to RJ. This run correcty!

I did not notice / understood that the physical network card was managed
.

$ grep alc0 dmesg.txt

alc0 at pci2 dev 0 function 0 "Attansic Technology E2200" rev 0x10:
msi, address 34:e6:d7:1b:7f:14
atphy0 at alc0 phy 0: AR8035 10/100/1000 PHY, rev. 9

But, if I configure inet and inet6 on hostname.alc0 file, either dhcp
or static informations, dmesg filled with "alc0: watchdog timeout" and
/var/log/messages grow up!

Into /var/log/messages, as:
Jun 21 16:13:26 ptb-aw13zou /bsd: alc0: watchdog timeout
Jun 21 16:14:00 ptb-aw13zou /bsd: alc0: watchdog timeout
Jun 21 16:15:56 ptb-aw13zou last message repeated 5 times
Jun 21 16:25:39 ptb-aw13zou last message repeated 20 times
Jun 21 16:35:34 ptb-aw13zou last message repeated 21 times
Jun 21 16:45:57 ptb-aw13zou last message repeated 22 times
Jun 21 16:55:56 ptb-aw13zou last message repeated 19 times
Jun 21 17:05:46 ptb-aw13zou last message repeated 22 times
Jun 21 17:15:37 ptb-aw13zou last message repeated 22 times
Jun 21 17:25:30 ptb-aw13zou last message repeated 22 times
Jun 21 17:27:54 ptb-aw13zou last message repeated 4 times

With 'dhcp', the system reply: "no lease".

Someone can explain-me the reason (simply), please?!
(and, perhaps, found a solution…)



My dmesg:
OpenBSD 6.5 (GENERIC.MP) #0: Wed Apr 24 23:38:54 CEST 2019

r...@syspatch-65-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENER
IC.MP
real mem = 8487260160 (8094MB)
avail mem = 8220405760 (7839MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec580 (74 entries)
bios0: vendor Alienware version "A08" date 01/25/2018
bios0: Alienware Alienware 13
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI SSDT ASF!
SLIC SSDT SSDT SSDT SSDT CSRT SSDT
acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4)
PEG2(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4)
PXSX(S4) RP04(S4) RP05(S4) PEGP(S4) [...]
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) i5-4210U CPU @ 1.70GHz, 799.46 MHz, 06-45-01
cpu0:
FPU,VME,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,SSE3,PCLMUL,DTES64,MWAIT,
DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOV
BE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAH
F,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIB
P,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz, 799.31 MHz, 06-45-01
cpu1:
FPU,VME,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,SSE3,PCLMUL,DTES64,MWAIT,
DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOV
BE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAH
F,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIB
P,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz, 799.31 MHz, 06-45-01
cpu2:
FPU,VME,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,SSE3,PCLMUL,DTES64,MWAIT,
DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOV
BE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAH
F,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIB
P,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz, 799.31 MHz, 06-45-01
cpu3:
FPU,VME,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,SSE3,PCLMUL,DTES64,MWAIT,
DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOV
BE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAH
F,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIB
P,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
acpimadt0: bogus nmi for apid 0
acpimadt0: bogus nmi for apid 2
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14