Is anyone actively working on making CUDA support possible in FreeBSD?
Hi all. I'm aware that currently there is no way to make CUDA work on FreeBSD. I am wondering whether there are any plans in the work to support it, and if there are any mailing lists or pages that I could follow along with to see the progress. Thanks, btv ___ 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: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: Boot loader stuck after first stage upgrading 11.2 to 12.0-RC2
I just did push biosdisk updates to stable/12, I wonder if you could test those bits… rgds, toomas > On 29 Nov 2018, at 17:01, Mark Martinec wrote: > > After successfully upgraded three hosts from 11.2-p4 to 12.0-RC2 (amd64, > zfs, bios), I tried my luck with one of our production hosts, and ended up > with a stuck loader after rebooting with a new kernel (after the first > stage of upgrade). > > These were the steps, and all went smoothly and normally until a reboot: > > freebsd-update upgrade -r 12.0-RC2 > freebsd-update install > shutdown -r now > > While booting, the 'BTX loader' comes up, lists the BIOS drives, > then the spinner below the list comes up and begins turning, > stuttering, and after a couple of seconds it grinds to a standstill > and nothing happens afterwards. > > At this point the ZFS and the bootstrap loader is supposed to > come up, but it doesn't. > > This host has too zfs pools, the system pool consists of two SSDs > in a zfs mirror (also holding a freebsd-boot partition each), the > other pool is a raidz2 with six JBOD disks on an LSI controller. > The gptzfsboot in both freebsd-boot partitions is fresh from 11.2, > both zpool versions are up-to-date with 11.2. The 'zpool status -v' > is happy with both pools. > > After rebooting from an USB drive and reverting the /boot directory > to a previous version, the machine comes up normally again > with the 11.2-RELEASE-p4. > > I found a file init.core in the / directory, slightly predating the > last reboot with a salvaged system - although it was probably not > a cause of the problem, but a consequence of the rescue operation. > > It is unfortunate that this is a production host, so I can't play > much with it. One or two more quick experiments I can probably > afford, but not much more. Should I just first wait for the > official 12.0 release? Should I try booting with a 12.0 on USB > and try to import pools? Suggestions welcome. > > > > Now that the /boot has been manually restored to the 11.2 state, > A SECOND QUESTION is about freebsd-update, which still thinks we are > in the middle of an upgrade procedure. Trying now to just update > the 11.2-RELEASE-p4 to 11.2-RELEASE-p5, the fetch complains: > > # uname -a > FreeBSD xxx 11.2-RELEASE-p4 FreeBSD 11.2-RELEASE-p4 > # > # freebsd-version > 11.2-RELEASE-p4 > # > # freebsd-update fetch > src component not installed, skipped > You have a partially completed upgrade pending > Run '/usr/sbin/freebsd-update install' first. > Run '/usr/sbin/freebsd-update fetch -F' to proceed anyway. > > So what is the right way to get rid of all traces of the > unsuccessful upgrade, and let freebsd-update believe we are cleanly > at 11.2-p4 ? Removing /var/db/freebsd-update did not help. > > Mark > ___ > 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" ___ 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"
Boot loader stuck after first stage upgrading 11.2 to 12.0-RC2
After successfully upgraded three hosts from 11.2-p4 to 12.0-RC2 (amd64, zfs, bios), I tried my luck with one of our production hosts, and ended up with a stuck loader after rebooting with a new kernel (after the first stage of upgrade). These were the steps, and all went smoothly and normally until a reboot: freebsd-update upgrade -r 12.0-RC2 freebsd-update install shutdown -r now While booting, the 'BTX loader' comes up, lists the BIOS drives, then the spinner below the list comes up and begins turning, stuttering, and after a couple of seconds it grinds to a standstill and nothing happens afterwards. At this point the ZFS and the bootstrap loader is supposed to come up, but it doesn't. This host has too zfs pools, the system pool consists of two SSDs in a zfs mirror (also holding a freebsd-boot partition each), the other pool is a raidz2 with six JBOD disks on an LSI controller. The gptzfsboot in both freebsd-boot partitions is fresh from 11.2, both zpool versions are up-to-date with 11.2. The 'zpool status -v' is happy with both pools. After rebooting from an USB drive and reverting the /boot directory to a previous version, the machine comes up normally again with the 11.2-RELEASE-p4. I found a file init.core in the / directory, slightly predating the last reboot with a salvaged system - although it was probably not a cause of the problem, but a consequence of the rescue operation. It is unfortunate that this is a production host, so I can't play much with it. One or two more quick experiments I can probably afford, but not much more. Should I just first wait for the official 12.0 release? Should I try booting with a 12.0 on USB and try to import pools? Suggestions welcome. Now that the /boot has been manually restored to the 11.2 state, A SECOND QUESTION is about freebsd-update, which still thinks we are in the middle of an upgrade procedure. Trying now to just update the 11.2-RELEASE-p4 to 11.2-RELEASE-p5, the fetch complains: # uname -a FreeBSD xxx 11.2-RELEASE-p4 FreeBSD 11.2-RELEASE-p4 # # freebsd-version 11.2-RELEASE-p4 # # freebsd-update fetch src component not installed, skipped You have a partially completed upgrade pending Run '/usr/sbin/freebsd-update install' first. Run '/usr/sbin/freebsd-update fetch -F' to proceed anyway. So what is the right way to get rid of all traces of the unsuccessful upgrade, and let freebsd-update believe we are cleanly at 11.2-p4 ? Removing /var/db/freebsd-update did not help. Mark ___ 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: Fujitsu Lifebook E751 (iGPU: HM65): distorted console with UEFI boot
O. Hartmann wrote: > The notebook seems UEFI only and doesn't boot off from MBR partioned > devices (i.e. NanoBSD I used to use). AFAICT, BIOS style boot should be possible with the named laptop. Is CSM enabled within the Firmware? Regards, ___ 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"
