Logging/backup .ksh_history
Hi, I use /bin/ksh as a console/terminal shell program, I want to log/backup all command, run on console/terminal/ksh, Any idea how to do this? Thanks. -- Key ID: 0xCF2C80AC Key fingerprint: CDB3 6C62 254B C088 1E5D DD32 182C 97DB CF2C 80AC 0xCF2C80AC.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: OpenBSD Songs - License
On 08/05/16 13:32, 46rc1p+8qbgq1pcsq...@guerrillamail.com wrote: > Hi all, > > I've just discovered the OpenBSD Songs, but unfortunately I can't > tell under which license they've been released. It would be really helpful if > you could update your website with this information > > - license of audio files > - license of the lyric texts > > Thank you in advance! Since no license is stated, no license exists. It falls under simple copyright laws, which means you have no license (no additional rights) to use it for anything other than simple copyright law permits. Nick.
Re: github
On 08/07/16 08:44, Dariusz Sendkowski wrote: > Is this http://[bullshit deleted]/openbsd the official OpenBSD github site? I find this part terrifying. Nowhere on the OpenBSD website mentions github as anything official. So you just assumed that the seven letters, "openbsd", in that order, makes it officially part of the project? No. Examples of this will be found all over the Internet. How about lock graphics on websites and the word "secure"? Internet 101: anyone can put anything in any URL. Or twisting Duke Ellington, "It don't mean a thing, just 'cause it has a string" Nick.
ksh, ctrl-r followed by arrow key leaves "[D" or "[C" artifacts
I'll try to describe an annoyance with my ksh setup. Web and man page searching has not provided a solution. I'm relatively new to both ksh and openbsd. I'm on version 5.9 release. Problem happens when I navigate command history with ctrl-r, then use left or right arrow. Hitting left arrow writes "[D", right inserts "[C". I'm hitting the arrow keys so I can edit my prior command. It's a habit I'm used to that works in bash. For example to reproduce, let's say I ran "ls -l" but I wanted to run "ls -la"... run the first command, "ls -l". type "ctrl-r ls". This works as expected, and my cursor is now in the middle of "ls -l". type right arrow. This is where the problem is. The command I'm editing becomes "ls[C -l". >From this point, arrow keys work as expected. I can use left or right to >navigate and edit the command. If, instead of arrows, I use ctrl-b or ctrl-f, these work fine. No artifacts like "[C" or "[D". If I use bash instead of ksh, this problem does not occur. I found suggestions to add aliases like the following to ~/.ksh, which I've attempted but seem to have no effect: alias __C=`echo "\006"` # right arrow = ^f = forward a character alias __D=`echo "\002"` # left arrow = ^b = back a character I understand from `man ksh` that these key bindings are defaults: bind '^[[C'=forward-char bind '^[[D'=backward-char My assumption is that when in ctrl-r mode, the '^[' is interpreted as part of the ctrl-r search (which doesn't match), then the '[C' or '[D' is interpreted as the next key (which is inserted). Can this behavior be changed? Any help appreciated. Thanks! -Dave
Re: opportunity to help: %s audit in mandoc
Hi Dariusz, Dariusz Sendkowski wrote on Sun, Aug 07, 2016 at 08:27:07PM +0200: > OK, but from which branch? We don't use branches in OpenBSD. Just use the HEAD of the OpenBSD CVS repository. You don't need to worry about merging to the portable mandoc on mdocml.bsd.lv. That's a no-brainer i'll take care of. > Can the results be sent incrementally? Yes, that's ideal. Don't work for days before sending anything. Imagine you misunderstand something and only learn about your error after having wasted days of work. That would be bad. Or imagine two people start working on the same task and work for days, both preparing the same huge report. That would be a waste, too. That cannot happen if you send results incrementally right after finding them. In general, OpenBSD prefers small patches that are easy to understand and verify, in particular from new contributors. They need not be easy to produce, though. Yours, Ingo
Re: opportunity to help: %s audit in mandoc
OK, but from which branch?
Can the results be sent incrementally?
2016-08-07 19:57 GMT+02:00 Ingo Schwarze :
> Hi,
>
> from time to time, people ask how they can help OpenBSD development
> if they are new to that task.
>
> Right now, there is a useful opportunity. Take the code in
> /usr/src/usr.bin/mandoc/, grep(1) it for "%s", and audit all instances
> you find, figuring out whether they can be reached with the char *
> being NULL or not. If you find one where the pointer can be NULL,
> construct an input file and a command line (for example, "'mandoc
> -Tlint foo.mdoc' or 'makewhatis -t foo.mdoc' with the attached
> file foo.mdoc") demonstrating that man(1), apropos(1), mandoc(1),
> or makewhatis(8) actually print "(null)", and send the report to
> me.
>
> The task is not very difficult, but requires considerable time (i
> guess i would need up to two days to do the full audit, even though
> i know the code very well). I have a huge backlog of patches to
> check and a huge backlog of tricky programming tasks to tackle.
> Once somebody finds these issues for me, fixing them is trivial,
> and i can focus on work that is less easy to do for newcomers.
>
> Besides, this will improve your code reading and auditing skills.
> If you find a few things, you could even try to tackle other
> parts of the tree which are more difficult.
>
> In mandoc, there are almost certainly some instances because
> until now, i wasn't aware that printf("%s", NULL) is problematic.
>
> Yours,
> Ingo
opportunity to help: %s audit in mandoc
Hi,
from time to time, people ask how they can help OpenBSD development
if they are new to that task.
Right now, there is a useful opportunity. Take the code in
/usr/src/usr.bin/mandoc/, grep(1) it for "%s", and audit all instances
you find, figuring out whether they can be reached with the char *
being NULL or not. If you find one where the pointer can be NULL,
construct an input file and a command line (for example, "'mandoc
-Tlint foo.mdoc' or 'makewhatis -t foo.mdoc' with the attached
file foo.mdoc") demonstrating that man(1), apropos(1), mandoc(1),
or makewhatis(8) actually print "(null)", and send the report to
me.
The task is not very difficult, but requires considerable time (i
guess i would need up to two days to do the full audit, even though
i know the code very well). I have a huge backlog of patches to
check and a huge backlog of tricky programming tasks to tackle.
Once somebody finds these issues for me, fixing them is trivial,
and i can focus on work that is less easy to do for newcomers.
Besides, this will improve your code reading and auditing skills.
If you find a few things, you could even try to tackle other
parts of the tree which are more difficult.
In mandoc, there are almost certainly some instances because
until now, i wasn't aware that printf("%s", NULL) is problematic.
Yours,
Ingo
Re: github
OpenBSD is using CVS solely, but for my own purposes I started to mirror src to github recently using cvs2gitdump tool. I do this since I find git log/git show more friendly than CVS provided tools... If you are interested see https://github.com/kgardas/openbsd-src -- CAVEAT! Do not trust the source code there and especially do not use it for your own OpenBSD build. In case of any doubts please use OpenBSD CVS's src as a reference. BTW I've tried to search among src's mirror on github.com but all were out-dated and needed to have src in git after spacehopper.org's git stopped working... On Sun, Aug 7, 2016 at 6:57 PM, Dariusz Sendkowski wrote: > 2016-08-07 18:42 GMT+02:00 Chris Bennett < > chrisbenn...@bennettconstruction.us>: > >> On Sun, Aug 07, 2016 at 10:06:56AM -0600, Jack J. Woehr wrote: >> > whereas on GitHub it would belong to a corporation. >> > >> > Doesn't that simply end the discussion right there? >> >> Yes. >> This thread has been informative to me. >> Forget the silly move from CVS part, never was an issue. >> >> I did NOT know that GitHub was a corporation. I find that very >> disturbing. Extremely disturbing. >> >> May all your pkg_* include: >> pkg_delete git >> > > > I'm afraid you're confusing git with github. > > > >> >> So there was a jewel to be found in this thread. >> Thank you all for this. >> >> Sorry if I was a bit noisy, I'm just so tired of seeing so many projects >> hooked on git. It's like a fad. What's next? Turdd. Shitt. Crapplee.
Re: github
2016-08-07 18:42 GMT+02:00 Chris Bennett < chrisbenn...@bennettconstruction.us>: > On Sun, Aug 07, 2016 at 10:06:56AM -0600, Jack J. Woehr wrote: > > whereas on GitHub it would belong to a corporation. > > > > Doesn't that simply end the discussion right there? > > Yes. > This thread has been informative to me. > Forget the silly move from CVS part, never was an issue. > > I did NOT know that GitHub was a corporation. I find that very > disturbing. Extremely disturbing. > > May all your pkg_* include: > pkg_delete git > I'm afraid you're confusing git with github. > > So there was a jewel to be found in this thread. > Thank you all for this. > > Sorry if I was a bit noisy, I'm just so tired of seeing so many projects > hooked on git. It's like a fad. What's next? Turdd. Shitt. Crapplee.
Re: github
On Sun, Aug 07, 2016 at 10:06:56AM -0600, Jack J. Woehr wrote: > whereas on GitHub it would belong to a corporation. > > Doesn't that simply end the discussion right there? Yes. This thread has been informative to me. Forget the silly move from CVS part, never was an issue. I did NOT know that GitHub was a corporation. I find that very disturbing. Extremely disturbing. May all your pkg_* include: pkg_delete git So there was a jewel to be found in this thread. Thank you all for this. Sorry if I was a bit noisy, I'm just so tired of seeing so many projects hooked on git. It's like a fad. What's next? Turdd. Shitt. Crapplee.
Re: github
> On 18:12 Sun 07 Aug, ludovic coues wrote: > > 2016-08-07 18:00 GMT+02:00 Consus : > > > On 10:56 Sun 07 Aug, Chris Bennett wrote: > > >> On Sun, Aug 07, 2016 at 06:43:02PM +0300, Consus wrote: > > >> > Sign your commits with GPG. Looky, a link: > > >> > > > >> > https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work > > >> > > > >> > Not that hard, is it? > > >> > > > >> > > >> OK, you win. > > >> > > >> Would you do me a favor first. > > >> Before this big move, could you make a commit to the OpenBSD CVS tree? > > >> Anything would do. Just find a file that has spaces where it should have > > >> tabs. Commit your diff. Once you do that, I think all of the developers > > >> will be easily convinced to move to Github. > > > > > > Err... What? > > > > > > > You are talking big while not contributing to the project. > > So? I'm not stating YOU GUYS SHOULD MOVE TO GITHUB RIGHT NOW. I'm > stating that "github is not secure" is bullshit. > Just stop it. We are not going to listen to you.
Re: github
>From all discussions: 1) a solution looking for a problem 2) the problems github tries to address are not considered urgent nor important problems by OpenBSD developers 3) migration cost/benefit is not worth it - and using 2 different methods of VC take away focus from the team". On Sunday, 7 August 2016, Jack J. Woehr wrote: > Ingo Schwarze wrote: > >> Hi, >> >> Dariusz Sendkowski wrote on Sun, Aug 07, 2016 at 02:44:58PM +0200: >> >> Is this https://github.com/openbsd the official OpenBSD github site? >>> >> As one of the OpenBSD developers, i don't know and frankly i don't >> care. You certainly shouldn't trust it in any way. >> > > It seems this discussion has gone on quite a while without stating the > obvious: > > 1. The developers are happy with CVS. > 2. As is, OpenBSD has full goddawmitey control of their source repository > whereas on GitHub it would belong to a corporation. > > Doesn't that simply end the discussion right there? > > -- > Jack J. Woehr # Science is more than a body of knowledge. It's a way of > www.well.com/~jax # thinking, a way of skeptically interrogating the > universe > www.softwoehr.com # with a fine understanding of human fallibility. - > Carl Sagan
Re: github
On 18:12 Sun 07 Aug, ludovic coues wrote: > 2016-08-07 18:00 GMT+02:00 Consus : > > On 10:56 Sun 07 Aug, Chris Bennett wrote: > >> On Sun, Aug 07, 2016 at 06:43:02PM +0300, Consus wrote: > >> > Sign your commits with GPG. Looky, a link: > >> > > >> > https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work > >> > > >> > Not that hard, is it? > >> > > >> > >> OK, you win. > >> > >> Would you do me a favor first. > >> Before this big move, could you make a commit to the OpenBSD CVS tree? > >> Anything would do. Just find a file that has spaces where it should have > >> tabs. Commit your diff. Once you do that, I think all of the developers > >> will be easily convinced to move to Github. > > > > Err... What? > > > > You are talking big while not contributing to the project. So? I'm not stating YOU GUYS SHOULD MOVE TO GITHUB RIGHT NOW. I'm stating that "github is not secure" is bullshit.
Re: github
2016-08-07 18:00 GMT+02:00 Consus : > On 10:56 Sun 07 Aug, Chris Bennett wrote: >> On Sun, Aug 07, 2016 at 06:43:02PM +0300, Consus wrote: >> > Sign your commits with GPG. Looky, a link: >> > >> > https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work >> > >> > Not that hard, is it? >> > >> >> OK, you win. >> >> Would you do me a favor first. >> Before this big move, could you make a commit to the OpenBSD CVS tree? >> Anything would do. Just find a file that has spaces where it should have >> tabs. Commit your diff. Once you do that, I think all of the developers >> will be easily convinced to move to Github. > > Err... What? > You are talking big while not contributing to the project. -- Cordialement, Coues Ludovic +336 148 743 42
Re: github
Ingo Schwarze wrote: Hi, Dariusz Sendkowski wrote on Sun, Aug 07, 2016 at 02:44:58PM +0200: Is this https://github.com/openbsd the official OpenBSD github site? As one of the OpenBSD developers, i don't know and frankly i don't care. You certainly shouldn't trust it in any way. It seems this discussion has gone on quite a while without stating the obvious: 1. The developers are happy with CVS. 2. As is, OpenBSD has full goddawmitey control of their source repository whereas on GitHub it would belong to a corporation. Doesn't that simply end the discussion right there? -- Jack J. Woehr # Science is more than a body of knowledge. It's a way of www.well.com/~jax # thinking, a way of skeptically interrogating the universe www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan
Re: github
On 10:56 Sun 07 Aug, Chris Bennett wrote: > On Sun, Aug 07, 2016 at 06:43:02PM +0300, Consus wrote: > > Sign your commits with GPG. Looky, a link: > > > > https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work > > > > Not that hard, is it? > > > > OK, you win. > > Would you do me a favor first. > Before this big move, could you make a commit to the OpenBSD CVS tree? > Anything would do. Just find a file that has spaces where it should have > tabs. Commit your diff. Once you do that, I think all of the developers > will be easily convinced to move to Github. Err... What?
Re: github
On Sun, Aug 07, 2016 at 06:43:02PM +0300, Consus wrote: > Sign your commits with GPG. Looky, a link: > > https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work > > Not that hard, is it? > OK, you win. Would you do me a favor first. Before this big move, could you make a commit to the OpenBSD CVS tree? Anything would do. Just find a file that has spaces where it should have tabs. Commit your diff. Once you do that, I think all of the developers will be easily convinced to move to Github.
Re: github
On 10:35 Sun 07 Aug, Chris Bennett wrote: > On Sun, Aug 07, 2016 at 11:17:21AM -0400, Donald Allen wrote: > > > Date: Sun, 7 Aug 2016 17:59:07 +0300 > > > From: con...@gmx.com > > > To: > > misc@openbsd.org > > > Subject: Re: github > > > > > > > And github offers two-factor authentication, so if enabled, not simple > > to hack the account. > > > > Github is running OpenBSD? I didn't know that. > That's a relief. I wouldn't trust any of my critical data with any less > secure Operating Ayatem. Sign your commits with GPG. Looky, a link: https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work Not that hard, is it?
Re: github
On Sun, Aug 7, 2016 at 11:17 AM, Donald Allen wrote: >> Date: Sun, 7 Aug 2016 17:59:07 +0300 >> From: con...@gmx.com >> To: > misc@openbsd.org >> Subject: Re: github >> >> On 16:43 Sun 07 Aug, Ingo Schwarze > wrote: Do you have any plans to move the OpenBSD source code repository to github? >>> >>> Absolutely not. The OpenBSD repository will remain > secure and >>> will not be outsourced to a random third party. >> >> I'm sorry, > are we talking about the same OpenBSD CVS tree that does not >> offer any kind > of encryption and transfers all your data in plain over >> the network (except > for developers who use SSH of course)? How's that >> secure? >> >> Moreover, Git > itself allows you to check what the hell is going on using >> your local > history (e.g. git pull will not work without some love if >> somebody changes > your repo on the GitHub side without your awareness). >> Also signed commits > FWIW. > > And github offers two-factor authentication, so if enabled, not simple > to hack the account. > The openBSD tree is duplicated over the SSH protocol, not HTTPS; You are spreading miss information. -- - () ascii ribbon campaign - against html e-mail /\
Re: github
On Sun, Aug 07, 2016 at 11:17:21AM -0400, Donald Allen wrote: > > Date: Sun, 7 Aug 2016 17:59:07 +0300 > > From: con...@gmx.com > > To: > misc@openbsd.org > > Subject: Re: github > > > > And github offers two-factor authentication, so if enabled, not simple > to hack the account. > Github is running OpenBSD? I didn't know that. That's a relief. I wouldn't trust any of my critical data with any less secure Operating Ayatem.
Re: github
> Date: Sun, 7 Aug 2016 17:59:07 +0300 > From: con...@gmx.com > To: misc@openbsd.org > Subject: Re: github > > On 16:43 Sun 07 Aug, Ingo Schwarze wrote: >>> Do you have any plans to move the OpenBSD source code repository >>> to github? >> >> Absolutely not. The OpenBSD repository will remain secure and >> will not be outsourced to a random third party. > > I'm sorry, are we talking about the same OpenBSD CVS tree that does not > offer any kind of encryption and transfers all your data in plain over > the network (except for developers who use SSH of course)? How's that > secure? > > Moreover, Git itself allows you to check what the hell is going on using > your local history (e.g. git pull will not work without some love if > somebody changes your repo on the GitHub side without your awareness). > Also signed commits FWIW. And github offers two-factor authentication, so if enabled, not simple to hack the account.
Re: github
On 16:43 Sun 07 Aug, Ingo Schwarze wrote: > > Do you have any plans to move the OpenBSD source code repository > > to github? > > Absolutely not. The OpenBSD repository will remain secure and > will not be outsourced to a random third party. I'm sorry, are we talking about the same OpenBSD CVS tree that does not offer any kind of encryption and transfers all your data in plain over the network (except for developers who use SSH of course)? How's that secure? Moreover, Git itself allows you to check what the hell is going on using your local history (e.g. git pull will not work without some love if somebody changes your repo on the GitHub side without your awareness). Also signed commits FWIW.
Re: github
Hi, Dariusz Sendkowski wrote on Sun, Aug 07, 2016 at 02:44:58PM +0200: > Is this https://github.com/openbsd the official OpenBSD github site? As one of the OpenBSD developers, i don't know and frankly i don't care. You certainly shouldn't trust it in any way. Personally, i consider github commercial crap that is utterly unusable for anything. If you send me a github link, i'm very likely to completely ignore it even if i would in principle be quite interested in the content, simply because i'm not willing to waste my time on the crappy user interface. > Do you have any plans to move the OpenBSD source code repository > to github? Absolutely not. The OpenBSD repository will remain secure and will not be outsourced to a random third party. Even if OpenBSD, at some point in the future, would decide to do anything with git, i would very strongly oppose doing anything official whatsoever with github. Yours, Ingo
Re: github
Thanks. Original message From: Mike Burns Date: 8/7/16 14:51 (GMT+01:00) To: Dariusz Sendkowski Cc: misc Subject: Re: github On 2016-08-07 14.44.58 +0200, Dariusz Sendkowski wrote: > Is this https://github.com/openbsd the official OpenBSD github site? > Do you have any plans to move the OpenBSD source code repository to github? http://marc.info/?l=openbsd-misc&m=134408828426309&w=2
Re: github
On 2016-08-07 14.44.58 +0200, Dariusz Sendkowski wrote: > Is this https://github.com/openbsd the official OpenBSD github site? > Do you have any plans to move the OpenBSD source code repository to github? http://marc.info/?l=openbsd-misc&m=134408828426309&w=2
github
Is this https://github.com/openbsd the official OpenBSD github site? Do you have any plans to move the OpenBSD source code repository to github?
Re: acpiasus(4) not attached with EeePC 1000H on OpenBSD-current
On 29/07/2016 19:32, Dominique Goncalves wrote: My EeePC runs OpenBSD-current and works good. Since I updated the bios to the latest version, some hotkeys are not working as before. wireless and brightness hotkeys are working. standby and volume are not working. Since I have an Asus netbook I thought I'd dig out my 1015PX and replace 5.8 with the latest snapshot to see what happens. I'm seeing the same - acpiasus isn't appearing in dmesg and whereas before I had sleep, mute and volume up/down working now I have sleep and screen brightness up/down. dmesg 6.0: == OpenBSD 6.0 (GENERIC.MP) #2319: Tue Jul 26 13:00:43 MDT 2016 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2120744960 (2022MB) avail mem = 2052059136 (1956MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf0740 (31 entries) bios0: vendor American Megatrends Inc. version "1301" date 05/06/2011 bios0: ASUSTeK Computer INC. 1015PX acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG ECDT OEMB HPET GSCI SSDT SLIC acpi0: wakeup devices P0P1(S4) P0P4(S4) P0P5(S4) P0P6(S4) P0P7(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) Atom(TM) CPU N570 @ 1.66GHz, 1666.80 MHz 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR cpu0: 512KB 64b/line 8-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 166MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Atom(TM) CPU N570 @ 1.66GHz, 1666.48 MHz 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR cpu1: 512KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Atom(TM) CPU N570 @ 1.66GHz, 1666.48 MHz 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR cpu2: 512KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Atom(TM) CPU N570 @ 1.66GHz, 1666.48 MHz 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR cpu3: 512KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiec0 at acpi0 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 4 (P0P4) acpiprt2 at acpi0: bus 2 (P0P5) acpiprt3 at acpi0: bus -1 (P0P6) acpiprt4 at acpi0: bus 1 (P0P7) acpicpu0 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpitz0 at acpi0: critical temperature is 101 degC "PNP0303" at acpi0 not configured "SYN0A13" at acpi0 not configured acpibat0 at acpi0: BAT0 model "1015PE" serial type LION oem "ASUS" acpiac0 at acpi0: AC unit offline acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibtn2 at acpi0: PWRB "PNP0C14" at acpi0 not configured acpivideo0 at acpi0: VGA_ acpivout0 at acpivideo0: LCDD cpu0: Enhanced SpeedStep 1666 MHz: speeds: 1667, 1333, 1000 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Pineview DMI" rev 0x02 inteldrm0 at pci0 dev 2 function 0 "Intel Pineview Video" rev 0x02 drm0 at inteldrm0 intagp0 at inteldrm0 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0: msi inteldrm0: 1024x600 wsdisplay0 at inteldrm0 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: Realtek ALC269 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: msi pci1 at ppb0 bus 4 ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: msi pci2 at ppb1 bus 2 "Broadcom BCM4313" rev 0x01 at pci2 dev 0 function 0 not configured ppb2 at pci0 dev 28 function 3 "Int
