Re: SCSI and dmesg
On Thu, Nov 29, 2018 at 11:08 AM Brooks Davis wrote: > On Thu, Nov 29, 2018 at 11:01:01AM -0700, Alan Somers wrote: > > On Thu, Nov 29, 2018 at 10:49 AM Warner Losh wrote: > > > > > > > > > > > On Thu, Nov 29, 2018 at 8:09 AM Alan Somers > wrote: > > > > > >> On Mon, Nov 26, 2018 at 3:57 PM Warner Losh wrote: > > >> > > >>> On Mon, Nov 26, 2018 at 3:32 PM Maxim Sobolev > > > >>> wrote: > > >>> > > >>> > Somebody needs to make collection/submission automatic and make a > port > > >>> out > > >>> > of it, so that it's as easy as pkg install dmesg_survey && > > >>> > dmesg_survey_enabled="YES" in the /etc/rc.conf. JIMHO. I'd gladly > make > > >>> it a > > >>> > default on all dev boxes within our organization. Might also make a > > >>> nice > > >>> > SoC project idea. > > >>> > > > >>> > > >>> It's barely a weekend hack, since with the curl 1 liner 95% of what > you > > >>> want is there. > > >>> > > >>> This service isn't suitable, though, to have it in rc.conf, I don't > > >>> think, > > >>> unless it's updated only when there's a material change... > > >>> > > >>> And I'd rather we get more nuanced data than dmesg can provide if we > were > > >>> to do the data collection. The admonition to submit to this site was > one > > >>> of > > >>> expedience... > > >>> > > >>> Warner > > >>> > > >> > > >> Sounds like somebody needs to adopt sysutils/bsdstats. It's a great > > >> start, but it needs some TLC. > > >> > > > > > > Except there's no available data from it. And it's not a great start, > but > > > a terrible one. It gathers the wrong things. > > > > > > Warner > > > > > > > What do you mean "no available data"? Are you saying that you'd prefer > > direct access to the server rather than access through the web UI? I'm > > sure Scrappy would allow that. He's implied that he'd like some help > with > > the server. What I like about bsdstats is that it's much more structured > > than your dmesg service. Instead of a big long string, it gathers > > structured info with sysctl, pciconf, and pkg. Plus, it already has a > > port, it's integrated into periodic(8), and it has a website. If it > omits > > some information that you would like to see, then you should enhance it; > > not replace it. > > The data isn't available through the UI because it's broken. Try > drilling down to find all the NIC types for example and you'll get: > > ERROR !! > > an e-mail has been sent to the staff > we are sorry for this problem > > I've reported this multiple time and at least once Scrappy claimed it > was fixed, but it wasn't. > > -- Brooks > Try drilling down to find all the NIC types in dmesgd and you'll get nothing at all, because that feature doesn't exist. bsdstats obviously needs some TLC, but why reinvent the wheel? -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SCSI and dmesg
On Thu, Nov 29, 2018 at 11:01:01AM -0700, Alan Somers wrote: > On Thu, Nov 29, 2018 at 10:49 AM Warner Losh wrote: > > > > > > > On Thu, Nov 29, 2018 at 8:09 AM Alan Somers wrote: > > > >> On Mon, Nov 26, 2018 at 3:57 PM Warner Losh wrote: > >> > >>> On Mon, Nov 26, 2018 at 3:32 PM Maxim Sobolev > >>> wrote: > >>> > >>> > Somebody needs to make collection/submission automatic and make a port > >>> out > >>> > of it, so that it's as easy as pkg install dmesg_survey && > >>> > dmesg_survey_enabled="YES" in the /etc/rc.conf. JIMHO. I'd gladly make > >>> it a > >>> > default on all dev boxes within our organization. Might also make a > >>> nice > >>> > SoC project idea. > >>> > > >>> > >>> It's barely a weekend hack, since with the curl 1 liner 95% of what you > >>> want is there. > >>> > >>> This service isn't suitable, though, to have it in rc.conf, I don't > >>> think, > >>> unless it's updated only when there's a material change... > >>> > >>> And I'd rather we get more nuanced data than dmesg can provide if we were > >>> to do the data collection. The admonition to submit to this site was one > >>> of > >>> expedience... > >>> > >>> Warner > >>> > >> > >> Sounds like somebody needs to adopt sysutils/bsdstats. It's a great > >> start, but it needs some TLC. > >> > > > > Except there's no available data from it. And it's not a great start, but > > a terrible one. It gathers the wrong things. > > > > Warner > > > > What do you mean "no available data"? Are you saying that you'd prefer > direct access to the server rather than access through the web UI? I'm > sure Scrappy would allow that. He's implied that he'd like some help with > the server. What I like about bsdstats is that it's much more structured > than your dmesg service. Instead of a big long string, it gathers > structured info with sysctl, pciconf, and pkg. Plus, it already has a > port, it's integrated into periodic(8), and it has a website. If it omits > some information that you would like to see, then you should enhance it; > not replace it. The data isn't available through the UI because it's broken. Try drilling down to find all the NIC types for example and you'll get: ERROR !! an e-mail has been sent to the staff we are sorry for this problem I've reported this multiple time and at least once Scrappy claimed it was fixed, but it wasn't. -- Brooks signature.asc Description: PGP signature
Re: SCSI and dmesg
On Thu, Nov 29, 2018 at 10:49 AM Warner Losh wrote: > > > On Thu, Nov 29, 2018 at 8:09 AM Alan Somers wrote: > >> On Mon, Nov 26, 2018 at 3:57 PM Warner Losh wrote: >> >>> On Mon, Nov 26, 2018 at 3:32 PM Maxim Sobolev >>> wrote: >>> >>> > Somebody needs to make collection/submission automatic and make a port >>> out >>> > of it, so that it's as easy as pkg install dmesg_survey && >>> > dmesg_survey_enabled="YES" in the /etc/rc.conf. JIMHO. I'd gladly make >>> it a >>> > default on all dev boxes within our organization. Might also make a >>> nice >>> > SoC project idea. >>> > >>> >>> It's barely a weekend hack, since with the curl 1 liner 95% of what you >>> want is there. >>> >>> This service isn't suitable, though, to have it in rc.conf, I don't >>> think, >>> unless it's updated only when there's a material change... >>> >>> And I'd rather we get more nuanced data than dmesg can provide if we were >>> to do the data collection. The admonition to submit to this site was one >>> of >>> expedience... >>> >>> Warner >>> >> >> Sounds like somebody needs to adopt sysutils/bsdstats. It's a great >> start, but it needs some TLC. >> > > Except there's no available data from it. And it's not a great start, but > a terrible one. It gathers the wrong things. > > Warner > What do you mean "no available data"? Are you saying that you'd prefer direct access to the server rather than access through the web UI? I'm sure Scrappy would allow that. He's implied that he'd like some help with the server. What I like about bsdstats is that it's much more structured than your dmesg service. Instead of a big long string, it gathers structured info with sysctl, pciconf, and pkg. Plus, it already has a port, it's integrated into periodic(8), and it has a website. If it omits some information that you would like to see, then you should enhance it; not replace it. -Alan > > > > >> >>> >>> > -Max >>> > >>> > On Mon, Nov 26, 2018 at 2:08 PM Yuri Pankov wrote: >>> > >>> > > Yuri Pankov wrote: >>> > > > Warner Losh wrote: >>> > > >> Greetings >>> > > >> >>> > > >> a few weeks ago I pointed people to the nycbug dmesg service. I >>> said I >>> > > was >>> > > >> looking at data to drive SCSI retirement. I've gatherd some >>> > preliminary >>> > > >> data, which I've uploaded to >>> > > >> https://github.com/bsdimp/device-data/blob/master/cam.md along >>> with >>> > > some >>> > > >> preliminary notions of disposition for the hardware. I'm still >>> working >>> > > out >>> > > >> the kinks in the dmesg parsing, but this is interesting data. >>> > > >> >>> > > >> If you've not recently submitted, please consider doing so. We'll >>> be >>> > > >> finalizing the scsi SIMs that I'm going to propose retiring in 13 >>> here >>> > > in a >>> > > >> few weeks, and I'm going to base much of what list I come up with >>> > based >>> > > on >>> > > >> what is submitted. The glitches with FreeBSD dmesgs have been >>> cleared >>> > > up as >>> > > >> well. >>> > > >> >>> > > >> http://dmesgd.nycbug.org/index.cgi >>> > > >> >>> > > >> or >>> > > >> >>> > > >> curl -v -d "nickname=$USER" -d "email=$USER@$(hostname)" -d >>> > > >> "description=FreeBSD/$(uname -m) on $(kenv smbios.system.maker) >>> $(kenv >>> > > >> smbios.system.product)" -d "do=addd" --data-urlencode 'dmesg@ >>> > > >> /var/run/dmesg.boot' http://dmesgd.nycbug.org/index.cgi >>> > > > >>> > > > Got another system to submit, but continuously getting "500 >>> Internal >>> > > > Server Error" using the curl one-liner. dmesg.boot attached in >>> case >>> > > > it's the source of the problem. >>> > > >>> > > It works now, sorry for the noise. >>> > > >>> > > >>> > ___ >>> > freebsd-sta...@freebsd.org mailing list >>> > https://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> > To unsubscribe, send any mail to " >>> freebsd-stable-unsubscr...@freebsd.org" >>> > >>> ___ >>> freebsd-sta...@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org >>> " >>> >> ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SCSI and dmesg
On Thu, Nov 29, 2018 at 8:09 AM Alan Somers wrote: > On Mon, Nov 26, 2018 at 3:57 PM Warner Losh wrote: > >> On Mon, Nov 26, 2018 at 3:32 PM Maxim Sobolev >> wrote: >> >> > Somebody needs to make collection/submission automatic and make a port >> out >> > of it, so that it's as easy as pkg install dmesg_survey && >> > dmesg_survey_enabled="YES" in the /etc/rc.conf. JIMHO. I'd gladly make >> it a >> > default on all dev boxes within our organization. Might also make a nice >> > SoC project idea. >> > >> >> It's barely a weekend hack, since with the curl 1 liner 95% of what you >> want is there. >> >> This service isn't suitable, though, to have it in rc.conf, I don't think, >> unless it's updated only when there's a material change... >> >> And I'd rather we get more nuanced data than dmesg can provide if we were >> to do the data collection. The admonition to submit to this site was one >> of >> expedience... >> >> Warner >> > > Sounds like somebody needs to adopt sysutils/bsdstats. It's a great > start, but it needs some TLC. > Except there's no available data from it. And it's not a great start, but a terrible one. It gathers the wrong things. Warner > >> >> > -Max >> > >> > On Mon, Nov 26, 2018 at 2:08 PM Yuri Pankov wrote: >> > >> > > Yuri Pankov wrote: >> > > > Warner Losh wrote: >> > > >> Greetings >> > > >> >> > > >> a few weeks ago I pointed people to the nycbug dmesg service. I >> said I >> > > was >> > > >> looking at data to drive SCSI retirement. I've gatherd some >> > preliminary >> > > >> data, which I've uploaded to >> > > >> https://github.com/bsdimp/device-data/blob/master/cam.md along >> with >> > > some >> > > >> preliminary notions of disposition for the hardware. I'm still >> working >> > > out >> > > >> the kinks in the dmesg parsing, but this is interesting data. >> > > >> >> > > >> If you've not recently submitted, please consider doing so. We'll >> be >> > > >> finalizing the scsi SIMs that I'm going to propose retiring in 13 >> here >> > > in a >> > > >> few weeks, and I'm going to base much of what list I come up with >> > based >> > > on >> > > >> what is submitted. The glitches with FreeBSD dmesgs have been >> cleared >> > > up as >> > > >> well. >> > > >> >> > > >> http://dmesgd.nycbug.org/index.cgi >> > > >> >> > > >> or >> > > >> >> > > >> curl -v -d "nickname=$USER" -d "email=$USER@$(hostname)" -d >> > > >> "description=FreeBSD/$(uname -m) on $(kenv smbios.system.maker) >> $(kenv >> > > >> smbios.system.product)" -d "do=addd" --data-urlencode 'dmesg@ >> > > >> /var/run/dmesg.boot' http://dmesgd.nycbug.org/index.cgi >> > > > >> > > > Got another system to submit, but continuously getting "500 Internal >> > > > Server Error" using the curl one-liner. dmesg.boot attached in case >> > > > it's the source of the problem. >> > > >> > > It works now, sorry for the noise. >> > > >> > > >> > ___ >> > freebsd-sta...@freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> > To unsubscribe, send any mail to " >> freebsd-stable-unsubscr...@freebsd.org" >> > >> ___ >> freebsd-sta...@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >> > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SCSI and dmesg
On Mon, Nov 26, 2018 at 3:57 PM Warner Losh wrote: > On Mon, Nov 26, 2018 at 3:32 PM Maxim Sobolev > wrote: > > > Somebody needs to make collection/submission automatic and make a port > out > > of it, so that it's as easy as pkg install dmesg_survey && > > dmesg_survey_enabled="YES" in the /etc/rc.conf. JIMHO. I'd gladly make > it a > > default on all dev boxes within our organization. Might also make a nice > > SoC project idea. > > > > It's barely a weekend hack, since with the curl 1 liner 95% of what you > want is there. > > This service isn't suitable, though, to have it in rc.conf, I don't think, > unless it's updated only when there's a material change... > > And I'd rather we get more nuanced data than dmesg can provide if we were > to do the data collection. The admonition to submit to this site was one of > expedience... > > Warner > Sounds like somebody needs to adopt sysutils/bsdstats. It's a great start, but it needs some TLC. > > > > -Max > > > > On Mon, Nov 26, 2018 at 2:08 PM Yuri Pankov wrote: > > > > > Yuri Pankov wrote: > > > > Warner Losh wrote: > > > >> Greetings > > > >> > > > >> a few weeks ago I pointed people to the nycbug dmesg service. I > said I > > > was > > > >> looking at data to drive SCSI retirement. I've gatherd some > > preliminary > > > >> data, which I've uploaded to > > > >> https://github.com/bsdimp/device-data/blob/master/cam.md along with > > > some > > > >> preliminary notions of disposition for the hardware. I'm still > working > > > out > > > >> the kinks in the dmesg parsing, but this is interesting data. > > > >> > > > >> If you've not recently submitted, please consider doing so. We'll be > > > >> finalizing the scsi SIMs that I'm going to propose retiring in 13 > here > > > in a > > > >> few weeks, and I'm going to base much of what list I come up with > > based > > > on > > > >> what is submitted. The glitches with FreeBSD dmesgs have been > cleared > > > up as > > > >> well. > > > >> > > > >> http://dmesgd.nycbug.org/index.cgi > > > >> > > > >> or > > > >> > > > >> curl -v -d "nickname=$USER" -d "email=$USER@$(hostname)" -d > > > >> "description=FreeBSD/$(uname -m) on $(kenv smbios.system.maker) > $(kenv > > > >> smbios.system.product)" -d "do=addd" --data-urlencode 'dmesg@ > > > >> /var/run/dmesg.boot' http://dmesgd.nycbug.org/index.cgi > > > > > > > > Got another system to submit, but continuously getting "500 Internal > > > > Server Error" using the curl one-liner. dmesg.boot attached in case > > > > it's the source of the problem. > > > > > > It works now, sorry for the noise. > > > > > > > > ___ > > freebsd-sta...@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org > " > > > ___ > freebsd-sta...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SCSI and dmesg
On Mon, Nov 26, 2018 at 3:32 PM Maxim Sobolev wrote: > Somebody needs to make collection/submission automatic and make a port out > of it, so that it's as easy as pkg install dmesg_survey && > dmesg_survey_enabled="YES" in the /etc/rc.conf. JIMHO. I'd gladly make it a > default on all dev boxes within our organization. Might also make a nice > SoC project idea. > It's barely a weekend hack, since with the curl 1 liner 95% of what you want is there. This service isn't suitable, though, to have it in rc.conf, I don't think, unless it's updated only when there's a material change... And I'd rather we get more nuanced data than dmesg can provide if we were to do the data collection. The admonition to submit to this site was one of expedience... Warner > -Max > > On Mon, Nov 26, 2018 at 2:08 PM Yuri Pankov wrote: > > > Yuri Pankov wrote: > > > Warner Losh wrote: > > >> Greetings > > >> > > >> a few weeks ago I pointed people to the nycbug dmesg service. I said I > > was > > >> looking at data to drive SCSI retirement. I've gatherd some > preliminary > > >> data, which I've uploaded to > > >> https://github.com/bsdimp/device-data/blob/master/cam.md along with > > some > > >> preliminary notions of disposition for the hardware. I'm still working > > out > > >> the kinks in the dmesg parsing, but this is interesting data. > > >> > > >> If you've not recently submitted, please consider doing so. We'll be > > >> finalizing the scsi SIMs that I'm going to propose retiring in 13 here > > in a > > >> few weeks, and I'm going to base much of what list I come up with > based > > on > > >> what is submitted. The glitches with FreeBSD dmesgs have been cleared > > up as > > >> well. > > >> > > >> http://dmesgd.nycbug.org/index.cgi > > >> > > >> or > > >> > > >> curl -v -d "nickname=$USER" -d "email=$USER@$(hostname)" -d > > >> "description=FreeBSD/$(uname -m) on $(kenv smbios.system.maker) $(kenv > > >> smbios.system.product)" -d "do=addd" --data-urlencode 'dmesg@ > > >> /var/run/dmesg.boot' http://dmesgd.nycbug.org/index.cgi > > > > > > Got another system to submit, but continuously getting "500 Internal > > > Server Error" using the curl one-liner. dmesg.boot attached in case > > > it's the source of the problem. > > > > It works now, sorry for the noise. > > > > > ___ > freebsd-sta...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SCSI and dmesg
Somebody needs to make collection/submission automatic and make a port out of it, so that it's as easy as pkg install dmesg_survey && dmesg_survey_enabled="YES" in the /etc/rc.conf. JIMHO. I'd gladly make it a default on all dev boxes within our organization. Might also make a nice SoC project idea. -Max On Mon, Nov 26, 2018 at 2:08 PM Yuri Pankov wrote: > Yuri Pankov wrote: > > Warner Losh wrote: > >> Greetings > >> > >> a few weeks ago I pointed people to the nycbug dmesg service. I said I > was > >> looking at data to drive SCSI retirement. I've gatherd some preliminary > >> data, which I've uploaded to > >> https://github.com/bsdimp/device-data/blob/master/cam.md along with > some > >> preliminary notions of disposition for the hardware. I'm still working > out > >> the kinks in the dmesg parsing, but this is interesting data. > >> > >> If you've not recently submitted, please consider doing so. We'll be > >> finalizing the scsi SIMs that I'm going to propose retiring in 13 here > in a > >> few weeks, and I'm going to base much of what list I come up with based > on > >> what is submitted. The glitches with FreeBSD dmesgs have been cleared > up as > >> well. > >> > >> http://dmesgd.nycbug.org/index.cgi > >> > >> or > >> > >> curl -v -d "nickname=$USER" -d "email=$USER@$(hostname)" -d > >> "description=FreeBSD/$(uname -m) on $(kenv smbios.system.maker) $(kenv > >> smbios.system.product)" -d "do=addd" --data-urlencode 'dmesg@ > >> /var/run/dmesg.boot' http://dmesgd.nycbug.org/index.cgi > > > > Got another system to submit, but continuously getting "500 Internal > > Server Error" using the curl one-liner. dmesg.boot attached in case > > it's the source of the problem. > > It works now, sorry for the noise. > > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SCSI and dmesg
Yuri Pankov wrote: > Warner Losh wrote: >> Greetings >> >> a few weeks ago I pointed people to the nycbug dmesg service. I said I was >> looking at data to drive SCSI retirement. I've gatherd some preliminary >> data, which I've uploaded to >> https://github.com/bsdimp/device-data/blob/master/cam.md along with some >> preliminary notions of disposition for the hardware. I'm still working out >> the kinks in the dmesg parsing, but this is interesting data. >> >> If you've not recently submitted, please consider doing so. We'll be >> finalizing the scsi SIMs that I'm going to propose retiring in 13 here in a >> few weeks, and I'm going to base much of what list I come up with based on >> what is submitted. The glitches with FreeBSD dmesgs have been cleared up as >> well. >> >> http://dmesgd.nycbug.org/index.cgi >> >> or >> >> curl -v -d "nickname=$USER" -d "email=$USER@$(hostname)" -d >> "description=FreeBSD/$(uname -m) on $(kenv smbios.system.maker) $(kenv >> smbios.system.product)" -d "do=addd" --data-urlencode 'dmesg@ >> /var/run/dmesg.boot' http://dmesgd.nycbug.org/index.cgi > > Got another system to submit, but continuously getting "500 Internal > Server Error" using the curl one-liner. dmesg.boot attached in case > it's the source of the problem. It works now, sorry for the noise. signature.asc Description: OpenPGP digital signature
Re: SCSI and dmesg
Warner Losh wrote: > Greetings > > a few weeks ago I pointed people to the nycbug dmesg service. I said I was > looking at data to drive SCSI retirement. I've gatherd some preliminary > data, which I've uploaded to > https://github.com/bsdimp/device-data/blob/master/cam.md along with some > preliminary notions of disposition for the hardware. I'm still working out > the kinks in the dmesg parsing, but this is interesting data. > > If you've not recently submitted, please consider doing so. We'll be > finalizing the scsi SIMs that I'm going to propose retiring in 13 here in a > few weeks, and I'm going to base much of what list I come up with based on > what is submitted. The glitches with FreeBSD dmesgs have been cleared up as > well. > > http://dmesgd.nycbug.org/index.cgi > > or > > curl -v -d "nickname=$USER" -d "email=$USER@$(hostname)" -d > "description=FreeBSD/$(uname -m) on $(kenv smbios.system.maker) $(kenv > smbios.system.product)" -d "do=addd" --data-urlencode 'dmesg@ > /var/run/dmesg.boot' http://dmesgd.nycbug.org/index.cgi Got another system to submit, but continuously getting "500 Internal Server Error" using the curl one-liner. dmesg.boot attached in case it's the source of the problem. ---<>--- Copyright (c) 1992-2018 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.0-CURRENT r340744 GENERIC-NODEBUG amd64 FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) VT(efifb): resolution 3440x1440 CPU: Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz (3504.14-MHz K8-class CPU) Origin="GenuineIntel" Id=0x806e9 Family=0x6 Model=0x8e Stepping=9 Features=0xbfebfbff Features2=0x7ffafbbf AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0x29c67af Structured Extended Features3=0x9c00 XSAVE Features=0xf VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16472522752 (15709 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads random: unblocking device. ioapic0 irqs 0-119 on motherboard Launching APs: 1 3 2 Timecounter "TSC-low" frequency 1752072050 Hz quality 1000 random: entropy device external interface [ath_hal] loaded module_register_init: MOD_LOAD (vesa, 0x8113f150, 0) error 19 kbd0 at kbdmux0 random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" netmap: loaded module nexus0 efirtc0: on motherboard efirtc0: registered as a time-of-day clock, resolution 1.00s cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 2400 Hz quality 950 Event timer "HPET" frequency 2400 Hz quality 550 Event timer "HPET1" frequency 2400 Hz quality 440 Event timer "HPET2" frequency 2400 Hz quality 440 Event timer "HPET3" frequency 2400 Hz quality 440 Event timer "HPET4" frequency 2400 Hz quality 440 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. atrtc0: registered as a time-of-day clock, resolution 1.00s Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xf000-0xf03f mem 0x2ffe00-0x2ffeff,0x2f-0x2f7fff at device 2.0 on pci0 vgapci0: Boot video device xhci0: mem 0x2fff01-0x2fff01 at device 20.0 on pci0 xhci0: 32 bytes context size, 64-bit DMA usbus0 on xhci0 usbus0: 5.0Gbps Super Speed USB v3.0 pci0: at device 22.0 (no driver attached) ahci0: port 0xf090-0xf097,0xf080-0xf083,0xf060-0xf07f mem 0xde424000-0xde425fff,0xde427000-0xde4270ff,0xde426000-0xde4267ff at device 23.0 on pci0 ahci0: AHCI v1.31 with 1 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 pcib1: at device 28.0 on pci0 pcib1: [GIANT-LOCKED] pcib2: at device 28.5 on pci0 pci1: on pcib2 pci1: at device 0.0 (no driver attached) pcib3: at device 28.7 on pci0 pci2: on pcib3 pci2: at device 0.0 (no driver attached) pcib4: at device 29.0 on pci0 pci3: on pcib4 nvme0: mem 0xde10-0xde103fff at device 0.0 on pci3 isab0: at device 31.0 on pci0 isa0: on isab0 pci0: at device 31.2 (no driver attached) hdac0: mem 0x2fff02-0x2fff023fff,0x2fff00-0x2fff00 at device 31.3 on pci0 em0: mem 0xde40-0xde41 at device 31.6 on pci0
