Re: Future of ident(1)
On Mon, Oct 25, 2021 at 09:47:18AM -0700, Maxim Sobolev wrote: > Just in case someone thinks this is something useful, I've got a PR filed > against git to implement custom $Id$. There are no technical issues with > the change but Git developers are not very keen on merging it in, since > they see this as an obscure feature, no one needs. :-/ So if anyone wants > to chime in on GitHub or git mailing list please do so. > > https://github.com/git/git/pull/1074 Or temporary put one file into devel/git/files? > Thanks! > > -Max > > On Fri, Oct 22, 2021 at 2:30 PM Steve Kargl < > s...@troutmask.apl.washington.edu> wrote: > > > All, > > > > With the new world order, what is the future of ident(1)? > > Should it be removed from base? Given a compiled binary > > in base, how does one find the equivalent git info that > > ident(1) used to perform? > > > > Having a few minutes to dust off old patchs for libm, should > > I remove $FreeBSD$ tags in files I touch? For new files, is > > it expected that useless $FreeBSD$ tags should be added? > > > > -- > > Steve > > > >
Re: console getty uses 1.5% of CPU
On Wed, Apr 07, 2021 at 02:33:57PM +, Poul-Henning Kamp wrote: > > T.e. if all system eat 985 ticks of CPU each second and getty eat 15 > > ticks of CPU each second -- top show 1.5% for getty. > > That may be, but getty should not wake up at all in this situation, > it should be sleeping, waiting for modem-control signals. May be some kernel-side ticks counted for getty. You can try check this by dtrace, I mean. Snoop scheduler activation and check process accounting. ___ 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: console getty uses 1.5% of CPU
On Wed, Apr 07, 2021 at 05:22:40AM +, Poul-Henning Kamp wrote: > I have two 12.2-R systems where the serial console is attached to a terminal > server. > > When there are no TCP connections to the terminal server, getty soaks up 1.5% > of the > CPU in the kernel (sleeping in "ttyin"), ktrace shows no system calls. > > When a TCP connection is made to the terminal server, which raises the > modem-handshake > on the DE-9 connector, the CPU usage stops. > > Anybody else seeing something like this ? Problem of comparing low number? Top's "getty 1.5% of the CPU" is not "getty eat 1.5% of the ALL CPU power", this is "getty 1.5% of off all other curerent eats of CPU power". T.e. if all system eat 985 ticks of CPU each second and getty eat 15 ticks of CPU each second -- top show 1.5% for getty. Load is raised to 99_985 ticks for system, getty eat 15 ticks -- top show 0% ( 15/(99985+15) = .015% ). ___ 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: OpenZFS: kldload zfs.ko freezes on i386 4GB memory
On Fri, Oct 30, 2020 at 04:00:55PM -0700, Cy Schubert wrote: > > > > More stresses memory usually refers to performance penalty. > > > > Usually way for better performance is reduce memory access. > > > > > > The reason filesystems (UFS, ZFS, EXT4, etc.) cache is to avoid disk > > > accesses. Nanoseconds vs milliseconds. > > > > I mean compared ZoL ZFS ARC vs old (BSD/Opensolaris/Illumos) ZFS ARC. > > Any reaason to rise ARC hit rate in ZoL case? > > That's what hit rate is. It's a memory access instead of a disk access. > That's what you want. Is ZoL ARC hit rate rise from FreeBSD ARC hit rate? ___ 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: OpenZFS: kldload zfs.ko freezes on i386 4GB memory
On Fri, Oct 30, 2020 at 03:34:10PM -0700, Cy Schubert wrote: > In message <20201030220809.gg2...@zxy.spb.ru>, Slawa Olhovchenkov writes: > > On Fri, Oct 30, 2020 at 01:53:10PM -0700, Cy Schubert wrote: > > > > > In message <20201030204622.gf2...@zxy.spb.ru>, Slawa Olhovchenkov writes: > > > > On Thu, Oct 29, 2020 at 08:13:00PM -0700, Cy Schubert wrote: > > > > > > > > > In message , > > > > > qroxan > > a > > > > > writes > > > > > : > > > > > > > > > > > > Hi, > > > > > > > > > > > > I have an old i386 machine running r364479. After upgrading to > > > > > > r367045, running kldload zfs.ko freezes the whole system. > > > > > > > > > > > > I also tried to replace the 4GB memory with another 2GB one > > > > > > and kldload zfs.ko works without freezing the machine. > > > > > > > > > > ZFS ARC stresses memory. I've found a number of bad RAM chips over > > > > > the > > > > > years using ZFS. > > > > > > > > > > The OpenZFS upgrade significantly changed how it manages ARC. It's > > > > > like > > ly > > > > > that prior to the OpenZFS upgrade your memory wasn't stressed to the > > > > > po > > int > > > > > of failure. You can try to mask the problem by reducing your RAM > > > > > clock > > rate > > > > > > > > > or or increase one of the other latency settings in your BIOS. > > > > > However, > > > > > > > again, this only masks an already weak RAM chip. > > > > > > > > Sounds like performance drop and regression > > > > > > How so. Please explain. > > > > More stresses memory usually refers to performance penalty. > > Usually way for better performance is reduce memory access. > > The reason filesystems (UFS, ZFS, EXT4, etc.) cache is to avoid disk > accesses. Nanoseconds vs milliseconds. I mean compared ZoL ZFS ARC vs old (BSD/Opensolaris/Illumos) ZFS ARC. Any reaason to rise ARC hit rate in ZoL case? ___ 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: OpenZFS: kldload zfs.ko freezes on i386 4GB memory
On Fri, Oct 30, 2020 at 01:53:10PM -0700, Cy Schubert wrote: > In message <20201030204622.gf2...@zxy.spb.ru>, Slawa Olhovchenkov writes: > > On Thu, Oct 29, 2020 at 08:13:00PM -0700, Cy Schubert wrote: > > > > > In message , qroxana > > > writes > > > : > > > > > > > > Hi, > > > > > > > > I have an old i386 machine running r364479. After upgrading to > > > > r367045, running kldload zfs.ko freezes the whole system. > > > > > > > > I also tried to replace the 4GB memory with another 2GB one > > > > and kldload zfs.ko works without freezing the machine. > > > > > > ZFS ARC stresses memory. I've found a number of bad RAM chips over the > > > years using ZFS. > > > > > > The OpenZFS upgrade significantly changed how it manages ARC. It's likely > > > that prior to the OpenZFS upgrade your memory wasn't stressed to the > > > point > > > of failure. You can try to mask the problem by reducing your RAM clock > > > rate > > > > > or or increase one of the other latency settings in your BIOS. However, > > > again, this only masks an already weak RAM chip. > > > > Sounds like performance drop and regression > > How so. Please explain. More stresses memory usually refers to performance penalty. Usually way for better performance is reduce memory access. ___ 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: OpenZFS: kldload zfs.ko freezes on i386 4GB memory
On Thu, Oct 29, 2020 at 08:13:00PM -0700, Cy Schubert wrote: > In message , qroxana > writes > : > > > > Hi, > > > > I have an old i386 machine running r364479. After upgrading to > > r367045, running kldload zfs.ko freezes the whole system. > > > > I also tried to replace the 4GB memory with another 2GB one > > and kldload zfs.ko works without freezing the machine. > > ZFS ARC stresses memory. I've found a number of bad RAM chips over the > years using ZFS. > > The OpenZFS upgrade significantly changed how it manages ARC. It's likely > that prior to the OpenZFS upgrade your memory wasn't stressed to the point > of failure. You can try to mask the problem by reducing your RAM clock rate > or or increase one of the other latency settings in your BIOS. However, > again, this only masks an already weak RAM chip. Sounds like performance drop and regression ___ 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: Deprecating ftpd in the FreeBSD base system?
On Thu, Sep 17, 2020 at 08:55:26AM -0700, Cy Schubert wrote: > In message <451538de-9427-4584-987b-8e4aa26c2...@freebsd.org>, Daniel > Eischen w > rites: > > > > > > > On Sep 17, 2020, at 11:20 AM, Maxim Sobolev wrote: > > > > > > Re: removing HTTP client please no!!! The current drive to "outlaw" > > > HTTP > > > coming from companies who see all world via web browser. Totally ignoring > > > the fact that HTTP != HTTPS in particular in cases where reliability and > > > lower complexity of the system takes precedence over on-the-wire protocol > > > security. For example, many internal APIs of AWS EC2 are HTTP. > > > > Agree. And remember the mantra: tools, not policy. > > Since there are so many I'll pick this email to reply to. > > libfetch should be designed to call plugins. An https plugin, http plugin, > ftp plugin, sftp plugin, and so on. New protocols are added as needed, > preferably to ports before they are mainstream. Old protocols are removed > and moved to ports. People who still need to use old protocols can install > the port which plugs into libfetch. When a protocol becomes stale it's > forgotten, no longer maintained and simply disappears into the ether. > > Given that pkgbase will become a reality at some point the line between > base and ports will blur. I expect at some point some of what we see in > base to simply become ports. As a developer of both base and ports, ports > are much easier to maintain than importing into base. And for install plugin from ports use HTTP AWS API installed from ports? ___ 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: vfs.zfs.min_auto_ashift and OpenZFS
On Wed, Sep 09, 2020 at 11:55:14AM -0400, Ryan Moeller wrote: > > On 9/8/20 4:31 PM, Niclas Zeising wrote: > > On 2020-05-02 02:20, Matthew Macy wrote: > >> OpenZFS doesn't have the same ashift optimization logic that FreeBSD > >> has. It's something that needs to be resolved before the code can be > >> integrated downstream. > > > > So currently all pools created with OpenZFS will use 512 bit > > alignment, at least if the underlying storage device uses 512bit > > sectors (which most drives tend to do)? > > > > If this is the case, it feels like a pessimisation. > > > > Regards > > > The vdev ashift optimizations from FreeBSD were put in OpenZFS before > the import into base. That sysctl does work now. Ugly hack w/ geom_noop required again? ___ 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: sysutils/screen-ncurses port
On Tue, May 05, 2020 at 02:29:00PM +0200, Baptiste Daroussin wrote: > On Tue, May 05, 2020 at 03:24:15PM +0300, Slawa Olhovchenkov wrote: > > On Thu, Apr 30, 2020 at 03:04:49PM +0200, Baptiste Daroussin wrote: > > > > > > > This way ports with random termcap info to add would be able to do it > > > > > witho= > > > > > ut > > > > > the requirement to wait for a commit in base and a MFC. > > > > > > > > This is probably outside of my scope at the moment but, yes, agreed. > > > > > > > I will then. > > > I added that to my TODO > > > > Can you also see at termcap/ncurses related code? > > Latest commit in base do unusable sh/tcsh w/ emacs > > tramp mode and inside screen. > > I am not aware of sh/tcsh being unsable at all. I heard about an emacs thingy > but not being an emacs guy myself I haven't reproduced. > > I can have a look but I would need a more specific feedback with examples of > failures. Do you see this my mail https://lists.freebsd.org/pipermail/freebsd-stable/2020-April/092251.html ? This is reproduce by different gay too. tcsh inside screen at editing near to end of screen produce grabadge at multiple lines. Not sure about 100% reproduce this. ___ 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: sysutils/screen-ncurses port
On Thu, Apr 30, 2020 at 03:04:49PM +0200, Baptiste Daroussin wrote: > > > This way ports with random termcap info to add would be able to do it > > > witho= > > > ut > > > the requirement to wait for a commit in base and a MFC. > > > > This is probably outside of my scope at the moment but, yes, agreed. > > > I will then. > I added that to my TODO Can you also see at termcap/ncurses related code? Latest commit in base do unusable sh/tcsh w/ emacs tramp mode and inside screen. And paste from screen too (many unneed trailing space from lines). ___ 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"
Kernel free memory control / pressure
I am looked to code control kernel free memory /p ressure and see some strange points: - vm.v_free_target is RW but do nothing. You can set it to any value and this is don't have any effect. - vmd_free_target (as vm.domain.N.stats.free_target) is RD and don't have any sysctl to tune Same for v_free_min, v_free_reserved, v_pageout_free_min. As I see this behavior for 12 and current branches, after-NUMA kernels. Is this expected behavior? PS: (kgdb) p vm_dom[0].vmd_page_count $2 = 33454844 (kgdb) p vm_dom[1].vmd_page_count $3 = 31872620 What source of vm_dom[0].vmd_page_count > vm_dom[1].vmd_page_count? ___ 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: Lockdown adaX numbers to allow booting ?
On Fri, Sep 20, 2019 at 01:06:29PM -0400, Garrett Wollman wrote: > In article <20190920155304.gn3...@zxy.spb.ru>, s...@zxy.spb.ru writes: > > >Location of device in multi-chassis storage system is different story. > >I am don't know how to field engineer insert disks in chassis. > >For me simple is find in /var/run/dmesg.boot S/N <=> daXY mapping and > >turn ON led by sas2ircu. > > sesutil does this for you! > > # sesutil locate daXY on > # sesutil locate daXY off > > So long as your enclosure supports SES (all the modern ones I've seen > do) and is enumerable by ses(4). In theory there is no difference between theory and practice. But, in practice, there is. # sesutil map ses0: Enclosure Name: AHCI SGPIO Enclosure Enclosure ID:0 Element 0, Type: Array Device Slot Status: Unsupported (0x00 0x00 0x00 0x00) Element 1, Type: Array Device Slot Status: Unknown (0x06 0x00 0x00 0x00) Description: SLOT 000 Element 2, Type: Array Device Slot Status: Unknown (0x06 0x00 0x00 0x00) Description: SLOT 001 Element 3, Type: Array Device Slot Status: Unknown (0x06 0x00 0x00 0x00) Description: SLOT 002 Element 4, Type: Array Device Slot Status: Unknown (0x06 0x00 0x00 0x00) Description: SLOT 003 ses1: Enclosure Name: AHCI SGPIO Enclosure Enclosure ID:0 Element 0, Type: Array Device Slot Status: Unsupported (0x00 0x00 0x00 0x00) Element 1, Type: Array Device Slot Status: Unknown (0x06 0x00 0x00 0x00) Description: SLOT 000 Element 2, Type: Array Device Slot Status: Unknown (0x06 0x00 0x00 0x00) Description: SLOT 001 Element 3, Type: Array Device Slot Status: Unknown (0x06 0x00 0x00 0x00) Description: SLOT 002 Element 4, Type: Array Device Slot Status: Unknown (0x06 0x00 0x00 0x00) Description: SLOT 003 Element 5, Type: Array Device Slot Status: Unknown (0x06 0x00 0x00 0x00) Description: SLOT 004 Element 6, Type: Array Device Slot Status: Unknown (0x06 0x00 0x00 0x00) Description: SLOT 005 # sesutil locate ada0 on sesutil: Count not find the SES id of device 'ada0' # sesutil locate da0 on sesutil: Count not find the SES id of device 'da0' # sas2ircu 0 DISPLAY LSI Corporation SAS2 IR Configuration Utility. Version 20.00.00.00 (2014.09.18) Copyright (c) 2008-2014 LSI Corporation. All rights reserved. Read configuration has been initiated for controller 0 Controller information Controller type : SAS2308_1 BIOS version: 7.39.02.00 Firmware version: 20.00.07.00 Channel description : 1 Serial Attached SCSI Initiator ID: 0 Maximum physical devices: 255 Concurrent commands supported : 8192 Slot: 1 Segment : 0 Bus : 1 Device : 0 Function: 0 RAID Support: No IR Volume information Physical device information Initiator at ID #0 Device is a Hard disk Enclosure # : 1 Slot # : 0 SAS Address : 4433221-1-0300- State : Ready (RDY) Size (in MB)/(in sectors) : 7630885/15628053167 Manufacturer: ATA Model Number: TOSHIBA HDWN180 Firmware Revision : GX2M Serial No : 79HSK0PHFAVG GUID: N/A Protocol: SATA Drive Type : SATA_HDD Device is a Hard disk Enclosure # : 1 Slot # : 1 SAS Address : 4433221-1-0200- State : Ready (RDY) Size (in MB)/(in sectors) : 7630885/15628053167 Manufacturer: ATA
Re: Lockdown adaX numbers to allow booting ?
On Fri, Sep 20, 2019 at 08:29:08AM -0700, Freddie Cash wrote: > On Fri, Sep 20, 2019 at 7:35 AM Slawa Olhovchenkov wrote: > > > On Thu, Sep 19, 2019 at 06:04:54PM +0200, Michael Gmelin wrote: > > > What about gpart output of the pool drives? > > > > > > In general you would create zpools using gptids or gpt labels, not the > > devices, so you’re independent of device numbering. The boot loader should > > only be installed on drives that contain the boot pool (maybe you have old > > boot loaders on data drives?). > > > > ZFS work w/ ZFS labels, not w/ device names/gptids/gpt labels. > > You don't worry about changed device names aroud reboots. > > > > Very true, from ZFS' point of view. It writes a ZFS label to whichever > GEOM provider you hand it (file, iSCSI device, raw device, MBR partition, > GPT partition, etc), and it will find it's pool members based on those > labels. ZFS doesn't care where the device is physically connected in the > system, just that it is connected. > > But the ZFS labels aren't what it will display in "zpool list -v" or "zpool > status" output. That will show the GEOM provider you gave it (and, > depending on the order that GEOM tastes the devices, and what's > enabled/disabled in loader.conf, that output can change). That's where > it's useful to have human-readable, descriptive labels (like GPT partition > labels), and to disable all the GEOM ID systems you won't be using via > loader.conf. So that when things go sideways, and a disk dies, you can > find it quickly and easily. Much easier to replace "gpt/jbod3-a6" in a > multi-chassis storage system with 100+ drives than to figure out which bay > corresponds to "ada73" after a couple of reboots that may or may not have > changed the PCI bus enumeration direction, or after replacing an HBA that Location of device in multi-chassis storage system is different story. I am don't know how to field engineer insert disks in chassis. For me simple is find in /var/run/dmesg.boot S/N <=> daXY mapping and turn ON led by sas2ircu. > enumerates drives a different way (da vs ada), or after a BIOS/EFI upgrade > that renumbers things, or any other number of situations. (We've run into > most of these, and have come to rely on GPT partition labels for just this > reason; and we stick the drive serial number on the outside of the bay, > just in case). > It's not a ZFS requirement. It just makes things easier for the admin down > the road. Especially if the admin team changes or inherits systems. :) This is need many manual work at setup and build time. DC field engineer make servers for me and don't do this work for me. ___ 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: Lockdown adaX numbers to allow booting ?
On Thu, Sep 19, 2019 at 06:04:54PM +0200, Michael Gmelin wrote: > > > > On 19. Sep 2019, at 17:57, Kurt Jaeger wrote: > > > > Hi! > > > >>> We have a system with 10 SATA disks. 2 disks are for the system, > >>> 8 disks drive a data pool 'bck', configured as raidz2, for backup > >>> purposes: > >>> > >>> bck72.8T 38.7T 34.1T- - 1%53% 1.00x > >>> ONLINE - > > > >>> The problem is that if all 10 disks are connected, the system > >>> looses track from where it should boot and fails to boot (serial boot > >>> log): > > > >> Why this order does change? One would expect disks 0 and 1 to be OS disks > >> and the rest for data??? > > > > 0+1 are 2.5", and the initial setup was: > > - we installed system disks as zroot > > - shipped the box to the housing facility > > - booted and added the drives > > > > At that time we did not do additional tests about the disk/boot sequence > > etc. > > > >> Also the question is, what you mean with ???system looses track > > > > I interpret the hang during boot as 'it looses track'. So I guess > > it tries to read the kernel from the wrong drives. > > > >> disk4 becomes adaX? why it matters, are you using ufs on boot disks? > > > > No, zpool only. > > > > I've made a few more details available here: > > > > https://people.freebsd.org/~pi/host/dmesg.txt > > https://people.freebsd.org/~pi/host/devlist.txt > > https://people.freebsd.org/~pi/host/gpart.txt > > https://people.freebsd.org/~pi/host/pciconf.txt > > https://people.freebsd.org/~pi/host/zpool.txt > > What about gpart output of the pool drives? > > In general you would create zpools using gptids or gpt labels, not the > devices, so you’re independent of device numbering. The boot loader should > only be installed on drives that contain the boot pool (maybe you have old > boot loaders on data drives?). ZFS work w/ ZFS labels, not w/ device names/gptids/gpt labels. You don't worry about changed device names aroud reboots. ___ 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: leaked swap?
On Tue, Mar 19, 2019 at 04:07:45PM +0200, Andriy Gapon wrote: > On 19/03/2019 15:02, Slawa Olhovchenkov wrote: > > On Mon, Mar 18, 2019 at 11:00:10PM +0200, Andriy Gapon wrote: > > > >> On 18/03/2019 20:01, Andrey Fesenko wrote: > >>> Not this? ZFS use wired and not clean only reboot? > >>> https://reviews.freebsd.org/D7538?id=25108 > >> > >> Wired memory surely has nothing to do with swap. > > > > Wired memory can pressure to swapable memory > > > > Yes, it can. But I am interested in what is in the swap. Not what caused it > to > go to the swap. procstat -v -a | awk '$10 == "sw"' ? ___ 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: leaked swap?
On Mon, Mar 18, 2019 at 11:00:10PM +0200, Andriy Gapon wrote: > On 18/03/2019 20:01, Andrey Fesenko wrote: > > Not this? ZFS use wired and not clean only reboot? > > https://reviews.freebsd.org/D7538?id=25108 > > Wired memory surely has nothing to do with swap. Wired memory can pressure to swapable memory ___ 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: is 4k desktop possible on freebsd-12?
On Wed, Oct 10, 2018 at 02:57:39PM +0100, tech-lists wrote: > On 10/10/2018 13:45, Slawa Olhovchenkov wrote: > > for 4K@60FPS you need DP connection. > > problem is monitor only has HDMI. I'm not sure it'll 4k@30fps is an > acceptable mode for it; need to check You need check HDMI 2.0 available on video card and monitor. For HDMI 1.4 you need check of support both card and monitor support 4K@24. ___ 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: is 4k desktop possible on freebsd-12?
On Wed, Oct 10, 2018 at 11:17:03AM +0100, tech-lists wrote: > > so would this indicate the card is 4k capable but the HDMI port on the > card is not? Or the port on the monitor? Or something else? for 4K@60FPS you need DP connection. ___ 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: Deadlocks / hangs in ZFS
On Thu, Jul 12, 2018 at 02:42:29PM +0200, Alexander Leidinger wrote:
> __curthread () at ./machine/pcpu.h:230
> 230 __asm("movq %%gs:%1,%0" : "=r" (td)
> (kgdb) bt
> #0 __curthread () at ./machine/pcpu.h:230
> #1 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:366
> #2 0x80485e11 in kern_reboot (howto=260) at
> /usr/src/sys/kern/kern_shutdown.c:446
> #3 0x804863f3 in vpanic (fmt=, ap=0xfe457870)
> at /usr/src/sys/kern/kern_shutdown.c:863
> #4 0x80486443 in panic (fmt=) at
> /usr/src/sys/kern/kern_shutdown.c:790
> #5 0x8075279f in trap_fatal (frame=0xfe457a50,
> eva=32) at /usr/src/sys/amd64/amd64/trap.c:892
> #6 0x80752812 in trap_pfault (frame=0xfe457a50,
> usermode=)
> at /usr/src/sys/amd64/amd64/trap.c:728
> #7 0x80751e1a in trap (frame=0xfe457a50) at
> /usr/src/sys/amd64/amd64/trap.c:427
> #8
> #9 0x81391fbe in arc_check_uma_cache (lowest=-1011712)
> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:4532
> #10 arc_reclaim_thread (unused=)
> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:4657
> #11 0x8044ca74 in fork_exit (callout=0x81391b90
> , arg=0x0,
> frame=0xfe457c00) at /usr/src/sys/kern/kern_fork.c:1057
> #12
> (kgdb) up 9
> #9 0x81391fbe in arc_check_uma_cache (lowest=-1011712)
> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:4532
> 4532lowest +=
> uma_zone_get_free_size(zio_data_buf_cache[n]->kc_zone);
> (kgdb) list
> 4527int iter = 4;
> 4528int step = 1 << (SPA_MAXBLOCKSHIFT
> - SPA_MINBLOCKSHIFT - 3);
> 4529int n = (SPA_MAXBLOCKSIZE >>
> SPA_MINBLOCKSHIFT) - 1;
> 4530
> 4531while (n >= 0) {
> 4532lowest +=
> uma_zone_get_free_size(zio_data_buf_cache[n]->kc_zone);
> 4533if (lowest >= 0)
> 4534return lowest;
> 4535n -= step;
> 4536if(--iter == 0) {
> (kgdb) print n
> $1 = 32767
> (kgdb) print zio_data_buf_cache[n]
> $2 = (kmem_cache_t *) 0x0
> (kgdb)
Very strange, zio_data_buf_cache[] can't be NULL, as asserted in
zio_init.
___
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: Deadlocks / hangs in ZFS
On Sun, Jun 03, 2018 at 09:14:50PM +0200, Alexander Leidinger wrote: > Quoting Alexander Leidinger (from Mon, 28 > May 2018 09:02:01 +0200): > > > Quoting Slawa Olhovchenkov (from Mon, 28 May 2018 > > 01:06:12 +0300): > > > >> On Sun, May 27, 2018 at 09:41:59PM +0200, Kirill Ponomarev wrote: > >> > >>> On 05/22, Slawa Olhovchenkov wrote: > >>>> > It has been a while since I tried Karl's patch the last time, and I > >>>> > stopped because it didn't apply to -current anymore at some point. > >>>> > Will what is provided right now in the patch work on -current? > >>>> > >>>> I am mean yes, after s/vm_cnt.v_free_count/vm_free_count()/g > >>>> I am don't know how to have two distinct patch (for stable and > >>>> current) in one review. > >>> > >>> I'm experiencing these issues sporadically as well, would you mind > >>> to publish this patch for fresh current? > >> > >> Week ago I am adopt and publish patch to fresh current and stable, is > >> adopt need again? > > > > I applied the patch in the review yesterday to rev 333966, it > > applied OK (with some fuzz). I will try to reproduce my issue with > > the patch. > > The behavior changed (or the system was long enough in this state > without me noticing it). I have a panic now: > panic: deadlkres: possible deadlock detected for 0xf803766db580, > blocked for 1803003 ticks Hmm, may be first determinate locked function addr2line -ie /boot/kernel/kernel 0xf803766db580 or kgdb x/10i 0xf803766db580 > I only have the textdump. Is nayone up to debug this? If yes, I switch > to normal dumps, just tell me what I shall check for. > > db:0:kdb.enter.panic> run lockinfo > db:1:lockinfo> show locks > No such command; use "help" to list available commands > db:1:lockinfo> show alllocks > No such command; use "help" to list available commands > db:1:lockinfo> show lockedvnods > Locked vnodes > db:0:kdb.enter.panic> show pcpu > cpuid= 6 > dynamic pcpu = 0xfe008f03e840 > curthread= 0xf80370c82000: pid 0 tid 100218 "deadlkres" > curpcb = 0xfe0116472cc0 > fpcurthread = none > idlethread = 0xf803700b9580: tid 18 "idle: cpu6" > curpmap = 0x80d28448 > tssp = 0x80d96d90 > commontssp = 0x80d96d90 > rsp0 = 0xfe0116472cc0 > gs32p= 0x80d9d9c8 > ldt = 0x80d9da08 > tss = 0x80d9d9f8 > db:0:kdb.enter.panic> bt > Tracing pid 0 tid 100218 td 0xf80370c82000 > kdb_enter() at kdb_enter+0x3b/frame 0xfe0116472aa0 > vpanic() at vpanic+0x1c0/frame 0xfe0116472b00 > panic() at panic+0x43/frame 0xfe0116472b60 > deadlkres() at deadlkres+0x3a6/frame 0xfe0116472bb0 > fork_exit() at fork_exit+0x84/frame 0xfe0116472bf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfe0116472bf0 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > > > Bye, > Alexander. > > -- > http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF ___ 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: Deadlocks / hangs in ZFS
On Mon, May 28, 2018 at 09:02:01AM +0200, Alexander Leidinger wrote: > Quoting Slawa Olhovchenkov (from Mon, 28 May 2018 > 01:06:12 +0300): > > > On Sun, May 27, 2018 at 09:41:59PM +0200, Kirill Ponomarev wrote: > > > >> On 05/22, Slawa Olhovchenkov wrote: > >> > > It has been a while since I tried Karl's patch the last time, and I > >> > > stopped because it didn't apply to -current anymore at some point. > >> > > Will what is provided right now in the patch work on -current? > >> > > >> > I am mean yes, after s/vm_cnt.v_free_count/vm_free_count()/g > >> > I am don't know how to have two distinct patch (for stable and > >> current) in one review. > >> > >> I'm experiencing these issues sporadically as well, would you mind > >> to publish this patch for fresh current? > > > > Week ago I am adopt and publish patch to fresh current and stable, is > > adopt need again? > > I applied the patch in the review yesterday to rev 333966, it applied > OK (with some fuzz). I will try to reproduce my issue with the patch. > > Some thoughts I had after looking a little bit at the output of top... > half of the RAM of my machine is in use, the other half is listed as > free. Swap gets used while there is plenty of free RAM. I have NUMA in > my kernel (it's 2 socket Xeon system). I don't see any NUMA specific > code in the diff (and I don't expect something there), but could it be > that some NUMA related behavior comes into play here too? Does it make > sense to try without NUMA in the kernel? Good question, NUMA in FreeBSD too new, nobody know it. For Linux, some effectt exists: exhaust all memory in one NUMA domain can cause memory deficit (swap/allocation failure/etc) simultaneous with many free memory in other NUMA domain. Yes, try w/o NUMA, this is may be interesting for NUMA developers. ___ 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: Deadlocks / hangs in ZFS
On Sun, May 27, 2018 at 09:41:59PM +0200, Kirill Ponomarev wrote: > On 05/22, Slawa Olhovchenkov wrote: > > > It has been a while since I tried Karl's patch the last time, and I > > > stopped because it didn't apply to -current anymore at some point. > > > Will what is provided right now in the patch work on -current? > > > > I am mean yes, after s/vm_cnt.v_free_count/vm_free_count()/g > > I am don't know how to have two distinct patch (for stable and current) in > > one review. > > I'm experiencing these issues sporadically as well, would you mind > to publish this patch for fresh current? Week ago I am adopt and publish patch to fresh current and stable, is adopt need again? ___ 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: Deadlocks / hangs in ZFS
On Tue, May 22, 2018 at 04:16:32PM +0200, Alexander Leidinger wrote:
>
> Quoting Slawa Olhovchenkov (from Tue, 22 May 2018
> 15:29:24 +0300):
>
> > On Tue, May 22, 2018 at 08:17:00AM -0400, Steve Wills wrote:
> >
> >> I may be seeing similar issues. Have you tried leaving top -SHa running
> >> and seeing what threads are using CPU when it hangs? I did and saw pid
> >> 17 [zfskern{txg_thread_enter}] using lots of CPU but no disk activity
> >> happening. Do you see similar?
>
> I will try and report back.
>
> > Can you try https://reviews.freebsd.org/D7538 and report?
>
> The patch tells it is against -STABLE, we're talking -current here.
ZFS don't changes this.
> It has been a while since I tried Karl's patch the last time, and I
> stopped because it didn't apply to -current anymore at some point.
> Will what is provided right now in the patch work on -current?
I am mean yes, after s/vm_cnt.v_free_count/vm_free_count()/g
I am don't know how to have two distinct patch (for stable and current) in one
review.
> As a data point, the system I talk about in the start of the thread
> has 64 GB RAM and the ARC is not limited via sysctl.
Currently vanlia ARC poorly limited via sysctl. After abd extra.
May be interesting test
./sys/cddl/contrib/opensolaris/uts/common/fs/zfs/abd.c:boolean_t
zfs_abd_scatter_enabled = B_FALSE;
(no sysctl for change this exist)
___
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: Deadlocks / hangs in ZFS
On Tue, May 22, 2018 at 08:17:00AM -0400, Steve Wills wrote:
> I may be seeing similar issues. Have you tried leaving top -SHa running
> and seeing what threads are using CPU when it hangs? I did and saw pid
> 17 [zfskern{txg_thread_enter}] using lots of CPU but no disk activity
> happening. Do you see similar?
Can you try https://reviews.freebsd.org/D7538 and report?
> On 05/22/18 04:17, Alexander Leidinger wrote:
> > Hi,
> >
> > does someone else experience deadlocks / hangs in ZFS?
> >
> > What I see is that if on a 2 socket / 4 cores -> 16 threads system I do
> > a lot in parallel (e.g. updating ports in several jails), then the
> > system may get into a state were I can login, but any exit (e.g. from
> > top) or logout of shell blocks somewhere. Sometimes it helps to CTRL-C
> > all updates to get the system into a good shape again, but most of the
> > times it doesn't.
> >
> > On another system at the same rev (333966) with a lot less CPUs (and AMD
> > instead of Intel), I don't see such a behavior.
> >
> > Bye,
> > Alexander.
> >
> ___
> 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: [RFC] Deprecation and removal of the drm2 driver
On Sat, May 19, 2018 at 08:38:20PM +0200, Jan Beich wrote: > Slawa Olhovchenkov writes: > > > On Fri, May 18, 2018 at 07:58:10PM +0200, Niclas Zeising wrote: > > > >> [ Cross posted to freebsd-current@ and freebsd-x11@. Please respect > >> reply-to and send all replies to freebsd-x11@. Thanks! ] > >> > >> > >> Hi! > >> I propose that we remove the old drm2 driver (sys/dev/drm2) from > >> FreeBSD. I suggest the driver is marked as deprecated in 11.x and > >> removed from 12.0, as was done for other drivers recently. Some > >> background and rationale: > >> > >> The drm2 driver was the original port of a KMS driver to FreeBSD. It > >> was done by Konstantin Belousov to support Intel graphics cards, and > >> later extended by Jean-Sébastien Pédron as well as Konstantin to match > >> what's in Linux 3.8. This included unstable support from Haswell, but > >> nothing newer than that. > >> > >> For quite some time now we have had the graphics/drm-stable-kmod and > >> graphics/drm-next-kmods which provides support for modern AMD and Intel > >> graphics cards. These ports, together with the linuxkpi, or lkpi, has > > > > What about old graphics card? I am have notebook w/ i945 chipset, is > > this supported by graphics/drm-*? > > > > And what about nvidia? > > (sorry, I am not developer this drivers, I am just user, I am don't > > know what need for nvidia work etc) > > NVIDIA dropped 32bit driver since 396.* series. None of x11/nvidia-driver* > currently depend on either drm.ko or drm2.ko. However, Linux driver > appears to depend on DRM/KMS since 364.12. Some of my hardware supported only by nvidia 340.106. ___ 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: [RFC] Deprecation and removal of the drm2 driver
On Fri, May 18, 2018 at 07:58:10PM +0200, Niclas Zeising wrote: > [ Cross posted to freebsd-current@ and freebsd-x11@. Please respect > reply-to and send all replies to freebsd-x11@. Thanks! ] > > > Hi! > I propose that we remove the old drm2 driver (sys/dev/drm2) from > FreeBSD. I suggest the driver is marked as deprecated in 11.x and > removed from 12.0, as was done for other drivers recently. Some > background and rationale: > > The drm2 driver was the original port of a KMS driver to FreeBSD. It > was done by Konstantin Belousov to support Intel graphics cards, and > later extended by Jean-Sébastien Pédron as well as Konstantin to match > what's in Linux 3.8. This included unstable support from Haswell, but > nothing newer than that. > > For quite some time now we have had the graphics/drm-stable-kmod and > graphics/drm-next-kmods which provides support for modern AMD and Intel > graphics cards. These ports, together with the linuxkpi, or lkpi, has What about old graphics card? I am have notebook w/ i945 chipset, is this supported by graphics/drm-*? And what about nvidia? (sorry, I am not developer this drivers, I am just user, I am don't know what need for nvidia work etc) > made it significantly easier to port and update our graphics drivers. > Further, these new drivers cover the same drivers as the old drm2 driver. > > What does the community think? Is there anyone still using the drm2 > driver on 12-CURRENT? If so, what is preventing you from switching to > the port? ___ 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: [RFC] Deprecation and removal of the drm2 driver
On Fri, May 18, 2018 at 02:03:32PM -0600, Warner Losh wrote: > > Check the Makefiles > > > > % more /usr/ports/graphics/drm-next-kmod/Makefile > > > > ONLY_FOR_ARCHS= amd64 > > ONLY_FOR_ARCHS_REASON= the new KMS components are only supported on amd64 > > > > Not to ia32 friendly. > > > > So do people use i386 for desktop? And need the latest KMS stuff? Removing drm2 remove all _graphics_ stuff. I am have i386 notebook, I am don't need lates KMS, I am need just X11/mplayer/firefox/skype. ___ 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: Strange ARC/Swap/CPU on yesterday's -CURRENT
On Fri, Mar 23, 2018 at 04:21:32PM -0700, Bryan Drewery wrote: > On 3/20/2018 12:07 AM, Peter Jeremy wrote: > > > > On 2018-Mar-11 10:43:58 -1000, Jeff Roberson > > wrote: > >> Also, if you could try going back to r328953 or r326346 and let me know if > >> the problem exists in either. That would be very helpful. If anyone is > >> willing to debug this with me contact me directly and I will send some > >> test patches or debugging info after you have done the above steps. > > > > I ran into this on 11-stable and tracked it to r326619 (MFC of r325851). > > I initially got around the problem by reverting that commit but either > > it or something very similar is still present in 11-stable r331053. > > > > I've seen it in my main server (32GB RAM) but haven't managed to reproduce > > it in smaller VBox guests - one difficulty I faced was artificially filling > > ARC. > > > > Looking at the ARC change you referred to from r325851 > https://reviews.freebsd.org/D12163, I am convinced that ARC backpressure > is completely broken. On my 78GB RAM system with ARC limited to 40GB and > doing a poudriere build of all LLVM and GCC packages at once in tmpfs I > can get swap up near 50GB and yet the ARC remains at 40GB through it > all. It's always been slow to give up memory for package builds but it > really seems broken right now. Can you test: revert all 'needfree' related commits and applay https://reviews.freebsd.org/D7538 ? ___ 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: Performance Benchmark for PTI (aka Meltdown mitigation)
On Mon, Mar 12, 2018 at 04:36:05PM -0400, Arshan Khanifar wrote: > I did some benchmarking for the two revisions: > results are here: > https://github.com/ArshanKhanifar/pti-benchmark/tree/master/stable-11-pre-after/results > first file is before pti patch and second file is after pti patch. 10x! .2 is is before pti patch and .4 is after pti patch? This is like pti patch (w/ pti off) do small speed up (about 1%)? > On Fri, Mar 9, 2018 at 10:16 AM, Slawa Olhovchenkov wrote: > > > On Fri, Mar 09, 2018 at 09:58:55AM -0500, Ed Maste wrote: > > > > > On 9 March 2018 at 07:01, Slawa Olhovchenkov wrote: > > > > On Thu, Mar 08, 2018 at 05:04:11PM -0500, Arshan Khanifar wrote: > > > > > > > >> Executive Summary: > > > >> - The PTI feature increases the system call times by more than 100%. > > > >> - As a macrobenchmark, buildworld was used. Wall clock and user time > > > >> showed no statistically-significant changes, while system time > > > >> increased by less than 5%. > > > >> > > > >> This email contains the results for benchmarking the performance of > > the > > > >> PTI patch on FreeBSD 12-current. As a microbenchmark, timing of > > > >> getppid(2) system call was used, and as a macrobenchmark, a number of > > > >> buildworld tasks were timed. > > > >> > > > > > > > > Can you also run pre-patched kernel? > > > > > > It's not easy to do an apples-to-apples comparison as there were a few > > > followup changes to the PTI work, interspersed with unrelated changes. > > > That said, I think Arshan has some benchmarks obtained during the > > > development of the PTI changes that may be illustrative. > > > > > > The best approach is probably to compare stable/11 at r329450 (last > > > stable/11 revision before the merge) with r329462 with PTI and IBRS > > > disabled. > > > > Stable/11 more interesting to me, nice to see. > > > > ___ 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: Performance Benchmark for PTI (aka Meltdown mitigation)
On Fri, Mar 09, 2018 at 09:58:55AM -0500, Ed Maste wrote: > On 9 March 2018 at 07:01, Slawa Olhovchenkov wrote: > > On Thu, Mar 08, 2018 at 05:04:11PM -0500, Arshan Khanifar wrote: > > > >> Executive Summary: > >> - The PTI feature increases the system call times by more than 100%. > >> - As a macrobenchmark, buildworld was used. Wall clock and user time > >> showed no statistically-significant changes, while system time > >> increased by less than 5%. > >> > >> This email contains the results for benchmarking the performance of the > >> PTI patch on FreeBSD 12-current. As a microbenchmark, timing of > >> getppid(2) system call was used, and as a macrobenchmark, a number of > >> buildworld tasks were timed. > >> > > > > Can you also run pre-patched kernel? > > It's not easy to do an apples-to-apples comparison as there were a few > followup changes to the PTI work, interspersed with unrelated changes. > That said, I think Arshan has some benchmarks obtained during the > development of the PTI changes that may be illustrative. > > The best approach is probably to compare stable/11 at r329450 (last > stable/11 revision before the merge) with r329462 with PTI and IBRS > disabled. Stable/11 more interesting to me, nice to see. ___ 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: Performance Benchmark for PTI (aka Meltdown mitigation)
On Thu, Mar 08, 2018 at 05:04:11PM -0500, Arshan Khanifar wrote: > Executive Summary: > - The PTI feature increases the system call times by more than 100%. > - As a macrobenchmark, buildworld was used. Wall clock and user time > showed no statistically-significant changes, while system time > increased by less than 5%. > > This email contains the results for benchmarking the performance of the > PTI patch on FreeBSD 12-current. As a microbenchmark, timing of > getppid(2) system call was used, and as a macrobenchmark, a number of > buildworld tasks were timed. > Can you also run pre-patched kernel? ___ 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: [RFC] future of drm1 in base
On Sat, Sep 02, 2017 at 10:02:57PM -0400, Johannes M Dieterich wrote: > Dear current/x11, > > please CC me on responses. > > I am writing you on behalf of the FreeBSDDesktop team concerning the > future of drm1 in base. > > drm1 in base supports the following GPUs: > * 3dfx Banshee/Voodoo3+ (tdfx) > * ATI Rage 128 (r128) > * ATI Rage Pro (mach64) > * Matrox G200/G400 (mga) > * Savage3D/MX/IX, Savage4, SuperSavage, Twister, ProSavage[DDR] (savage) > * SIS 300/630/540 and XGI V3XE/V5/V8 (sis) > * VIA Unichrome / Pro (via) > > Since their original introduction up to 2010 these drivers have mostly > been maintained as part of larger cleanups. The newest hardware drm1 > supports dates from 2004, if I am not mistaken, and most of the > hardware is AGP-based. Some of this hardware is part of more modern servers platforms (ex: http://www.supermicro.com/products/motherboard/Xeon/C600/X9DRT-F.cfm) > With the introduction of graphics/drm-next-kmod which brings its own > drm.ko following the Linux notation, we are facing collisions between > these old drivers' drm.ko and the newer one. > > We would like to hear if anybody still runs CURRENT on machines housing > the above GPUs and relies on drm1. > > If there are still a significant number of people running CURRENT on > this hardware in production, we would be willing to make a > graphics/drm-legacy-kmod port. > > Thanks, > > the FreeBSDDesktop team > ___ > 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: Time to increase MAXPHYS?
On Sat, Jun 03, 2017 at 11:49:01PM -0600, Warner Losh wrote: > > Netflix runs MAXPHYS of 8MB. There's issues with something this big, to be > > sure, especially on memory limited systems. Lots of hardware can't do this > > big an I/O, and some drivers can't cope, even if the underlying hardware > > can. Since we don't use such drivers at work, I don't have a list handy > > (though I think the SG list for NVMe limits it to 1MB). 128k is totally > > reasonable bump by default, but I think going larger by default should be > > approached with some caution given the overhead that adds to struct buf. > > Having it be a run-time tunable would be great. > > > > Of course 128k is reasonable, it's the current default :). I'd mean to say > that doubling would have a limited impact. 1MB might be a good default, but > it might be too big for smaller systems (nothing says it has to be a MI > constant, though). It would be a perfectly fine default if it were a > tunable. Some cloud providers limit IOPs per VM, for this cases MAXPHYS must be large as posible. ___ 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: Time to increase MAXPHYS?
On Sat, Jun 03, 2017 at 11:55:51PM -0400, Allan Jude wrote: > On 2017-06-03 22:35, Julian Elischer wrote: > > On 4/6/17 4:59 am, Colin Percival wrote: > >> On January 24, 1998, in what was later renumbered to SVN r32724, dyson@ > >> wrote: > >>> Add better support for larger I/O clusters, including larger physical > >>> I/O. The support is not mature yet, and some of the underlying > >>> implementation > >>> needs help. However, support does exist for IDE devices now. > >> and increased MAXPHYS from 64 kB to 128 kB. Is it time to increase it > >> again, > >> or do we need to wait at least two decades between changes? > >> > >> This is hurting performance on some systems; in particular, EC2 "io1" > >> disks > >> are optimized for 256 kB I/Os, EC2 "st1" (throughput optimized > >> spinning rust) > >> disks are optimized for 1 MB I/Os, and Amazon's NFS service (EFS) > >> recommends > >> using a maximum I/O size of 1 MB (and despite NFS not being *physical* > >> I/O it > >> seems to still be limited by MAXPHYS). > >> > > We increase it in freebsd 8 and 10.3 on our systems, Only good results. > > > > sys/sys/param.h:#define MAXPHYS (1024 * 1024) /* max raw I/O > > transfer size */ > > > > ___ > > 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" > > At some point Warner and I discussed how hard it might be to make this a > boot time tunable, so that big amd64 machines can have a larger value > without causing problems for smaller machines. > > ZFS supports a block size of 1mb, and doing I/Os in 128kb negates some > of the benefit. 16MB ___ 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: more default uid/gid for NFS in mountd
On Sun, May 14, 2017 at 01:12:11AM +, Rick Macklem wrote: > >> It is also the case that mountd.c doesn't look "nobody" up in the password > >> database > >> to set the default. It would be nice to do this, but it could result in > >> the mountd daemon > >> getting "stuck" during a boot waiting for an unresponsive LDAP service or > >> similar. > >> Does doing this sound like a good idea? > > > >This is (stuck at boot) already do for case of using NIS and nfsuserd. > There is a difference here. nfsuserd mpas between uid/names, so it can't work > without the password database. > mountd can work without the password database, so I held off on doing this > for now. > > >I am regular see this for case of DNS failed at boot. > >You offer don't impair current behaviour. > As an aside, if you have the critical entries in the local files (/etc/hosts, > /etc/passwd, > /etc/group) and then tell the libraries to search these first in > /etc/nsswitch.conf, then > you usually avoid this problem. Same as for 'nobody' for mountd? > Thanks for the comments, rick > Thanks! ___ 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: more default uid/gid for NFS in mountd
On Mon, May 08, 2017 at 11:45:46AM +, Rick Macklem wrote: > Hi, > > Five years ago (yea, it slipped through a crack;-), Slawa reported that files > created by root would end up owned by uid 2**32-2 (-2 as uint32_t). > This happens if there is no "-maproot=" in the /etc/exports line. > > The cause is obvious. The value is set to -2 by default. > > The question is... Should this be changed to 65534 (ie "nobody")? > - It would seem more consistent to make it the uid of nobody, but I can also > see > the argument that since it has been like this *forever*, that changing it > would be > a POLA violation. > What do others think? IMHO uid 2**32-2 is POLA violation. Nobody expect this uid. Too much number. This is like bug. > It is also the case that mountd.c doesn't look "nobody" up in the password > database > to set the default. It would be nice to do this, but it could result in the > mountd daemon > getting "stuck" during a boot waiting for an unresponsive LDAP service or > similar. > Does doing this sound like a good idea? This is (stuck at boot) already do for case of using NIS and nfsuserd. I am regular see this for case of DNS failed at boot. You offer don't impair current behaviour. Thanks! > Thanks for any comments, rick > ps: Here's the original email thread, in case you are interested: > > https://lists.freebsd.org/pipermail/freebsd-stable/2012-March/066868.html > ___ 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: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)
On Wed, Apr 05, 2017 at 04:15:41PM +, Alexey Dokuchaev wrote: > > I've also tried without WITH_DEBUG= and now. . . > > > > # pkg delete llvm40 > > Checking integrity... done (0 conflicting) > > Deinstallation has been requested for the following 1 packages (of 0 > > packages in the universe): > > > > Installed packages to be REMOVED: > > llvm40-4.0.0 > > > > Number of packages to be removed: 1 > > > > The operation will free 1 GiB. > > That 1G looks like a big jump from 259M of llvm39-3.9.1_1.txz to me. > I'm surely looking forward modularization of LLVM port; rebuilding it > every time becomes a real PITA given that X11 stack requires it. :-( What real reason of requiring llvm for X11? I am about run time depends: # pkg info -r llvm39 llvm39-3.9.1_4: libEGL-13.0.6 dri-13.0.6,2 # ldd /usr/local/lib/libXvMCr600.so /usr/local/lib/libXvMCr600.so: [...] libLLVM-3.9.so => /usr/local/llvm39/lib/libLLVM-3.9.so (0x803e0) libLTO.so => /usr/local/llvm39/lib/../lib/libLTO.so (0x80820) [...] # ls -lh /usr/local/llvm39/lib/libLLVM-3.9.so /usr/local/llvm39/lib/../lib/libLTO.so -rwxr-xr-x 1 root wheel38M Apr 2 18:18 /usr/local/llvm39/lib/../lib/libLTO.so -rwxr-xr-x 1 root wheel47M Apr 2 18:18 /usr/local/llvm39/lib/libLLVM-3.9.so libXvMCr600 realy do run-time llvm interpetation and linker-time optimisation?! Also, I am don't see any realy dependence libEGL-13.0.6 from llvm. ___ 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: CURRENT: slow like crap! ZFS scrubbing and ports update > 25 min
On Wed, Mar 22, 2017 at 10:25:24PM +0100, O. Hartmann wrote: > Am Wed, 22 Mar 2017 21:10:51 +0100 > Michael Gmelin schrieb: > > > > On 22 Mar 2017, at 21:02, O. Hartmann wrote: > > > > > > CURRENT (FreeBSD 12.0-CURRENT #82 r315720: Wed Mar 22 18:49:28 CET 2017 > > > amd64) is > > > annoyingly slow! While scrubbing is working on my 12 GB ZFS volume, > > > updating /usr/ports takes >25 min(!). That is an absolute record now. > > > > > > I do an almost daily update of world and ports tree and have periodic > > > scrubbing ZFS > > > volumes every 35 days, as it is defined in /etc/defaults. Prts tree > > > hasn't grown much, > > > the content of the ZFS volume hasn't changed much (~ 100 GB, its fill is > > > about 4 TB > > > now) and this is now for ~ 2 years constant. > > > > > > I've experienced before that while scrubbing the ZFS volume, some > > > operations, even the > > > update of /usr/ports which resides on that ZFS RAIDZ volume, takes a bit > > > longer than > > > usual - but never that long like now! > > > > > > Another box is quite unusable while it is scrubbing and it has been > > > usable times > > > before. The change is dramatic ... > > > > > > > What do "zpool list", "gstat" and "zpool status" show? > > > > > > > zpool list: > > NAME SIZE ALLOC FREE EXPANDSZ FRAGCAP DEDUP HEALTH ALTROOT > TANK00 10.9T 5.45T 5.42T - 7%50% 1.58x ONLINE - > > Deduplication is off right now, I had one ZFS filesystem with dedup enabled > > gstat: not shown here, but the drives comprise the volume (4x 3 TB) show 100% > busy each, > but one drive is always a bit off (by 10% lower) and this drive is walking > through all > four drives ada2, ada3, ada4 and ada5. Nothing unusual in that situation. But > the > throughput is incredible low, for example ada4: > > L(q) ops/sr/s kBps ms/rw/s kBps ms/w %busy Name > 2174174 1307 11.4 0 00.0 99.4| ada4 > > kBps (kilo Bits per second I presume) are peaking at ~ 4800 - 5000. On > another bos, this > is ~ 20x higher! Most time, kBps r and w stay at ~ 500 -600. kilo Bytes. 174 rps is normal for general 7200 RPM disk. Transfer too low by every request is about 1307/174 = ~8 KB. Don't know root cause of this. I am see raid-z of 4 disk, 8*3 = ~24KB per record. May be compession enable and zfs use 128KB record size? For this case this is expected performance. Use 1MB and higher record size. ___ 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: CURRENT: FreeBSD not reporting AES-NI on Intel(R) Xeon(R) CPU E5-1650 v3
On Sun, Mar 19, 2017 at 06:07:33PM +0200, Konstantin Belousov wrote: > On Sun, Mar 19, 2017 at 04:58:40PM +0100, Dimitry Andric wrote: > > On 19 Mar 2017, at 13:36, Rozhuk Ivan wrote: > > > > > > On Fri, 17 Mar 2017 17:53:24 +0100 > > > "O. Hartmann" wrote: > > > > > >>> Other OS detect AES-NI on this server? > > >> > > >> I havn't ried so far, the box is in heavy use. I'd like to check with > > >> some live USB drive versions and report later. > > >> > > > > > > You can write or find some program that read and decode CPUID and check > > > AES-NI support without reboot. > > > > The kernel already does this at boot time, and show the results, e.g.: > > > > CPU: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz (3391.68-MHz 686-class CPU) > > Origin="GenuineIntel" Id=0x306a9 Family=0x6 Model=0x3a Stepping=9 > > > > Features=0xfa3fbff > > > > Features2=0xffba2203 > > AMD Features=0x2810 > > AMD Features2=0x1 > > Structured Extended Features=0x202 > > TSC: P-state invariant > > > > Unfortunately the kernel does not expose this information via any > > sysctl, so some time after booting it may have "scrolled away" in > > dmesg. > It is quite pointless to expose the information through a sysctl, because > it is non-privileged and is available to usermode via execution of the > CPUID instruction, which is utilized by utilities listed below. > > Also, look at cpucontrol -i. % cpucontrol -i 0x1 /dev/cpuctl1 cpucontrol: error opening /dev/cpuctl1 for reading: Permission denied > > > > In that case, you can use either the misc/cpuid or the sysutils/cpuid > > ports to show this information, and even quite a lot more. > Or better, sysutils/x86info. % x86info x86info v1.31pre /dev/cpuctl0: Permission denied Found 24 identical CPUs Extended Family: 0 Extended Model: 4 Family: 6 Model: 79 Stepping: 1 Type: 0 (Original OEM) CPU Model (x86info's best guess): Unknown model. Processor name string (BIOS programmed): Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz Total processor threads: 24 This system has 2 six-core processors with hyper-threading (2 threads per core) running at an estimated 2.20GHz ___ 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: CURRENT: FreeBSD not reporting AES-NI on Intel(R) Xeon(R) CPU E5-1650 v3
On Sun, Mar 19, 2017 at 04:58:40PM +0100, Dimitry Andric wrote: > On 19 Mar 2017, at 13:36, Rozhuk Ivan wrote: > > > > On Fri, 17 Mar 2017 17:53:24 +0100 > > "O. Hartmann" wrote: > > > >>> Other OS detect AES-NI on this server? > >> > >> I havn't ried so far, the box is in heavy use. I'd like to check with > >> some live USB drive versions and report later. > >> > > > > You can write or find some program that read and decode CPUID and check > > AES-NI support without reboot. > > The kernel already does this at boot time, and show the results, e.g.: > > CPU: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz (3391.68-MHz 686-class CPU) > Origin="GenuineIntel" Id=0x306a9 Family=0x6 Model=0x3a Stepping=9 > > Features=0xfa3fbff > > Features2=0xffba2203 > AMD Features=0x2810 > AMD Features2=0x1 > Structured Extended Features=0x202 > TSC: P-state invariant > > Unfortunately the kernel does not expose this information via any > sysctl, so some time after booting it may have "scrolled away" in > dmesg. /var/run/dmesg.boot ___ 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: CURRENT: FreeBSD not reporting AES-NI on Intel(R) Xeon(R) CPU E5-1650 v3
On Fri, Mar 17, 2017 at 06:31:11PM +0100, O. Hartmann wrote: > Am Fri, 17 Mar 2017 20:07:35 +0300 > Slawa Olhovchenkov schrieb: > > > On Fri, Mar 17, 2017 at 05:53:24PM +0100, O. Hartmann wrote: > > > > > Am Fri, 17 Mar 2017 15:04:29 +0300 > > > Slawa Olhovchenkov schrieb: > > > > > > > On Fri, Mar 17, 2017 at 12:36:25PM +0100, O. Hartmann wrote: > > > > > > > > > Running recent CURRENT on a Fujitsu Celsius M740 equipted with an > > > > > Intel(R) > > > > > Xeon(R) CPU E5-1650 v3 @ 3.50GHz CPU makes me some trouble. > > > > > > > > > > FreeBSD does not report the existence or availability of AES-NI > > > > > feature, which > > > > > is supposed to be a feature of this type of CPU: > > > > > > > > What reassons to detect AES-NI by FreeBSD? > > > > > > What do you mean? I do not understand! FreeBSD is supposed to read the > > > CPUID and > > > therefore the capabilities as every other OS, too. But there may some > > > circumstances > > > why FBSD won't. I do not know, that is the reason why I'm asking here. > > > > This sample can have disabled AES-NI by vendor, in BIOS, for example. > > As I show by links this is posible. > > > > CPUID in you example don't show AES-NI capabilities, for example > > 1650v4 w/ AES-NI > > > > CPU: Intel(R) Xeon(R) CPU E5-1650 v4 @ 3.60GHz (3600.07-MHz K8-class CPU) > > Origin="GenuineIntel" Id=0x406f1 Family=0x6 Model=0x4f Stepping=1 > > > > Features=0xbfebfbff > > > > Features2=0x7ffefbff > > > > > > ^^ > > AMD Features=0x2c100800 > > AMD Features2=0x121 > > Structured Extended > > Features=0x21cbfbb > > XSAVE Features=0x1 VT-x: > > PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr > > TSC: P-state invariant, performance statistics > > > > In you sample: "TSCDLT,XSAVE" > > > > May be AES-NI disabled by vendor and FreeBSD correct show this. Or some bug > > in FreeBSD, > > AES-NI work and other OS show AES-NI capabilities. > > > > ___ > > 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" > > We have some LGA1151 XEON based 19 inch rack server, also equipted with > Haswell > E3-12XX-v3 XEONs and FreeBSD, also CURRENT, does show AES-NI. > > You're right, the vendor could have disabled AES-NI by intention - but they > offered this > box especially with AES-NI capabilities. > > See here: > > > http://freebsd.1045724.x6.nabble.com/r285947-broken-AESNI-support-No-aesni0-on-Intel-XEON-E5-1650-v3-on-Fujitsu-Celsius-M740-td6028895.html > > I feel a bit pissed off right now due to Fujitsu, because we started testing > some > encrypting features and I'd like to use AES-NI and I run into this issue > again. > > I need to know that FreeBSD is not the issue with this specific CPU type. I'm > still > frustrated by that stupid comment "UNIX is not supoorted" I got that time > then when I > reported 2015 the issue to Fujitsu. JFYI: 11-STABLE CPU: Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz (3500.08-MHz K8-class CPU) Origin="GenuineIntel" Id=0x306f2 Family=0x6 Model=0x3f Stepping=2 Features=0xbfebfbff Features2=0x7ffefbff ^ AMD Features=0x2c100800 AMD Features2=0x21 Structured Extended Features=0x37ab XSAVE Features=0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr TSC: P-state invariant, performance statistics ___ 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: CURRENT: FreeBSD not reporting AES-NI on Intel(R) Xeon(R) CPU E5-1650 v3
On Fri, Mar 17, 2017 at 05:53:24PM +0100, O. Hartmann wrote: > Am Fri, 17 Mar 2017 15:04:29 +0300 > Slawa Olhovchenkov schrieb: > > > On Fri, Mar 17, 2017 at 12:36:25PM +0100, O. Hartmann wrote: > > > > > Running recent CURRENT on a Fujitsu Celsius M740 equipted with an Intel(R) > > > Xeon(R) CPU E5-1650 v3 @ 3.50GHz CPU makes me some trouble. > > > > > > FreeBSD does not report the existence or availability of AES-NI feature, > > > which > > > is supposed to be a feature of this type of CPU: > > > > What reassons to detect AES-NI by FreeBSD? > > What do you mean? I do not understand! FreeBSD is supposed to read the CPUID > and > therefore the capabilities as every other OS, too. But there may some > circumstances why > FBSD won't. I do not know, that is the reason why I'm asking here. This sample can have disabled AES-NI by vendor, in BIOS, for example. As I show by links this is posible. CPUID in you example don't show AES-NI capabilities, for example 1650v4 w/ AES-NI CPU: Intel(R) Xeon(R) CPU E5-1650 v4 @ 3.60GHz (3600.07-MHz K8-class CPU) Origin="GenuineIntel" Id=0x406f1 Family=0x6 Model=0x4f Stepping=1 Features=0xbfebfbff Features2=0x7ffefbff ^^ AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0x21cbfbb XSAVE Features=0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr TSC: P-state invariant, performance statistics In you sample: "TSCDLT,XSAVE" May be AES-NI disabled by vendor and FreeBSD correct show this. Or some bug in FreeBSD, AES-NI work and other OS show AES-NI capabilities. ___ 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: CURRENT: FreeBSD not reporting AES-NI on Intel(R) Xeon(R) CPU E5-1650 v3
On Fri, Mar 17, 2017 at 12:36:25PM +0100, O. Hartmann wrote: > Running recent CURRENT on a Fujitsu Celsius M740 equipted with an Intel(R) > Xeon(R) CPU E5-1650 v3 @ 3.50GHz CPU makes me some trouble. > > FreeBSD does not report the existence or availability of AES-NI feature, which > is supposed to be a feature of this type of CPU: What reassons to detect AES-NI by FreeBSD? Other OS detect AES-NI on this server? AES-NI may be disabled by BIOS/vendor/BIOS settings https://forums.lenovo.com/t5/ThinkPad-11e-Windows-13-E-and/AES-NI-is-disabled-on-my-13-New-S2/td-p/3498468 http://h17007.www1.hpe.com/docs/iss/proliant_uefi/UEFI_Gen9_060216/s_enable_AES-NI.html http://en.community.dell.com/support-forums/servers/f/956/t/19509653 ___ 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: ISO image: where is the CLANG compiler?
On Wed, Jan 18, 2017 at 10:19:15AM +0100, O. Hartmann wrote: > Hello Daniel, > > thank you very much for responding! > > I just looked into "makeing release". I have a lot of NanoBSD images and build > environments for our purpose at work, but I always strip off the compiler, > too :-( > > I was realy badly surprised that on the ISOs the compiler is not present - for > the sake of space? If so, then best practice would be to melt everything down > to 1,66 MB size - as an ancient floppy would contain. Or better, Null. > Sorry ... It is hard these days to purchase 1GB USB flash drives, most of them > do have 2 GB at least. ISO images limited by size, for fit to real CD-R blank disks. ___ 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: recent change to vim defaults?
On Mon, Jan 16, 2017 at 05:25:26PM +0100, Baptiste Daroussin wrote: > On Mon, Jan 16, 2017 at 12:03:08AM +0800, Julian Elischer wrote: > > I noticed that suddenly vim is grabbing mouse movements, which makes life > > really hard. > > > > Was there a specific revision that brought in this change, and can it be > > removed? > > This change appeared in one of the last patchset of vim 7.4 and was one of the > "features" of the vim 8.0 release. > > I do agree this is just totally painful :( Wat about edit 8-bit files in utf-8 locale? Still corrupted files? ___ 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: Mozilla firefox freezes/zombie on FreeBSD current
On Mon, Dec 26, 2016 at 10:29:33PM +0300, Subbsd wrote: > Hi, > > On recent FreeBSD version (tested on two host: one from > svn://svn.freebsd.org/base/head ( r310507 now) and second from > https://github.com/FreeBSDDesktop/freebsd-base-graphics.git / > drm-next-4.7 ) and latest firefox ( firefox-50.1.0_4,1 ) I often get > into a situation where firefox is hands. What about downgrade to ff-48? ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On Fri, Dec 23, 2016 at 09:37:40PM +0100, Willem Jan Withagen wrote: > On 23-12-2016 20:30, Slawa Olhovchenkov wrote: > > On Fri, Dec 23, 2016 at 08:16:39PM +0100, Willem Jan Withagen wrote: > > > >> On 23-12-2016 14:26, Slawa Olhovchenkov wrote: > >>> On Thu, Dec 22, 2016 at 09:26:02PM +0100, Willem Jan Withagen wrote: > >>> > >>>> On 16-12-2016 00:57, Adrian Chadd wrote: > >>>>> heh, an updated BIOS that solves the problem will solve the problem. :) > >>>>> > >>>>> I think you have enough information to provide to supermicro. Ie, > >>>>> "SMAP says X, when physical memory pages at addresses X are accessed, > >>>>> they don't behave like memory, maybe something is wrong". > >>>>> > >>>>> All I can think of is some hack to add a blacklist for that region so > >>>>> you can boot the unit. But it makes me wonder what else is going on. > >>>> > >>>> I have an X10DRL-iT with 256Gb and 2* 2630V4 available for testing until > >>>> begin January. Started it on 11-RELEASE and upgraded to 12-CURRENT of > >>>> 20-12-2016. > >>>> Boots just fine, and seems to run OKE. > >>>> > >>>> If anything useful to test, just let me know. > >>> > >>> For touch issuse you must enable in BIOS both NUMA and Memory > >>> Interleave below 4G. > >> > >> Numa was already on, but I cannot find the Memory Interleave option. > > > > for X10DRi: > > > > Advanced/Chipset Config/North Bridge/Memory Config/Socket Interleave below > > 4G > > The only thing that could be this is: > a7 mode, > but that is already enabled. > This speaks about a bit higher memory bandwidth. In may case A7 immediately below 'Socket Interleave below 4G' > On the PCIe page ther is something like: > above 4G encoding > but that will probably not be it. > > --WjW > ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On Fri, Dec 23, 2016 at 08:16:39PM +0100, Willem Jan Withagen wrote: > On 23-12-2016 14:26, Slawa Olhovchenkov wrote: > > On Thu, Dec 22, 2016 at 09:26:02PM +0100, Willem Jan Withagen wrote: > > > >> On 16-12-2016 00:57, Adrian Chadd wrote: > >>> heh, an updated BIOS that solves the problem will solve the problem. :) > >>> > >>> I think you have enough information to provide to supermicro. Ie, > >>> "SMAP says X, when physical memory pages at addresses X are accessed, > >>> they don't behave like memory, maybe something is wrong". > >>> > >>> All I can think of is some hack to add a blacklist for that region so > >>> you can boot the unit. But it makes me wonder what else is going on. > >> > >> I have an X10DRL-iT with 256Gb and 2* 2630V4 available for testing until > >> begin January. Started it on 11-RELEASE and upgraded to 12-CURRENT of > >> 20-12-2016. > >> Boots just fine, and seems to run OKE. > >> > >> If anything useful to test, just let me know. > > > > For touch issuse you must enable in BIOS both NUMA and Memory > > Interleave below 4G. > > Numa was already on, but I cannot find the Memory Interleave option. for X10DRi: Advanced/Chipset Config/North Bridge/Memory Config/Socket Interleave below 4G ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On Thu, Dec 22, 2016 at 09:26:02PM +0100, Willem Jan Withagen wrote: > On 16-12-2016 00:57, Adrian Chadd wrote: > > heh, an updated BIOS that solves the problem will solve the problem. :) > > > > I think you have enough information to provide to supermicro. Ie, > > "SMAP says X, when physical memory pages at addresses X are accessed, > > they don't behave like memory, maybe something is wrong". > > > > All I can think of is some hack to add a blacklist for that region so > > you can boot the unit. But it makes me wonder what else is going on. > > I have an X10DRL-iT with 256Gb and 2* 2630V4 available for testing until > begin January. Started it on 11-RELEASE and upgraded to 12-CURRENT of > 20-12-2016. > Boots just fine, and seems to run OKE. > > If anything useful to test, just let me know. For touch issuse you must enable in BIOS both NUMA and Memory Interleave below 4G. ___ 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: FreeBSD system profiling and tuning for 10, 11 and 12
On Sat, Dec 17, 2016 at 10:43:52AM +0100, Olivier Cochard-Labbé wrote: > On Sat, Dec 17, 2016 at 10:19 AM, Slawa Olhovchenkov wrote: > > > > > === > > On FreeBSD older than 11.0, use more compact ip_fastfoward routine. It > > processes most packets falling back to 'normal' forward routine for > > fragments, packets with options, etc. Can save you up to 20% speed > > (but will break IPSec). > > > > net.inet.ip.fastforwarding=1 > > === > > > > I am not found in 11/12 this sysctl/tunable. > > > > Yes, this sysctl is available "on FreeBSD older than 11.0". It's was > improved, renamed tryforward, and it's the default method since 11.0. Sorry, missreading. ___ 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: FreeBSD system profiling and tuning for 10, 11 and 12
On Sat, Dec 17, 2016 at 04:06:40PM +0800, Julian Elischer wrote: > Hi > > I'm looking for recent information regarding profiling and tuning in > FreeBSD. > > Google has turned up some links but I think that the best leads are > still hiding.. > for example I only found > https://wiki.freebsd.org/NetworkPerformanceTuning recently. > > (BTW Anyone who has a moment is encouraged to check if they have > anything to add to it.) === Ensure BPF is OFF. No tcpdump, cdpd, lldpd, dhcpd, dhcp-relay. Patches are coming. Check netstat -B. === Don't see any problem with tcpdump up to 40G. tcpdump used for capture selected stream. === On FreeBSD older than 11.0, use more compact ip_fastfoward routine. It processes most packets falling back to 'normal' forward routine for fragments, packets with options, etc. Can save you up to 20% speed (but will break IPSec). net.inet.ip.fastforwarding=1 === I am not found in 11/12 this sysctl/tunable. === Skip feeding /dev/random from network by adding harvest_mask="351" to /etc/rc.conf or theses line to /etc/sysctl.conf: kern.random.sys.harvest.ethernet=0 kern.random.sys.harvest.point_to_point=0 kern.random.sys.harvest.interrupt=0 === On 11: # sysctl kern.random.sys.harvest sysctl: unknown oid 'kern.random.sys.harvest' > I am sure there is better information around for profiling the kernel > and modules, > but I am not seeing "the definitive profiler's guide" out there. I do > know several people > have blogs that cover this sort of thing. If you have one or know of good > profiling resources we should gather them.. send them to me and I'll > try make > sure everything is up to date, and put them together in a wiki page. > > there is already some stuff there, > (see > https://wiki.freebsd.org/NetworkPerformanceTuning?action=fullsearch&context=180&value=profiling&fullsearch=Text > > ) > but it could do with gathering together. You might surprised, but various options in BIOS can gain up to 10-20%% every, 50% total. Also, be careful about using internal architectures detials. I am already overloaded: a) bandwidtch of DMI2 link b) bandwidtch of 8x PCIe3 Not all cores equals for IRQ handling and cost of PCIe access. ___ 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: best approximation of getcpu() ?
On Fri, Dec 16, 2016 at 03:17:19AM +0100, Luigi Rizzo wrote: > TL;DR; is there any way a userspace thread in FreeBSD can tell > on which CPU it is (was) running ? I know the thread can migrate > at any time but as long as the event is rare I can live with > the occasionally wrong information. > Linux has getcpu(2) which is exposed by glibc as sched_getcpu(3), > but the linuxulator in FreeBSD only has a dummy (uniplemented) > function for that syscall. > > FULL DESCRIPTION > It is common practice, when building scalable systems, to use per-cpu > resources that can be accessed without contention by just protecting > them with a CLI; STI; pair. Multiqueue NICs typically do this to > build a lock-free transmit path. In [1] we show an in-kernel > scheduler that maps a large number of clients to a (much smaller) > number of lock-free mailboxes, one per core. > > In the kernel we can do CLI and STI and access curcpu. > In userspace a suitably privileged process can indeed open /dev/io > to acquire the right to use CLI and STI, though I am not sure > wether curcpu is available in some way. > > Of course running userspace code with interrupts disabled is risky, > but we can use the per-cpu trick with a small tweak, namely, > protect each resouce with a lock. If the thread does not migrate > imediately after getcpu(), we will access the lock (and the resource) > almost always from the same cpu hence very efficiently. > Occasional migration may cause contention but should not > alter too much the good performance of this scheme. > > So, any idea before I add a syscall/ioctl (or extend one) > to export this information ? Most hard task is discover what irq handle specific NIC tx/rx queue (assume irq already have affinity). After this discover (by some magic shit) no problem to start pthread and execute some like CPU_ZERO(&mask); CPU_SET(i, &mask); pthread_attr_init(&attr); pthread_attr_setaffinity_np(&attr, sizeof(mask), &mask); pthread_create(&balancer[i].tid, &attr, balancer_thread, &balancer[i]); pthread_set_name_np(balancer[i].tid, name); ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On Thu, Dec 15, 2016 at 03:56:56PM +0200, Konstantin Belousov wrote:
> > > Possibly, the dmesg of the boot (with late_console=0) with this and only
> > > this patch applied against stock HEAD. This might be long.
> >
> > Do you need all (262144?) lines?
> >
> > Testing system
> > memorypb
> > 0x204000
> > pb 0x2040001000
> > pb 0x2040002000
> > pb 0x2040003000
> > pb 0x2040004000
> > pb 0x2040005000
> > pb 0x2040006000
> > [...]
> > pb 0x207000
> >
> > > diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
> > > index 682307f5fe4..072c8d76acf 100644
> > > --- a/sys/amd64/amd64/machdep.c
> > > +++ b/sys/amd64/amd64/machdep.c
> > > @@ -1400,6 +1400,7 @@ getmemsize(caddr_t kmdp, u_int64_t first)
> > >*/
> > > *(int *)ptr = tmp;
> > >
> > > +if (page_bad) printf("pb 0x%lx\n", pa);
> > > skip_memtest:
> > > /*
> > >* Adjust array of valid/good pages.
> >
> > PS: memtest86 hung at test 128-130G (server have 128G installed).
> Well, the physical memory is 128G, but it is not mapped contiguously into
> the address space accessible to the processors. E.g. in the SMAPs you
> posted above, there are several holes (type 2) used for PCIe config
> window, PCI BARs, APICs, and other i/o register pages. Intel chipsets
> allow to remap the RAM hidden by the io pages, which is probably not
> done correctly by BIOS.
>
> The SMAP clearly reports segment 0x1-0x208000 as populated
> by RAM, this is 4G-130G. Very primitive memory test in kernel does
> not like all pages starting at 129G. Possibly important detail is that
> kernel memory test only touches first 4 bytes on each page. So if BIOS
> erronously mapped any io registers into that range, memory test might
> luckily avoid touching anything critical, but still noting that the
> page does not behave as RAM.
>
> Update BIOS, and if the issue persists, contact supermicro. This
> interesting detail adds even more evidence that BIOS is problematic.
Updated BIOS don't solve this.
___
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: Enabling NUMA in BIOS stop booting FreeBSD
On Thu, Dec 15, 2016 at 02:33:30PM +0200, Konstantin Belousov wrote:
> On Thu, Dec 15, 2016 at 01:51:18PM +0300, Slawa Olhovchenkov wrote:
> > On Wed, Dec 14, 2016 at 09:03:49PM +0200, Konstantin Belousov wrote:
> >
> > > So my opinion did not changed, this sounds like firmware problem.
> > > I do not see how can I drill into it more.
> >
> > I am don't know how it related. msgbufp mapped different with and w/o
> > memory test:
> >
> > w/o memory test, hang:
> > msgbufp=0xf8207ff0 pa_indx=7 phys_avail[pa_indx]=207ff0
> >
> > w/ memory test, boot:
> > msgbufp=0xf8203ff0 pa_indx=7 phys_avail[pa_indx]=203ff0
> Interesting.
>
> Can you show me
> - the output of the smap command from the loader (yes, I know it was already
> shown, I want it in the same mail as the data below for convenience);
OK set hw.memtest.tests=1
OK smap
SMAP type=01 base= len=00099c00 attr=01
SMAP type=02 base=00099c00 len=6400 attr=01
SMAP type=02 base=000e len=0002 attr=01
SMAP type=01 base=0010 len=7906b000 attr=01
SMAP type=02 base=7916b000 len=00936000 attr=01
SMAP type=04 base=79aa1000 len=00509000 attr=01
SMAP type=02 base=79faa000 len=02056000 attr=01
SMAP type=01 base=0001 len=001f8000 attr=01
SMAP type=02 base=7c00 len=1400 attr=01
SMAP type=02 base=fed1c000 len=00029000 attr=01
SMAP type=02 base=ff00 len=0100 attr=01
> - the output of sysctl machdep.smap after the succesfull boot with the
> memtest enabled.
machdep.smap:
SMAP type=01, xattr=01, base=, len=00099c00
SMAP type=02, xattr=01, base=00099c00, len=6400
SMAP type=02, xattr=01, base=000e, len=0002
SMAP type=01, xattr=01, base=0010, len=7906b000
SMAP type=02, xattr=01, base=7916b000, len=00936000
SMAP type=04, xattr=01, base=79aa1000, len=00509000
SMAP type=02, xattr=01, base=79faa000, len=02056000
SMAP type=01, xattr=01, base=0001, len=001f8000
SMAP type=02, xattr=01, base=7c00, len=1400
SMAP type=02, xattr=01, base=fed1c000, len=00029000
SMAP type=02, xattr=01, base=ff00, len=0100
> Possibly, the dmesg of the boot (with late_console=0) with this and only
> this patch applied against stock HEAD. This might be long.
Do you need all (262144?) lines?
Testing system
memorypb
0x204000
pb 0x2040001000
pb 0x2040002000
pb 0x2040003000
pb 0x2040004000
pb 0x2040005000
pb 0x2040006000
[...]
pb 0x207000
> diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
> index 682307f5fe4..072c8d76acf 100644
> --- a/sys/amd64/amd64/machdep.c
> +++ b/sys/amd64/amd64/machdep.c
> @@ -1400,6 +1400,7 @@ getmemsize(caddr_t kmdp, u_int64_t first)
>*/
> *(int *)ptr = tmp;
>
> +if (page_bad) printf("pb 0x%lx\n", pa);
> skip_memtest:
> /*
>* Adjust array of valid/good pages.
PS: memtest86 hung at test 128-130G (server have 128G installed).
___
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: Enabling NUMA in BIOS stop booting FreeBSD
On Wed, Dec 14, 2016 at 09:03:49PM +0200, Konstantin Belousov wrote: > So my opinion did not changed, this sounds like firmware problem. > I do not see how can I drill into it more. I am don't know how it related. msgbufp mapped different with and w/o memory test: w/o memory test, hang: msgbufp=0xf8207ff0 pa_indx=7 phys_avail[pa_indx]=207ff0 w/ memory test, boot: msgbufp=0xf8203ff0 pa_indx=7 phys_avail[pa_indx]=203ff0 ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On Wed, Dec 14, 2016 at 09:43:24PM +0200, Konstantin Belousov wrote: > On Wed, Dec 14, 2016 at 10:29:43PM +0300, Slawa Olhovchenkov wrote: > > On Wed, Dec 14, 2016 at 09:03:49PM +0200, Konstantin Belousov wrote: > > > > > On Wed, Dec 14, 2016 at 06:26:27PM +0300, Slawa Olhovchenkov wrote: > > > > For test hardware setup (NUMA+interleave), what ISO I can try to boot? > > > Didn't you already tried ? > > > > Different from FreeBSD. > Can you reformulate the statement ? > Did you booted some other (non-FreeBSD) OS and it hung with that options > as well ? No, I don't try now, can you advice some OS for test? > > For sure about firmware problem and complains to Supermicro. > > I think FreeBSD problem don't be accepted by Supermicro. > You never know. ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On Wed, Dec 14, 2016 at 09:03:49PM +0200, Konstantin Belousov wrote: > On Wed, Dec 14, 2016 at 06:26:27PM +0300, Slawa Olhovchenkov wrote: > > On Wed, Dec 14, 2016 at 03:13:36PM +0300, Slawa Olhovchenkov wrote: > > > > > On Wed, Dec 14, 2016 at 01:39:27PM +0200, Konstantin Belousov wrote: > > > > > > > In other words, it is almost certainly the hang and not a fault causing > > > > hang. This means that the machine is not compliant with the IA32 > > > > architecture, in particular, the region reported as normal memory by > > > > E820 BIOS service does not behave as normal memory. > > > > > > > > Since regardless of the option setting, the memory map is same, and > > > > bootstrap page table only depend on the memory map, we use the same page > > > > table when hanging and when operating correctly. We do not fault or hang > > > > when the option is turned off, which together with the improved early > > > > fault handling in the patch, makes it almost certain that the problem is > > > > in hardware configuration and not in our early setup. > > > > > > > > Of course, the most puzzling part is that memory test makes the hang > > > > go away, while repeating memory test operation only on the msgbuf region > > > > does not. msgbuf is special in that it is located at TOHM (top of high > > > > memory). It spans 128KB from below it to the last byte of the last > > > > physical segment. > > > > > > > > The only ideas I have right now is that there is either a bug in the > > > > Caching Agent/Home agent/IMC configuration in BIOS, in which case there > > > > is nothing OS can do to mitigate it. Or it might be that the memory > > > > map reported by CMS is wrong (you said that you use legacy boot, right > > > > ?). This is not too surprising if true, because non-EFI boot code path > > > > definitely get less and less testing. > > > > > > > > For the later case (potential bug in CMS), could you switch to EFI boot > > > > mode and see whether the issue magically healths itself ? You could > > > > boot > > > > from USB stick in EFI mode without reinstalling for test. > > > > > > I can't boot from USB stick -- this is remote DC and IPMI allow only > > > CDROM emulation. > > > > > > OK, I am boot in UEFI 12.0 snapshot ISO. > > > Boot ok. > > > > Sorry. Overload bu work and test wrong combination (NUMA=ON, > > interleave=OFF) > > > > snapshot iso don't boot with NUMA=ON interleave=ON > Ok. > > > > > For test hardware setup (NUMA+interleave), what ISO I can try to boot? > Didn't you already tried ? Different from FreeBSD. For sure about firmware problem and complains to Supermicro. I think FreeBSD problem don't be accepted by Supermicro. ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On Wed, Dec 14, 2016 at 03:13:36PM +0300, Slawa Olhovchenkov wrote: > On Wed, Dec 14, 2016 at 01:39:27PM +0200, Konstantin Belousov wrote: > > > In other words, it is almost certainly the hang and not a fault causing > > hang. This means that the machine is not compliant with the IA32 > > architecture, in particular, the region reported as normal memory by > > E820 BIOS service does not behave as normal memory. > > > > Since regardless of the option setting, the memory map is same, and > > bootstrap page table only depend on the memory map, we use the same page > > table when hanging and when operating correctly. We do not fault or hang > > when the option is turned off, which together with the improved early > > fault handling in the patch, makes it almost certain that the problem is > > in hardware configuration and not in our early setup. > > > > Of course, the most puzzling part is that memory test makes the hang > > go away, while repeating memory test operation only on the msgbuf region > > does not. msgbuf is special in that it is located at TOHM (top of high > > memory). It spans 128KB from below it to the last byte of the last > > physical segment. > > > > The only ideas I have right now is that there is either a bug in the > > Caching Agent/Home agent/IMC configuration in BIOS, in which case there > > is nothing OS can do to mitigate it. Or it might be that the memory > > map reported by CMS is wrong (you said that you use legacy boot, right > > ?). This is not too surprising if true, because non-EFI boot code path > > definitely get less and less testing. > > > > For the later case (potential bug in CMS), could you switch to EFI boot > > mode and see whether the issue magically healths itself ? You could boot > > from USB stick in EFI mode without reinstalling for test. > > I can't boot from USB stick -- this is remote DC and IPMI allow only > CDROM emulation. > > OK, I am boot in UEFI 12.0 snapshot ISO. > Boot ok. Sorry. Overload bu work and test wrong combination (NUMA=ON, interleave=OFF) snapshot iso don't boot with NUMA=ON interleave=ON For test hardware setup (NUMA+interleave), what ISO I can try to boot? PS: memmaps: NUMA=ON interleave=OFF OK memmap Type Physical Virtual #Pages Attr BootServicesCode 0008 UC WC WT WB ConventionalMemory 8000 0027 UC WC WT WB BootServicesData 0002f000 0011 UC WC WT WB BootServicesCode 0004 0060 UC WC WT WB ConventionalMemory 0010 000660a3 UC WC WT WB BootServicesData 661a3000 0080 UC WC WT WB ConventionalMemory 66223000 76b8 UC WC WT WB LoaderData 6d8db000 8000 UC WC WT WB LoaderCode 758db000 0070 UC WC WT WB BootServicesData 7594b000 3220 UC WC WT WB ConventionalMemory 78b6b000 028e UC WC WT WB BootServicesCode 78df9000 0372 UC WC WT WB Reserved 7916b000 0817 UC WC WT WB ConventionalMemory 79982000 011f UC WC WT WB ACPIMemoryNVS 79aa1000 0509 UC WC WT WB RuntimeServicesData 79faa000 1dbd UC WC WT WB RuntimeServicesCode 7bd67000 0061 UC WC WT WB BootServicesData 7bdc8000 0001 UC WC WT WB RuntimeServicesData 7bdc9000 0086 UC WC WT WB BootServicesData 7be4f000 01b1 UC WC WT WB ConventionalMemory 0001 01f8 UC WC WT WB Reserved 7c00 4000 MemoryMappedIO 8000 0001 UC MemoryMappedIO fed1c000 0029 UC MemoryMappedIO ff00 1000 UC NUMA=ON interleave=ON Type Physical Virtual #Pages Attr BootServicesCode 0008 UC WC WT WB ConventionalMemory 8000 0027 UC WC WT WB BootServicesData 0002f000 0011 UC WC WT WB BootServicesCode 0004 0060 UC WC WT WB ConventionalMemory 0010 000660a3 UC WC WT WB BootServicesData 661a3000 0080 UC WC WT WB ConventionalMemory 66223000 76b8 UC WC WT WB LoaderData 6d8db000 8000 UC WC WT WB LoaderCode 758db000 0070 UC WC WT WB BootServicesData 7594b000 00
Re: Enabling NUMA in BIOS stop booting FreeBSD
On Wed, Dec 14, 2016 at 04:40:33PM +0200, Konstantin Belousov wrote: > On Wed, Dec 14, 2016 at 03:13:36PM +0300, Slawa Olhovchenkov wrote: > > On Wed, Dec 14, 2016 at 01:39:27PM +0200, Konstantin Belousov wrote: > > > > > In other words, it is almost certainly the hang and not a fault causing > > > hang. This means that the machine is not compliant with the IA32 > > > architecture, in particular, the region reported as normal memory by > > > E820 BIOS service does not behave as normal memory. > > > > > > Since regardless of the option setting, the memory map is same, and > > > bootstrap page table only depend on the memory map, we use the same page > > > table when hanging and when operating correctly. We do not fault or hang > > > when the option is turned off, which together with the improved early > > > fault handling in the patch, makes it almost certain that the problem is > > > in hardware configuration and not in our early setup. > > > > > > Of course, the most puzzling part is that memory test makes the hang > > > go away, while repeating memory test operation only on the msgbuf region > > > does not. msgbuf is special in that it is located at TOHM (top of high > > > memory). It spans 128KB from below it to the last byte of the last > > > physical segment. > > > > > > The only ideas I have right now is that there is either a bug in the > > > Caching Agent/Home agent/IMC configuration in BIOS, in which case there > > > is nothing OS can do to mitigate it. Or it might be that the memory > > > map reported by CMS is wrong (you said that you use legacy boot, right > > > ?). This is not too surprising if true, because non-EFI boot code path > > > definitely get less and less testing. > > > > > > For the later case (potential bug in CMS), could you switch to EFI boot > > > mode and see whether the issue magically healths itself ? You could boot > > > from USB stick in EFI mode without reinstalling for test. > > > > I can't boot from USB stick -- this is remote DC and IPMI allow only > > CDROM emulation. > > > > OK, I am boot in UEFI 12.0 snapshot ISO. > > Boot ok. > > > > Can I convert installed OS to UEFI mode? > I am not sure what do you ask there. Are you asking whether I need any > further information from the broken setup ? I believe that no, I cannot > debug this any further. I am don't touch UEFI before. I am try to know how to switch for existing installtion from legacy boot to UEFI boot (for use less broken setup). [may be NUMA+interleaving don't give me any good, but I am need test for sure] > I think that the interesting piece of data that can be obtained now is > the memmap command output from the EFI loader from all three configurations, > NUMA on/off and interleaving. What you mean 'EFI loader'? FreeBSD loader for UEFI mode? Or UEFI shell from BIOS? > > > > > Do you use latest BIOS for your motherboard ? > > > > This is new MB (X10DRi) w/ BIOS 2.0, new is 2.1 but update is not > > simple (need to prepare bootable dos ISO, mostly utilites don't work > > under FreeBSD). > IMO the only way to fix this issue, if it is really important, is > to contact supermicro and show them the bug. But this only makes sense if > repeated on the latest firmware version. ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On Wed, Dec 14, 2016 at 01:39:27PM +0200, Konstantin Belousov wrote: > In other words, it is almost certainly the hang and not a fault causing > hang. This means that the machine is not compliant with the IA32 > architecture, in particular, the region reported as normal memory by > E820 BIOS service does not behave as normal memory. > > Since regardless of the option setting, the memory map is same, and > bootstrap page table only depend on the memory map, we use the same page > table when hanging and when operating correctly. We do not fault or hang > when the option is turned off, which together with the improved early > fault handling in the patch, makes it almost certain that the problem is > in hardware configuration and not in our early setup. > > Of course, the most puzzling part is that memory test makes the hang > go away, while repeating memory test operation only on the msgbuf region > does not. msgbuf is special in that it is located at TOHM (top of high > memory). It spans 128KB from below it to the last byte of the last > physical segment. > > The only ideas I have right now is that there is either a bug in the > Caching Agent/Home agent/IMC configuration in BIOS, in which case there > is nothing OS can do to mitigate it. Or it might be that the memory > map reported by CMS is wrong (you said that you use legacy boot, right > ?). This is not too surprising if true, because non-EFI boot code path > definitely get less and less testing. > > For the later case (potential bug in CMS), could you switch to EFI boot > mode and see whether the issue magically healths itself ? You could boot > from USB stick in EFI mode without reinstalling for test. I can't boot from USB stick -- this is remote DC and IPMI allow only CDROM emulation. OK, I am boot in UEFI 12.0 snapshot ISO. Boot ok. Can I convert installed OS to UEFI mode? > Do you use latest BIOS for your motherboard ? This is new MB (X10DRi) w/ BIOS 2.0, new is 2.1 but update is not simple (need to prepare bootable dos ISO, mostly utilites don't work under FreeBSD). ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On Wed, Dec 14, 2016 at 12:27:11PM +0200, Konstantin Belousov wrote: > On Wed, Dec 14, 2016 at 11:53:50AM +0200, Konstantin Belousov wrote: > > On Tue, Dec 13, 2016 at 08:43:45PM +0300, Slawa Olhovchenkov wrote: > > > On Tue, Dec 13, 2016 at 07:25:29PM +0200, Konstantin Belousov wrote: > > > > > > > This is not what I expected. > > > > Also, I realized that I mis-read the memory test code. It does not > > > > obliterate memory, old content is preserved. > > > > > > > > Please do exactly the same testing with another patch, at the end of the > > > > message. There could be more output, up to 256 lines. > > > > > > No problem. > > > > > > Booting... > > > KDB: debugger backends: ddb > > > KDB: current backend: ddb > > > SMAP type=01 base= len=00099c00 > > > SMAP type=02 base=00099c00 len=6400 > > > SMAP type=02 base=000e len=0002 > > > SMAP type=01 base=0010 len=7906b000 > > > SMAP type=02 base=7916b000 len=00936000 > > > SMAP type=04 base=79aa1000 len=00509000 > > > SMAP type=02 base=79faa000 len=02056000 > > > SMAP type=01 base=0001 len=001f8000 > > > SMAP type=02 base=7c00 len=1400 > > > SMAP type=02 base=fed1c000 len=00029000 > > > SMAP type=02 base=ff00 len=0100 > > > TTT1 0xf8207ff0 0xf8207fb8 10 > > > . 0 > > > . 1000 > > > . 2000 > > > . 3000 > > > . 4000 > > > . 5000 > > > . 6000 > > > . 7000 > > > . 8000 > > > . 9000 > > > . a000 > > > . b000 > > > . c000 > > > . d000 > > > . e000 > > > . f000 > > > . 1 > > > . 11000 > > > . 12000 > > > . 13000 > > > . 14000 > > > . 15000 > > > . 16000 > > > . 17000 > > > . 18000 > > > . 19000 > > > . 1a000 > > > . 1b000 > > > . 1c000 > > > . 1d000 > > > . 1e000 > > > . 1f000 > > > . 2 > > > . 21000 > > > . 22000 > > > . 23000 > > > . 24000 > > > . 25000 > > > . 26000 > > > . 27000 > > > . 28000 > > > . 29000 > > > . 2a000 > > > . 2b000 > > > > > > > Do you still have access to the machine ? > > If yes, please try this patch (against clean tree, as always) with the > > same instructions as before. > > > > Updated patch, it should provide the expected information in case of > page fault. Booting... KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base= len=00099c00 SMAP type=02 base=00099c00 len=6400 SMAP type=02 base=000e len=0002 SMAP type=01 base=0010 len=7906b000 SMAP type=02 base=7916b000 len=00936000 SMAP type=04 base=79aa1000 len=00509000 SMAP type=02 base=79faa000 len=02056000 SMAP type=01 base=0001 len=001f8000 SMAP type=02 base=7c00 len=1400 SMAP type=02 base=fed1c000 len=00029000 SMAP type=02 base=ff00 len=0100 TTT1 0xf8207ff0 0xf8207fb8 10 . 0 . 1000 . 2000 . 3000 . 4000 . 5000 . 6000 . 7000 . 8000 . 9000 . a000 . b000 . c000 . d000 . e000 . f000 . 1 . 11000 . 12000 . 13000 . 14000 . 15000 . 16000 . 17000 . 18000 . 19000 . 1a000 . 1b000 . 1c000 . 1d000 . 1e000 . 1f000 . 2 . 21000 . 22000 . 23000 . 24000 . 25000 . 26000 . 27000 . 28000 . 29000 . 2a000 . 2b000 ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On Tue, Dec 13, 2016 at 07:25:29PM +0200, Konstantin Belousov wrote: > This is not what I expected. > Also, I realized that I mis-read the memory test code. It does not > obliterate memory, old content is preserved. > > Please do exactly the same testing with another patch, at the end of the > message. There could be more output, up to 256 lines. No problem. Booting... KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base= len=00099c00 SMAP type=02 base=00099c00 len=6400 SMAP type=02 base=000e len=0002 SMAP type=01 base=0010 len=7906b000 SMAP type=02 base=7916b000 len=00936000 SMAP type=04 base=79aa1000 len=00509000 SMAP type=02 base=79faa000 len=02056000 SMAP type=01 base=0001 len=001f8000 SMAP type=02 base=7c00 len=1400 SMAP type=02 base=fed1c000 len=00029000 SMAP type=02 base=ff00 len=0100 TTT1 0xf8207ff0 0xf8207fb8 10 . 0 . 1000 . 2000 . 3000 . 4000 . 5000 . 6000 . 7000 . 8000 . 9000 . a000 . b000 . c000 . d000 . e000 . f000 . 1 . 11000 . 12000 . 13000 . 14000 . 15000 . 16000 . 17000 . 18000 . 19000 . 1a000 . 1b000 . 1c000 . 1d000 . 1e000 . 1f000 . 2 . 21000 . 22000 . 23000 . 24000 . 25000 . 26000 . 27000 . 28000 . 29000 . 2a000 . 2b000 > > > > > If the patched kernel boots succesfully, or if the patched kernel > > > boots further, I will provide one more, last patch, to test. > > > > please, next time point what verion of source need to patch: vanila or > > already patched. > I usually send full patches, i.e. the patch must be applied to the clean > checkout. Patch the vanilla sources. np. ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On Tue, Dec 13, 2016 at 05:01:39PM +0200, Konstantin Belousov wrote: > > KDB: debugger backends: ddb > > KDB: current backend: ddb > > SMAP type=01 base= len=00099c00 > > SMAP type=02 base=00099c00 len=6400 > > SMAP type=02 base=000e len=0002 > > SMAP type=01 base=0010 len=7906b000 > > SMAP type=02 base=7916b000 len=00936000 > > SMAP type=04 base=79aa1000 len=00509000 > > SMAP type=02 base=79faa000 len=02056000 > > SMAP type=01 base=0001 len=001f8000 > > SMAP type=02 base=7c00 len=1400 > > SMAP type=02 base=fed1c000 len=00029000 > > SMAP type=02 base=ff00 len=0100 > > XXX1 > > YYY1 > > ZZZ1 > > Ok, please do exactly the same testing with the following patch. KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base= len=00099c00 SMAP type=02 base=00099c00 len=6400 SMAP type=02 base=000e len=0002 SMAP type=01 base=0010 len=7906b000 SMAP type=02 base=7916b000 len=00936000 SMAP type=04 base=79aa1000 len=00509000 SMAP type=02 base=79faa000 len=02056000 SMAP type=01 base=0001 len=001f8000 SMAP type=02 base=7c00 len=1400 SMAP type=02 base=fed1c000 len=00029000 SMAP type=02 base=ff00 len=0100 TTT1 0xf8207ff0 0xf8207fb8 10 > If the patched kernel boots succesfully, or if the patched kernel > boots further, I will provide one more, last patch, to test. please, next time point what verion of source need to patch: vanila or already patched. ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On Tue, Dec 13, 2016 at 05:11:14PM +0300, Slawa Olhovchenkov wrote: > On Tue, Dec 13, 2016 at 03:57:59PM +0200, Konstantin Belousov wrote: > > > On Tue, Dec 13, 2016 at 03:49:32PM +0300, Slawa Olhovchenkov wrote: > > > > Boot with NUMA enabled and interleave off. > > > > > > Already with patched kernel > > > > > > > Patch kernel with the 'if (1 || ...)' patch. > > > > Reboot, enter BIOS setup and enable interleave there. > > > > Try to boot - does it boot ? > > > > > > No. > > > > > > > If it did not booted, power machine off for 10 minutes. > > > > > > OK > > > > > > > Power it on, try to boot (with the same patched kernel). > > > > Does the machine boot now ? > > > > > > Don't boot. > > > > I am really puzzled. In other words, touching all memory causes the > > msgbuf to not hang. > > yes > > > Can you try one more experiment ? > > Take the patch below, apply it. > > >From the config where interleave is disabled, install new kernel. > > Reboot, enter BIOS setup and enable interleave. > > Set late_console to zero in loader. > > Do not enable memory test. > > Boot the patched kernel. > > Kernel must hang, according to your previous reports. > > I want to see the console log. > > Hmm. I am [already] show output from ddb, and guess kernel will be > hang at first wirte to *mbp, i.e. you don't see any in console log. > > OK, anyway I am try this pacth. KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base= len=00099c00 SMAP type=02 base=00099c00 len=6400 SMAP type=02 base=000e len=0002 SMAP type=01 base=0010 len=7906b000 SMAP type=02 base=7916b000 len=00936000 SMAP type=04 base=79aa1000 len=00509000 SMAP type=02 base=79faa000 len=02056000 SMAP type=01 base=0001 len=001f8000 SMAP type=02 base=7c00 len=1400 SMAP type=02 base=fed1c000 len=00029000 SMAP type=02 base=ff00 len=0100 XXX1 YYY1 ZZZ1 ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On Tue, Dec 13, 2016 at 03:57:59PM +0200, Konstantin Belousov wrote:
> On Tue, Dec 13, 2016 at 03:49:32PM +0300, Slawa Olhovchenkov wrote:
> > > Boot with NUMA enabled and interleave off.
> >
> > Already with patched kernel
> >
> > > Patch kernel with the 'if (1 || ...)' patch.
> > > Reboot, enter BIOS setup and enable interleave there.
> > > Try to boot - does it boot ?
> >
> > No.
> >
> > > If it did not booted, power machine off for 10 minutes.
> >
> > OK
> >
> > > Power it on, try to boot (with the same patched kernel).
> > > Does the machine boot now ?
> >
> > Don't boot.
>
> I am really puzzled. In other words, touching all memory causes the
> msgbuf to not hang.
yes
> Can you try one more experiment ?
> Take the patch below, apply it.
> >From the config where interleave is disabled, install new kernel.
> Reboot, enter BIOS setup and enable interleave.
> Set late_console to zero in loader.
> Do not enable memory test.
> Boot the patched kernel.
> Kernel must hang, according to your previous reports.
> I want to see the console log.
Hmm. I am [already] show output from ddb, and guess kernel will be
hang at first wirte to *mbp, i.e. you don't see any in console log.
OK, anyway I am try this pacth.
> diff --git a/sys/kern/subr_msgbuf.c b/sys/kern/subr_msgbuf.c
> index f275aef3b4f..1be7a629f65 100644
> --- a/sys/kern/subr_msgbuf.c
> +++ b/sys/kern/subr_msgbuf.c
> @@ -67,14 +67,19 @@ msgbuf_init(struct msgbuf *mbp, void *ptr, int size)
> mbp->msg_ptr = ptr;
> mbp->msg_size = size;
> mbp->msg_seqmod = SEQMOD(size);
> +printf("YYY1\n");
> msgbuf_clear(mbp);
> +printf("YYY2\n");
> mbp->msg_magic = MSG_MAGIC;
> mbp->msg_lastpri = -1;
> mbp->msg_flags = 0;
> +printf("YYY3\n");
> bzero(&mbp->msg_lock, sizeof(mbp->msg_lock));
> mtx_init(&mbp->msg_lock, "msgbuf", NULL, MTX_SPIN);
> +printf("YYY4\n");
> }
>
> +
> /*
> * Reinitialize a message buffer, retaining its previous contents if
> * the size and checksum are correct. If the old contents cannot be
> @@ -85,8 +90,10 @@ msgbuf_reinit(struct msgbuf *mbp, void *ptr, int size)
> {
> u_int cksum;
>
> - if (mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) {
> + if (1 || mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) {
> +printf("XXX1\n");
> msgbuf_init(mbp, ptr, size);
> +printf("XXX2\n");
> return;
> }
> mbp->msg_seqmod = SEQMOD(size);
> @@ -117,10 +124,12 @@ void
> msgbuf_clear(struct msgbuf *mbp)
> {
>
> +printf("ZZZ1\n");
> bzero(mbp->msg_ptr, mbp->msg_size);
> mbp->msg_wseq = 0;
> mbp->msg_rseq = 0;
> mbp->msg_cksum = 0;
> +printf("ZZZ2\n");
> }
>
> /*
___
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: Enabling NUMA in BIOS stop booting FreeBSD
On Tue, Dec 13, 2016 at 01:23:40PM +0200, Konstantin Belousov wrote: > On Tue, Dec 13, 2016 at 02:14:37PM +0300, Slawa Olhovchenkov wrote: > > On Tue, Dec 13, 2016 at 01:05:35PM +0200, Konstantin Belousov wrote: > > > > > On Tue, Dec 13, 2016 at 02:37:14AM +0300, Slawa Olhovchenkov wrote: > > > > On Mon, Dec 12, 2016 at 04:20:33PM -0600, A. Wilcox wrote: > > > > > > > > > >>>> Try the debugging patch below, which unconditionally disables > > > > > >>>> import of > > > > > >>>> previous buffer. To test, you would need to boot, then frob > > > > > >>>> options in > > > > > >>>> BIOS, reboot, again frob etc. > > > > > >>> > > > > > >>> still need test patch? if yes, with BIOS options? > > > > > >> Yes, please test the patch. I explained the procedure above. > > > > > > > > > > > > sorry, i don't know 'frob'. > > > > > > what exactly options combination I need test and what about memory > > > > > > test? > > > > > > > > > > > > > > > > > > > > > The idea is that when rebooting, stale memory contents remain, but are > > > > > corrupted due to interleave. > > > > > > > > > > "Frob" basically means "mess with". So apply patch, test kernel, > > > > > reboot, change NUMA option, reboot again, see if it works, and so on. > > > > > Basically repeat your test with the NUMA=on interleave=on, NUMA=off > > > > > interleave=on, etc etc. > > > > > > > > NUMA=on interleave=off booted > > > > NUMA=on interleave=on hang > > > > > > > > I think different combination whatever? > > > > > > Do you mean, that both patched kernel, and unpatched kernel with the > > > memory test enabled, hang when NUMA and interleave options enabled ? > > > > Unpatched kernel boot with the memory test enabled when NUMA and > > interleave options enabled -- I am already reported this. > > > > patched kernel with the memory test enabled boot too. ^^ > > i.e. memory test enabled allow boot in any situation. > Then what about was the statement above ? About unpatched kernel https://lists.freebsd.org/pipermail/freebsd-current/2016-December/064069.html patched and test I am test now, and wrote in previos mail ^^^ > You said that NUMA and interleave > on caused hang. Was that on the patched kernel ? patched w/o memory test > > > > > Could you enable the options, power down the machine for 10-20 minutes, > > > and try to boot ? > > > > For with kernel and bios options and boot options? > > I am have two day befor server put in production for any expirements, > > but please, be more clear in what combination need to test. > > Boot with NUMA enabled and interleave off. Already with patched kernel > Patch kernel with the 'if (1 || ...)' patch. > Reboot, enter BIOS setup and enable interleave there. > Try to boot - does it boot ? No. > If it did not booted, power machine off for 10 minutes. OK > Power it on, try to boot (with the same patched kernel). > Does the machine boot now ? Don't boot. ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On Tue, Dec 13, 2016 at 01:05:35PM +0200, Konstantin Belousov wrote: > On Tue, Dec 13, 2016 at 02:37:14AM +0300, Slawa Olhovchenkov wrote: > > On Mon, Dec 12, 2016 at 04:20:33PM -0600, A. Wilcox wrote: > > > > > >>>> Try the debugging patch below, which unconditionally disables import > > > >>>> of > > > >>>> previous buffer. To test, you would need to boot, then frob options > > > >>>> in > > > >>>> BIOS, reboot, again frob etc. > > > >>> > > > >>> still need test patch? if yes, with BIOS options? > > > >> Yes, please test the patch. I explained the procedure above. > > > > > > > > sorry, i don't know 'frob'. > > > > what exactly options combination I need test and what about memory test? > > > > > > > > > > > > > The idea is that when rebooting, stale memory contents remain, but are > > > corrupted due to interleave. > > > > > > "Frob" basically means "mess with". So apply patch, test kernel, > > > reboot, change NUMA option, reboot again, see if it works, and so on. > > > Basically repeat your test with the NUMA=on interleave=on, NUMA=off > > > interleave=on, etc etc. > > > > NUMA=on interleave=off booted > > NUMA=on interleave=on hang > > > > I think different combination whatever? > > Do you mean, that both patched kernel, and unpatched kernel with the > memory test enabled, hang when NUMA and interleave options enabled ? Unpatched kernel boot with the memory test enabled when NUMA and interleave options enabled -- I am already reported this. patched kernel with the memory test enabled boot too. i.e. memory test enabled allow boot in any situation. > Could you enable the options, power down the machine for 10-20 minutes, > and try to boot ? For with kernel and bios options and boot options? I am have two day befor server put in production for any expirements, but please, be more clear in what combination need to test. ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On Mon, Dec 12, 2016 at 04:20:33PM -0600, A. Wilcox wrote: > Try the debugging patch below, which unconditionally disables import of > previous buffer. To test, you would need to boot, then frob options in > BIOS, reboot, again frob etc. > >>> > >>> still need test patch? if yes, with BIOS options? > >> Yes, please test the patch. I explained the procedure above. > > > > sorry, i don't know 'frob'. > > what exactly options combination I need test and what about memory test? > > > > > The idea is that when rebooting, stale memory contents remain, but are > corrupted due to interleave. > > "Frob" basically means "mess with". So apply patch, test kernel, > reboot, change NUMA option, reboot again, see if it works, and so on. > Basically repeat your test with the NUMA=on interleave=on, NUMA=off > interleave=on, etc etc. NUMA=on interleave=off booted NUMA=on interleave=on hang I think different combination whatever? ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On Mon, Dec 12, 2016 at 08:36:47PM +0200, Konstantin Belousov wrote:
> On Mon, Dec 12, 2016 at 08:43:11PM +0300, Slawa Olhovchenkov wrote:
> > On Mon, Dec 12, 2016 at 07:24:18PM +0200, Konstantin Belousov wrote:
> >
> > > On Mon, Dec 12, 2016 at 08:16:34PM +0300, Slawa Olhovchenkov wrote:
> > > > On Mon, Dec 12, 2016 at 06:54:57PM +0200, Konstantin Belousov wrote:
> > > >
> > > > > On Mon, Dec 12, 2016 at 07:21:53PM +0300, Slawa Olhovchenkov wrote:
> > > > > > On Mon, Dec 12, 2016 at 04:54:18PM +0200, Konstantin Belousov wrote:
> > > > > >
> > > > > > > On Sun, Dec 11, 2016 at 11:47:09PM +0300, Slawa Olhovchenkov
> > > > > > > wrote:
> > > > > > > > Booting...
> > > > > > > > ESC[01;00H8+0x8+0xe9bdc]
> > > > > > > > KDB: debugger backends: ddb
> > > > > > > > KDB: current backend: ddb
> > > > > > > > exit from kdb_init
> > > > > > > > KDB: enter: Boot flags requested debugger
> > > > > > > > [ thread pid 0 tid 0 ]
> > > > > > > - remove any video consoles from the HEAD kernel config, i.e.
> > > > > > > sc/vt and
> > > > > > > vga/efi,
> > > > > > > - do not use boot -d,
> > > > > > > - use serial console (IPMI SOL qualifies),
> > > > > > > - set late console to 0,
> > > > > > > and show me the verbose dmesg of such boot with the BIOS options
> > > > > > > which cause troubles.
> > > > > >
> > > > > > Booting...
> > > > > > KDB: debugger backends: ddb
> > > > > > KDB: current backend: ddb
> > > > > > SMAP type=01 base= len=00099c00
> > > > > > SMAP type=02 base=00099c00 len=6400
> > > > > > SMAP type=02 base=000e len=0002
> > > > > > SMAP type=01 base=0010 len=7906b000
> > > > > > SMAP type=02 base=7916b000 len=00936000
> > > > > > SMAP type=04 base=79aa1000 len=00509000
> > > > > > SMAP type=02 base=79faa000 len=02056000
> > > > > > SMAP type=01 base=0001 len=001f8000
> > > > > > SMAP type=02 base=7c00 len=1400
> > > > > > SMAP type=02 base=fed1c000 len=00029000
> > > > > > SMAP type=02 base=ff00 len=0100
> > > > > >
> > > > > > This is all. No more.
> > > > > When you switch between variations of the NUMA enablement options, do
> > > > > you just reboot the machine or do you sometimes physically turn it
> > > > > off ?
> > > >
> > > > just reboot an 'power reset' via kvm client (memory preserved, i mean)
> > > >
> > > > > Try to enable memtest, with the hw.memtest.tests=1 loader variable.
> > > > > Does it change things ?
> > > >
> > > > System booted, dmesg is http://zxy.spb.ru/dmesg.numa
> > > I suspect now the reversed situation could take place, the non-interleaved
> > > option would cause hang.
> >
> > No, also booted, dmesg http://zxy.spb.ru/dmesg.numa-ninter
> I mean, it could hang if memory testing is not enabled.
realy? system boot w/o memory testing when NUMA ON and interleave OFF:
I am already report about boot after off interleave.
> >
> > > My current guess is that memory content is preserved but swizzled by
> > > the cache line sized chunks. So that the msgbuf header, left after the
> > > previous boot, looks correct while the real buffer content is shuffled.
> > >
> > > Try the debugging patch below, which unconditionally disables import of
> > > previous buffer. To test, you would need to boot, then frob options in
> > > BIOS, reboot, again frob etc.
> >
> > still need test patch? if yes, with BIOS options?
> Yes, please test the patch. I explained the procedure above.
sorry, i don't know 'frob'.
what exactly options combination I need test and what about memory test?
> >
> > > diff --git a/sys/kern/subr_msgbuf.c b/sys/kern/subr_msgbuf.c
> > > index f275aef3b4f..d45ef502204 100644
> > > --- a/sys/kern/subr_msgbuf.c
> > > +++ b/sys/kern/subr_msgbuf.c
> > > @@ -85,7 +85,7 @@ msgbuf_reinit(struct msgbuf *mbp, void *ptr, int size)
> > > {
> > > u_int cksum;
> > >
> > > - if (mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) {
> > > + if (1 || mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) {
> > > msgbuf_init(mbp, ptr, size);
> > > return;
> > > }
___
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: Enabling NUMA in BIOS stop booting FreeBSD
On Mon, Dec 12, 2016 at 07:24:18PM +0200, Konstantin Belousov wrote:
> On Mon, Dec 12, 2016 at 08:16:34PM +0300, Slawa Olhovchenkov wrote:
> > On Mon, Dec 12, 2016 at 06:54:57PM +0200, Konstantin Belousov wrote:
> >
> > > On Mon, Dec 12, 2016 at 07:21:53PM +0300, Slawa Olhovchenkov wrote:
> > > > On Mon, Dec 12, 2016 at 04:54:18PM +0200, Konstantin Belousov wrote:
> > > >
> > > > > On Sun, Dec 11, 2016 at 11:47:09PM +0300, Slawa Olhovchenkov wrote:
> > > > > > Booting...
> > > > > > ESC[01;00H8+0x8+0xe9bdc]
> > > > > > KDB: debugger backends: ddb
> > > > > > KDB: current backend: ddb
> > > > > > exit from kdb_init
> > > > > > KDB: enter: Boot flags requested debugger
> > > > > > [ thread pid 0 tid 0 ]
> > > > > - remove any video consoles from the HEAD kernel config, i.e. sc/vt
> > > > > and
> > > > > vga/efi,
> > > > > - do not use boot -d,
> > > > > - use serial console (IPMI SOL qualifies),
> > > > > - set late console to 0,
> > > > > and show me the verbose dmesg of such boot with the BIOS options
> > > > > which cause troubles.
> > > >
> > > > Booting...
> > > > KDB: debugger backends: ddb
> > > > KDB: current backend: ddb
> > > > SMAP type=01 base= len=00099c00
> > > > SMAP type=02 base=00099c00 len=6400
> > > > SMAP type=02 base=000e len=0002
> > > > SMAP type=01 base=0010 len=7906b000
> > > > SMAP type=02 base=7916b000 len=00936000
> > > > SMAP type=04 base=79aa1000 len=00509000
> > > > SMAP type=02 base=79faa000 len=02056000
> > > > SMAP type=01 base=0001 len=001f8000
> > > > SMAP type=02 base=7c00 len=1400
> > > > SMAP type=02 base=fed1c000 len=00029000
> > > > SMAP type=02 base=ff00 len=0100
> > > >
> > > > This is all. No more.
> > > When you switch between variations of the NUMA enablement options, do
> > > you just reboot the machine or do you sometimes physically turn it off ?
> >
> > just reboot an 'power reset' via kvm client (memory preserved, i mean)
> >
> > > Try to enable memtest, with the hw.memtest.tests=1 loader variable.
> > > Does it change things ?
> >
> > System booted, dmesg is http://zxy.spb.ru/dmesg.numa
> I suspect now the reversed situation could take place, the non-interleaved
> option would cause hang.
No, also booted, dmesg http://zxy.spb.ru/dmesg.numa-ninter
> My current guess is that memory content is preserved but swizzled by
> the cache line sized chunks. So that the msgbuf header, left after the
> previous boot, looks correct while the real buffer content is shuffled.
>
> Try the debugging patch below, which unconditionally disables import of
> previous buffer. To test, you would need to boot, then frob options in
> BIOS, reboot, again frob etc.
still need test patch? if yes, with BIOS options?
> diff --git a/sys/kern/subr_msgbuf.c b/sys/kern/subr_msgbuf.c
> index f275aef3b4f..d45ef502204 100644
> --- a/sys/kern/subr_msgbuf.c
> +++ b/sys/kern/subr_msgbuf.c
> @@ -85,7 +85,7 @@ msgbuf_reinit(struct msgbuf *mbp, void *ptr, int size)
> {
> u_int cksum;
>
> - if (mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) {
> + if (1 || mbp->msg_magic != MSG_MAGIC || mbp->msg_size != size) {
> msgbuf_init(mbp, ptr, size);
> return;
> }
___
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: Enabling NUMA in BIOS stop booting FreeBSD
On Mon, Dec 12, 2016 at 06:54:57PM +0200, Konstantin Belousov wrote: > On Mon, Dec 12, 2016 at 07:21:53PM +0300, Slawa Olhovchenkov wrote: > > On Mon, Dec 12, 2016 at 04:54:18PM +0200, Konstantin Belousov wrote: > > > > > On Sun, Dec 11, 2016 at 11:47:09PM +0300, Slawa Olhovchenkov wrote: > > > > Booting... > > > > ESC[01;00H8+0x8+0xe9bdc] > > > > KDB: debugger backends: ddb > > > > KDB: current backend: ddb > > > > exit from kdb_init > > > > KDB: enter: Boot flags requested debugger > > > > [ thread pid 0 tid 0 ] > > > - remove any video consoles from the HEAD kernel config, i.e. sc/vt and > > > vga/efi, > > > - do not use boot -d, > > > - use serial console (IPMI SOL qualifies), > > > - set late console to 0, > > > and show me the verbose dmesg of such boot with the BIOS options > > > which cause troubles. > > > > Booting... > > KDB: debugger backends: ddb > > KDB: current backend: ddb > > SMAP type=01 base= len=00099c00 > > SMAP type=02 base=00099c00 len=6400 > > SMAP type=02 base=000e len=0002 > > SMAP type=01 base=0010 len=7906b000 > > SMAP type=02 base=7916b000 len=00936000 > > SMAP type=04 base=79aa1000 len=00509000 > > SMAP type=02 base=79faa000 len=02056000 > > SMAP type=01 base=0001 len=001f8000 > > SMAP type=02 base=7c00 len=1400 > > SMAP type=02 base=fed1c000 len=00029000 > > SMAP type=02 base=ff00 len=0100 > > > > This is all. No more. > When you switch between variations of the NUMA enablement options, do > you just reboot the machine or do you sometimes physically turn it off ? just reboot an 'power reset' via kvm client (memory preserved, i mean) > Try to enable memtest, with the hw.memtest.tests=1 loader variable. > Does it change things ? System booted, dmesg is http://zxy.spb.ru/dmesg.numa # sysctl vm.ndomains vm.default_policy vm.phys_locality vm.phys_segs vm.ndomains: 1 vm.default_policy: rr sysctl: unknown oid 'vm.phys_locality' vm.phys_segs: SEGMENT 0: start: 0x1 end: 0x96000 domain:0 free list: 0x80caabc0 SEGMENT 1: start: 0x10 end: 0x20 domain:0 free list: 0x80caabc0 SEGMENT 2: start: 0x15c1000 end: 0x15ed000 domain:0 free list: 0x80caa950 SEGMENT 3: start: 0x15ee000 end: 0x7916b000 domain:0 free list: 0x80caa950 SEGMENT 4: start: 0x1 end: 0x1f6d8ae000 domain:0 free list: 0x80caa6e0 ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On Mon, Dec 12, 2016 at 04:54:18PM +0200, Konstantin Belousov wrote: > On Sun, Dec 11, 2016 at 11:47:09PM +0300, Slawa Olhovchenkov wrote: > > Booting... > > ESC[01;00H8+0x8+0xe9bdc] > > KDB: debugger backends: ddb > > KDB: current backend: ddb > > exit from kdb_init > > KDB: enter: Boot flags requested debugger > > [ thread pid 0 tid 0 ] > - remove any video consoles from the HEAD kernel config, i.e. sc/vt and > vga/efi, > - do not use boot -d, > - use serial console (IPMI SOL qualifies), > - set late console to 0, > and show me the verbose dmesg of such boot with the BIOS options > which cause troubles. Booting... KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base= len=00099c00 SMAP type=02 base=00099c00 len=6400 SMAP type=02 base=000e len=0002 SMAP type=01 base=0010 len=7906b000 SMAP type=02 base=7916b000 len=00936000 SMAP type=04 base=79aa1000 len=00509000 SMAP type=02 base=79faa000 len=02056000 SMAP type=01 base=0001 len=001f8000 SMAP type=02 base=7c00 len=1400 SMAP type=02 base=fed1c000 len=00029000 SMAP type=02 base=ff00 len=0100 This is all. No more. > > > Hm, might be also show the output of the 'smap' and 'memmap' output from > > > the loader. If any of them worked, could be useful to see the same output > > > with the NUMA option disabled as well. > > > > NUMA disabled: > > OK smap > > SMAP type=01 base= len=00099c00 attr=01 > > SMAP type=02 base=00099c00 len=6400 attr=01 > > SMAP type=02 base=000e len=0002 attr=01 > > SMAP type=01 base=0010 len=7906b000 attr=01 > > SMAP type=02 base=7916b000 len=0093a000 attr=01 > > SMAP type=04 base=79aa5000 len=00505000 attr=01 > > SMAP type=02 base=79faa000 len=02056000 attr=01 > > SMAP type=01 base=0001 len=001f8000 attr=01 > > SMAP type=02 base=7c00 len=1400 attr=01 > > SMAP type=02 base=fed1c000 len=00029000 attr=01 > > SMAP type=02 base=ff00 len=0100 attr=01 > > NUMA enabled: > > OK smap > > SMAP type=01 base= len=00099c00 attr=01 > > SMAP type=02 base=00099c00 len=6400 attr=01 > > SMAP type=02 base=000e len=0002 attr=01 > > SMAP type=01 base=0010 len=7906b000 attr=01 > > SMAP type=04 base=79aa1000 len=00509000 attr=01 > > SMAP type=02 base=79faa000 len=02056000 attr=01 > > SMAP type=01 base=0001 len=001f8000 attr=01 > > SMAP type=02 base=7c00 len=1400 attr=01 > > SMAP type=02 base=fed1c000 len=00029000 attr=01 > > SMAP type=02 base=ff00 len=0100 attr=01 > > OK memmap > > memmap not found > > I.e. you use CMS in BIOS/legacy BIOS boot, right ? legacy BIOS boot, yes > Can you double-check that the smap output is indeed same for all three > cases (no-NUMA, NUMA without <4G interleave, NUMA with 4G interleave) ? NUMA=ON 4G interleave=ON SMAP type=01 base= len=00099c00 attr=01 SMAP type=02 base=00099c00 len=6400 attr=01 SMAP type=02 base=000e len=0002 attr=01 SMAP type=01 base=0010 len=7906b000 attr=01 SMAP type=02 base=7916b000 len=00936000 attr=01 SMAP type=04 base=79aa1000 len=00509000 attr=01 SMAP type=02 base=79faa000 len=02056000 attr=01 SMAP type=01 base=0001 len=001f8000 attr=01 SMAP type=02 base=7c00 len=1400 attr=01 SMAP type=02 base=fed1c000 len=00029000 attr=01 SMAP type=02 base=ff00 len=0100 attr=01 NUMA=ON 4G interleave=OFF SMAP type=01 base= len=00099c00 attr=01 SMAP type=02 base=00099c00 len=6400 attr=01 SMAP type=02 base=000e len=0002 attr=01 SMAP type=01 base=0010 len=7906b000 attr=01 SMAP type=02 base=7916b000 len=00936000 attr=01 SM
Re: Enabling NUMA in BIOS stop booting FreeBSD
On Mon, Dec 12, 2016 at 01:46:21AM +0300, Slawa Olhovchenkov wrote: > > > > > > Can you show the verbose dmesg up to the failure point ? > > > > > > In particular, the SMAP lines should be relevant. > > > > > > > > > > KDB: debugger backends: ddb > > > > > KDB: current backend: ddb > > > > > exit from kdb_init > > > > > KDB: enter: Boot flags requested debugger > > > > > [ thread pid 0 tid 0 ] > > > > > Stopped at 0x805361eb = kdb_enter+0x3b:movq > > > > > $0,0x80dcef20 = kdb_why Hang at boot is result of combination next two BIOS setting: NUMA enabled Socket Interleave below 4G enabled (memory options) Disabling any allow boot. ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On Mon, Dec 12, 2016 at 12:15:53AM +0300, Slawa Olhovchenkov wrote: > On Sun, Dec 11, 2016 at 11:47:09PM +0300, Slawa Olhovchenkov wrote: > > > On Sun, Dec 11, 2016 at 10:06:54PM +0200, Konstantin Belousov wrote: > > > > > On Sun, Dec 11, 2016 at 10:45:59PM +0300, Slawa Olhovchenkov wrote: > > > > On Sun, Dec 11, 2016 at 09:26:56PM +0200, Konstantin Belousov wrote: > > > > > > > > > On Sun, Dec 11, 2016 at 10:16:26PM +0300, Slawa Olhovchenkov wrote: > > > > > > On Sun, Dec 11, 2016 at 09:21:11PM +0300, Slawa Olhovchenkov wrote: > > > > > > > > > > > > > On Sat, Nov 26, 2016 at 05:57:47PM +0200, Konstantin Belousov > > > > > > > wrote: > > > > > > > > > > > > > > > On Sat, Nov 26, 2016 at 12:21:24PM +0300, Slawa Olhovchenkov > > > > > > > > wrote: > > > > > > > > > I am try to enable NUMA in bios and can't boot FreeBSD. > > > > > > > > > Boot stoped after next messages: > > > > > > > > > > > > > > > > > > === > > > > > > > > > Booting... > > > > > > > > > KDB: debugger backends: ddb > > > > > > > > > KDB: current backend: ddb > > > > > > > > So at least the hammer_time() has a chance to initialize the > > > > > > > > console. > > > > > > > > Do you have serial console ? Set the loader tunable > > > > > > > > debug.late_console > > > > > > > > to 1 and see if any NMI reaction appear. > > > > > > > > > > > > > > > > > === > > > > > > > > > > > > > > > > > > This is verbose boot. > > > > > > > > > No reaction to ~^B, NMI. > > > > > > > > > > > > > > > > > > Same for head and 10.3-RELEASE. > > > > > > > > > > > > > > > > > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. > > > > > > > > Is there a BIOS option for 'on-chip cluster' or 'HPC computing' > > > > > > > > ? > > > > > > > > What if you try to frob it ? > > > > > > > > > > > > > > > > > > > > > > > > > > On slight different hardware > > > > > > > > > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) > > > > > > > > > 10.3 boot ok w/ BIOS NUMA enabled. > > > > > > > > > > > > > > > > I think the only way to debug this is to add printf() lines to > > > > > > > > hammer_time() > > > > > > > > to see where does it break. Note that amd64_kdb_init() call > > > > > > > > succeeded, > > > > > > > > so you can start bisect the code from there. > > > > > > > > > > > > > > > > > > > > > > Hang in next two lines: > > > > > > > > > > > > > > msgbufinit(msgbufp, msgbufsize); > > > > > > > fpuinit(); > > > > > > > > > > Can you show the verbose dmesg up to the failure point ? > > > > > In particular, the SMAP lines should be relevant. > > > > > > > > KDB: debugger backends: ddb > > > > KDB: current backend: ddb > > > > exit from kdb_init > > > > KDB: enter: Boot flags requested debugger > > > > [ thread pid 0 tid 0 ] > > > > Stopped at 0x805361eb = kdb_enter+0x3b:movq > > > > $0,0x80dcef20 = kdb_why > > > > > > > > No SMAP print, boot_verbose enabled. > > > The log above shows that you used boot -d. What are the pristine boot > > > messages, with debug.late_console set to 0, of course ? > > > > This is stable/11, no debug.late_console. > > Booting HEAD: > > panic: pmap_mapdev_attr: too many preinit mappings > cpuid = 0 > KDB: stack backtrace: > #0 0x80535197 at ??+0 > #1 0x804eb0f2 at ??+0 > #2 0x804eaf63 at ??+0 > #3 0x807b5995 at ??+0 > #4 0x808479ca at ??+0 > #5 0x804079ea at ??+0 > #6 0x8040bb44 at ??+0 > #7 0x8047e178 at ??+0 > #8 0x807a47c3 at ??+0 > #9 0x8028f0a4 at ??+0 > Uptime: 1s Like this is debug.late_console=0 issuse. Same panic with NUMA disabled. Only set debug.late_console=1 allow to boot ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On Sun, Dec 11, 2016 at 11:47:09PM +0300, Slawa Olhovchenkov wrote: > On Sun, Dec 11, 2016 at 10:06:54PM +0200, Konstantin Belousov wrote: > > > On Sun, Dec 11, 2016 at 10:45:59PM +0300, Slawa Olhovchenkov wrote: > > > On Sun, Dec 11, 2016 at 09:26:56PM +0200, Konstantin Belousov wrote: > > > > > > > On Sun, Dec 11, 2016 at 10:16:26PM +0300, Slawa Olhovchenkov wrote: > > > > > On Sun, Dec 11, 2016 at 09:21:11PM +0300, Slawa Olhovchenkov wrote: > > > > > > > > > > > On Sat, Nov 26, 2016 at 05:57:47PM +0200, Konstantin Belousov wrote: > > > > > > > > > > > > > On Sat, Nov 26, 2016 at 12:21:24PM +0300, Slawa Olhovchenkov > > > > > > > wrote: > > > > > > > > I am try to enable NUMA in bios and can't boot FreeBSD. > > > > > > > > Boot stoped after next messages: > > > > > > > > > > > > > > > > === > > > > > > > > Booting... > > > > > > > > KDB: debugger backends: ddb > > > > > > > > KDB: current backend: ddb > > > > > > > So at least the hammer_time() has a chance to initialize the > > > > > > > console. > > > > > > > Do you have serial console ? Set the loader tunable > > > > > > > debug.late_console > > > > > > > to 1 and see if any NMI reaction appear. > > > > > > > > > > > > > > > === > > > > > > > > > > > > > > > > This is verbose boot. > > > > > > > > No reaction to ~^B, NMI. > > > > > > > > > > > > > > > > Same for head and 10.3-RELEASE. > > > > > > > > > > > > > > > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. > > > > > > > Is there a BIOS option for 'on-chip cluster' or 'HPC computing' ? > > > > > > > What if you try to frob it ? > > > > > > > > > > > > > > > > > > > > > > > On slight different hardware > > > > > > > > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) > > > > > > > > 10.3 boot ok w/ BIOS NUMA enabled. > > > > > > > > > > > > > > I think the only way to debug this is to add printf() lines to > > > > > > > hammer_time() > > > > > > > to see where does it break. Note that amd64_kdb_init() call > > > > > > > succeeded, > > > > > > > so you can start bisect the code from there. > > > > > > > > > > > > > > > > > > > Hang in next two lines: > > > > > > > > > > > > msgbufinit(msgbufp, msgbufsize); > > > > > > fpuinit(); > > > > > > > > Can you show the verbose dmesg up to the failure point ? > > > > In particular, the SMAP lines should be relevant. > > > > > > KDB: debugger backends: ddb > > > KDB: current backend: ddb > > > exit from kdb_init > > > KDB: enter: Boot flags requested debugger > > > [ thread pid 0 tid 0 ] > > > Stopped at 0x805361eb = kdb_enter+0x3b:movq > > > $0,0x80dcef20 = kdb_why > > > > > > No SMAP print, boot_verbose enabled. > > The log above shows that you used boot -d. What are the pristine boot > > messages, with debug.late_console set to 0, of course ? > > This is stable/11, no debug.late_console. Booting HEAD: panic: pmap_mapdev_attr: too many preinit mappings cpuid = 0 KDB: stack backtrace: #0 0x80535197 at ??+0 #1 0x804eb0f2 at ??+0 #2 0x804eaf63 at ??+0 #3 0x807b5995 at ??+0 #4 0x808479ca at ??+0 #5 0x804079ea at ??+0 #6 0x8040bb44 at ??+0 #7 0x8047e178 at ??+0 #8 0x807a47c3 at ??+0 #9 0x8028f0a4 at ??+0 Uptime: 1s > With ANSI ESC, captured from SOL: > > ESC[01;00HType '?' for a /boot/kernel.VSTREAM/opensolaris.ko size 0xcb10 at > 0x13d3000 > ESC[01;00HOK smap > /boot/kernel.VSTREAM/if_igb.ko size 0x69f10 at 0x13e > ESC[02;00HSMAP type=02 base=0009ESC[01;00HSMAP type=01 > base= len=00099c00 attr=01 > ESC[02;00HSMAP type=02 base=00099c00 len=0
Re: Enabling NUMA in BIOS stop booting FreeBSD
On Sun, Dec 11, 2016 at 10:06:54PM +0200, Konstantin Belousov wrote: > On Sun, Dec 11, 2016 at 10:45:59PM +0300, Slawa Olhovchenkov wrote: > > On Sun, Dec 11, 2016 at 09:26:56PM +0200, Konstantin Belousov wrote: > > > > > On Sun, Dec 11, 2016 at 10:16:26PM +0300, Slawa Olhovchenkov wrote: > > > > On Sun, Dec 11, 2016 at 09:21:11PM +0300, Slawa Olhovchenkov wrote: > > > > > > > > > On Sat, Nov 26, 2016 at 05:57:47PM +0200, Konstantin Belousov wrote: > > > > > > > > > > > On Sat, Nov 26, 2016 at 12:21:24PM +0300, Slawa Olhovchenkov wrote: > > > > > > > I am try to enable NUMA in bios and can't boot FreeBSD. > > > > > > > Boot stoped after next messages: > > > > > > > > > > > > > > === > > > > > > > Booting... > > > > > > > KDB: debugger backends: ddb > > > > > > > KDB: current backend: ddb > > > > > > So at least the hammer_time() has a chance to initialize the > > > > > > console. > > > > > > Do you have serial console ? Set the loader tunable > > > > > > debug.late_console > > > > > > to 1 and see if any NMI reaction appear. > > > > > > > > > > > > > === > > > > > > > > > > > > > > This is verbose boot. > > > > > > > No reaction to ~^B, NMI. > > > > > > > > > > > > > > Same for head and 10.3-RELEASE. > > > > > > > > > > > > > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. > > > > > > Is there a BIOS option for 'on-chip cluster' or 'HPC computing' ? > > > > > > What if you try to frob it ? > > > > > > > > > > > > > > > > > > > > On slight different hardware > > > > > > > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) > > > > > > > 10.3 boot ok w/ BIOS NUMA enabled. > > > > > > > > > > > > I think the only way to debug this is to add printf() lines to > > > > > > hammer_time() > > > > > > to see where does it break. Note that amd64_kdb_init() call > > > > > > succeeded, > > > > > > so you can start bisect the code from there. > > > > > > > > > > > > > > > > Hang in next two lines: > > > > > > > > > > msgbufinit(msgbufp, msgbufsize); > > > > > fpuinit(); > > > > > > Can you show the verbose dmesg up to the failure point ? > > > In particular, the SMAP lines should be relevant. > > > > KDB: debugger backends: ddb > > KDB: current backend: ddb > > exit from kdb_init > > KDB: enter: Boot flags requested debugger > > [ thread pid 0 tid 0 ] > > Stopped at 0x805361eb = kdb_enter+0x3b:movq > > $0,0x80dcef20 = kdb_why > > > > No SMAP print, boot_verbose enabled. > The log above shows that you used boot -d. What are the pristine boot > messages, with debug.late_console set to 0, of course ? This is stable/11, no debug.late_console. With ANSI ESC, captured from SOL: ESC[01;00HType '?' for a /boot/kernel.VSTREAM/opensolaris.ko size 0xcb10 at 0x13d3000 ESC[01;00HOK smap /boot/kernel.VSTREAM/if_igb.ko size 0x69f10 at 0x13e ESC[02;00HSMAP type=02 base=0009ESC[01;00HSMAP type=01 base= len=00099c00 attr=01 ESC[02;00HSMAP type=02 base=00099c00 len=6400 attr=01 ESC[03;00Hcan't find 'if_ixgbe' ESC[01;00H/boot/kernel.VSTREAM/if_lagg.ko size 0x150c0 at 0x144a000 ESC[01;00HSMAP type=02 base=000e/boot/kernel.VSTREAM/ukbd.ko size 0xe280 at 0x146 loading required moduleESC[01;00H 'usb'^MSMAP type=01 base=7916b000 len=00936000 attr =01 ESC[02;00H/boot/kernel.VSTREAM/usb.ko size 0x45d40 at 0x146f000 ESC[01;00HSMAP type=04 base=79aa1000 len=00/boot/kernel.VSTREAM/umass.ko size 0xaa10 at 0x14b5000 ESC[01;00HSMAP type=02 base=79faa000 len=02056000 attr=01 ESC[02;00HSMAP type=01 ba/boot/kernel.VSTREAM/accf_http.ko size 0x2710 at 0x14c ESC[01;00HSMAP type=01 base=0001 len=001f8000 attr=01 /boot/kernel.VSTREAM/
Re: Enabling NUMA in BIOS stop booting FreeBSD
On Sun, Dec 11, 2016 at 09:26:56PM +0200, Konstantin Belousov wrote: > On Sun, Dec 11, 2016 at 10:16:26PM +0300, Slawa Olhovchenkov wrote: > > On Sun, Dec 11, 2016 at 09:21:11PM +0300, Slawa Olhovchenkov wrote: > > > > > On Sat, Nov 26, 2016 at 05:57:47PM +0200, Konstantin Belousov wrote: > > > > > > > On Sat, Nov 26, 2016 at 12:21:24PM +0300, Slawa Olhovchenkov wrote: > > > > > I am try to enable NUMA in bios and can't boot FreeBSD. > > > > > Boot stoped after next messages: > > > > > > > > > > === > > > > > Booting... > > > > > KDB: debugger backends: ddb > > > > > KDB: current backend: ddb > > > > So at least the hammer_time() has a chance to initialize the console. > > > > Do you have serial console ? Set the loader tunable debug.late_console > > > > to 1 and see if any NMI reaction appear. > > > > > > > > > === > > > > > > > > > > This is verbose boot. > > > > > No reaction to ~^B, NMI. > > > > > > > > > > Same for head and 10.3-RELEASE. > > > > > > > > > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. > > > > Is there a BIOS option for 'on-chip cluster' or 'HPC computing' ? > > > > What if you try to frob it ? > > > > > > > > > > > > > > On slight different hardware > > > > > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) > > > > > 10.3 boot ok w/ BIOS NUMA enabled. > > > > > > > > I think the only way to debug this is to add printf() lines to > > > > hammer_time() > > > > to see where does it break. Note that amd64_kdb_init() call succeeded, > > > > so you can start bisect the code from there. > > > > > > > > > > Hang in next two lines: > > > > > > msgbufinit(msgbufp, msgbufsize); > > > fpuinit(); > > Can you show the verbose dmesg up to the failure point ? > In particular, the SMAP lines should be relevant. KDB: debugger backends: ddb KDB: current backend: ddb exit from kdb_init KDB: enter: Boot flags requested debugger [ thread pid 0 tid 0 ] Stopped at 0x805361eb = kdb_enter+0x3b:movq $0,0x80dcef20 = kdb_why No SMAP print, boot_verbose enabled. ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On Sun, Dec 11, 2016 at 09:21:11PM +0300, Slawa Olhovchenkov wrote: > On Sat, Nov 26, 2016 at 05:57:47PM +0200, Konstantin Belousov wrote: > > > On Sat, Nov 26, 2016 at 12:21:24PM +0300, Slawa Olhovchenkov wrote: > > > I am try to enable NUMA in bios and can't boot FreeBSD. > > > Boot stoped after next messages: > > > > > > === > > > Booting... > > > KDB: debugger backends: ddb > > > KDB: current backend: ddb > > So at least the hammer_time() has a chance to initialize the console. > > Do you have serial console ? Set the loader tunable debug.late_console > > to 1 and see if any NMI reaction appear. > > > > > === > > > > > > This is verbose boot. > > > No reaction to ~^B, NMI. > > > > > > Same for head and 10.3-RELEASE. > > > > > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. > > Is there a BIOS option for 'on-chip cluster' or 'HPC computing' ? > > What if you try to frob it ? > > > > > > > > On slight different hardware > > > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) > > > 10.3 boot ok w/ BIOS NUMA enabled. > > > > I think the only way to debug this is to add printf() lines to hammer_time() > > to see where does it break. Note that amd64_kdb_init() call succeeded, > > so you can start bisect the code from there. > > > > Hang in next two lines: > > msgbufinit(msgbufp, msgbufsize); > fpuinit(); [ thread pid 0 tid 0 ] Stopped at 0x80538c10 = msgbuf_reinit: pushq %rbp db> [ thread pid 0 tid 0 ] Stopped at 0x80538c11 = msgbuf_reinit+0x1: movq%rsp,%rbp db> [ thread pid 0 tid 0 ] Stopped at 0x80538c14 = msgbuf_reinit+0x4: pushq %r14 db> [ thread pid 0 tid 0 ] Stopped at 0x80538c16 = msgbuf_reinit+0x6: pushq %rbx db> [ thread pid 0 tid 0 ] Stopped at 0x80538c17 = msgbuf_reinit+0x7: movl%edx,%r8d db> [ thread pid 0 tid 0 ] Stopped at 0x80538c1a = msgbuf_reinit+0xa: movq%rdi,%r14 db> [ thread pid 0 tid 0 ] Stopped at 0x80538c1d = msgbuf_reinit+0xd: movq0x8(%r14),%rax db> [ thread pid 0 tid 0 ] Stopped at 0x80538c21 = msgbuf_reinit+0x11:cmpl $0x63062,%eax db> [ thread pid 0 tid 0 ] Stopped at 0x80538c26 = msgbuf_reinit+0x16:jnz 0x80538d37 = msgbuf_reinit+0x127 db> [ thread pid 0 tid 0 ] Stopped at 0x80538d37 = msgbuf_reinit+0x127: movq %rsi,(%r14) db> [ thread pid 0 tid 0 ] Stopped atKDB: reentering KDB: stack backtrace: db_trace_self_wrapper() at 0x8032de4b = db_trace_self_wrapper+0x2b/frame 0x80bb9370 kdb_reenter() at 0x8053670e = kdb_reenter+0x8e/frame 0x80bb9420 trap() at 0x807c0a31 = trap+0x51/frame 0x80bb9630 calltrap() at 0x807a5011 = calltrap+0x8/frame 0x80bb9630 --- trap 0x1c, rip = 0x8032db33, rsp = 0x80bb9700, rbp = 0x80bb9730 --- X_db_search_symbol() at 0x8032db33 = X_db_search_symbol+0x53/frame 0x80bb9730 db_printsym() at 0x80330f30 = db_printsym+0x70/frame 0x80bb97a0 db_print_loc_and_inst() at 0x8032c0a3 = db_print_loc_and_inst+0x13/frame 0x80bb97c0 db_trap() at 0x8032df7f = db_trap+0xcf/frame 0x80bb9850 kdb_trap() at 0x80536b43 = kdb_trap+0x193/frame 0x80bb98e0 trap() at 0x807c0c3c = trap+0x25c/frame 0x80bb9af0 calltrap() at 0x807a5011 = calltrap+0x8/frame 0x80bb9af0 --- trap 0xa, rip = 0x80538d3a, rsp = 0x80bb9bc0, rbp = 0x80bb9bd0 --- msgbuf_reinit() at 0x80538d3a = msgbuf_reinit+0x12a/frame 0x80bb9bd0 msgbufinit() at 0x8053dd31 = msgbufinit+0x21/frame 0x80bb9be0 hammer_time() at 0x807aa5fa = hammer_time+0xf8a/frame 0x80bba070 btext() at 0x8028fc34 = btext+0x24 db> show registers cs0x20 ds0x28 es0x28 fs0x28 gs0x28 ss0x28 rax 0x rcx 0 rdx0x17fb8 rbx0x7 rsp 0x80bb9bc0 __stop_set_pcpu+0xb48 rbp 0x80bb9bd0 __stop_set_pcpu+0xb58 rsi 0xf8207ffe8000 rdi 0xf8207fb8 r8 0x17fb8 r9 0x80bb9818 __stop_set_pcpu+0x7a0 r10 0 r11 0 r12 0 r13 0x208000 r14 0xf8207fb8 r15 0x8180 rip
Re: Enabling NUMA in BIOS stop booting FreeBSD
On Sat, Nov 26, 2016 at 05:57:47PM +0200, Konstantin Belousov wrote: > On Sat, Nov 26, 2016 at 12:21:24PM +0300, Slawa Olhovchenkov wrote: > > I am try to enable NUMA in bios and can't boot FreeBSD. > > Boot stoped after next messages: > > > > === > > Booting... > > KDB: debugger backends: ddb > > KDB: current backend: ddb > So at least the hammer_time() has a chance to initialize the console. > Do you have serial console ? Set the loader tunable debug.late_console > to 1 and see if any NMI reaction appear. > > > === > > > > This is verbose boot. > > No reaction to ~^B, NMI. > > > > Same for head and 10.3-RELEASE. > > > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. > Is there a BIOS option for 'on-chip cluster' or 'HPC computing' ? > What if you try to frob it ? > > > > > On slight different hardware > > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) > > 10.3 boot ok w/ BIOS NUMA enabled. > > I think the only way to debug this is to add printf() lines to hammer_time() > to see where does it break. Note that amd64_kdb_init() call succeeded, > so you can start bisect the code from there. > Hang in next two lines: msgbufinit(msgbufp, msgbufsize); fpuinit(); ___ 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: How to load kernel module automatic?
On Tue, Dec 06, 2016 at 06:53:03AM -0800, Navdeep Parhar wrote:
> On Tue, Dec 06, 2016 at 05:43:38PM +0300, Slawa Olhovchenkov wrote:
> > On Tue, Dec 06, 2016 at 06:41:14AM -0800, Navdeep Parhar wrote:
> >
> > > On Tue, Dec 06, 2016 at 05:34:56PM +0300, Slawa Olhovchenkov wrote:
> > > > On Tue, Dec 06, 2016 at 06:25:44AM -0800, Navdeep Parhar wrote:
> > > >
> > > > > On Tue, Dec 06, 2016 at 02:47:15PM +0300, Slawa Olhovchenkov wrote:
> > > > > > Now I am try to update fw in chelsio card.
> > > > > > Firmware can't be updated if card was running (interface go to UP).
> > > > > > I am try to unload if_cxgbe module, check module unloaded... and
> > > > > > after
> > > > > > short time see module loaded again!
> > > > > > How is this possible?
> > > > >
> > > > > Something is running "ifconfig cxgbe|cxl|cc" on your system. ifconfig
> > > > > can figure out the name of the module from the name of the ifnet and
> > > > > will kldload it if it isn't in the kernel already.
> > > >
> > > > What is 'something'?
> > >
> > > A script that's running via devd or some other mechanism.
> >
> > Its not clear to me what exact event cause devd start such script.
>
> Doesn't have to be devd. Could be any automated script running
> ifconfig. Leave this running and see if ifconfig is ever called with
No any automated scripts.
> (cxgbe|cxl|cc) as parameter. If it is then that's what's loading
> cxgbe(4) automatically.
>
> dtrace -n 'proc:::exec-success /execname == "ifconfig"/
> {trace(curpsinfo->pr_psargs);}
ok, i am do it tomorrow.
___
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: How to load kernel module automatic?
On Tue, Dec 06, 2016 at 06:41:14AM -0800, Navdeep Parhar wrote: > On Tue, Dec 06, 2016 at 05:34:56PM +0300, Slawa Olhovchenkov wrote: > > On Tue, Dec 06, 2016 at 06:25:44AM -0800, Navdeep Parhar wrote: > > > > > On Tue, Dec 06, 2016 at 02:47:15PM +0300, Slawa Olhovchenkov wrote: > > > > Now I am try to update fw in chelsio card. > > > > Firmware can't be updated if card was running (interface go to UP). > > > > I am try to unload if_cxgbe module, check module unloaded... and after > > > > short time see module loaded again! > > > > How is this possible? > > > > > > Something is running "ifconfig cxgbe|cxl|cc" on your system. ifconfig > > > can figure out the name of the module from the name of the ifnet and > > > will kldload it if it isn't in the kernel already. > > > > What is 'something'? > > A script that's running via devd or some other mechanism. Its not clear to me what exact event cause devd start such script. ___ 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: How to load kernel module automatic?
On Tue, Dec 06, 2016 at 06:25:44AM -0800, Navdeep Parhar wrote: > On Tue, Dec 06, 2016 at 02:47:15PM +0300, Slawa Olhovchenkov wrote: > > Now I am try to update fw in chelsio card. > > Firmware can't be updated if card was running (interface go to UP). > > I am try to unload if_cxgbe module, check module unloaded... and after > > short time see module loaded again! > > How is this possible? > > Something is running "ifconfig cxgbe|cxl|cc" on your system. ifconfig > can figure out the name of the module from the name of the ifnet and > will kldload it if it isn't in the kernel already. What is 'something'? ___ 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: How to load kernel module automatic?
On Tue, Dec 06, 2016 at 12:50:40PM +0100, Hans Petter Selasky wrote: > On 12/06/16 12:47, Slawa Olhovchenkov wrote: > > Now I am try to update fw in chelsio card. > > Firmware can't be updated if card was running (interface go to UP). > > I am try to unload if_cxgbe module, check module unloaded... and after > > short time see module loaded again! > > How is this possible? > > Hi, > > devd is likely re-loading the .ko for you. What event is? How devd guess module name for load? ___ 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"
How to load kernel module automatic?
Now I am try to update fw in chelsio card. Firmware can't be updated if card was running (interface go to UP). I am try to unload if_cxgbe module, check module unloaded... and after short time see module loaded again! How is this possible? ___ 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"
QLogic FastLinQ support
Is support for QLogic FastLinQ QL45000 planed in FreeBSD? ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On Sat, Nov 26, 2016 at 01:55:14PM -0800, Adrian Chadd wrote: > ok, hm. then i don' know offhand, not without putting in printf debugging. :) I am not expert in this code, I am need you patches for printf debugging. > On 26 November 2016 at 13:51, Slawa Olhovchenkov wrote: > > On Sat, Nov 26, 2016 at 01:49:00PM -0800, Adrian Chadd wrote: > > > >> Ok. So boot verbose and let's see what it says. > > > > See first message: it's already verbose boot. > > Yes, only 3 lines. > > > >> > >> On 26 November 2016 at 10:39, Slawa Olhovchenkov wrote: > >> > On Sat, Nov 26, 2016 at 09:44:49AM -0800, Adrian Chadd wrote: > >> > > >> >> The ACPI SRAT parsing code - sys/x86/acpica/srat.c . > >> >> > >> >> I'd start by enabling bootverbose - adds one echo (SLIT.Localities and > >> >> the table); adds CPU affinity info (legacy, XAPIC, ACPI) and other > >> >> locality stuff. > >> > > >> > I am use r308809 of HEAD. ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On Sat, Nov 26, 2016 at 01:49:00PM -0800, Adrian Chadd wrote: > Ok. So boot verbose and let's see what it says. See first message: it's already verbose boot. Yes, only 3 lines. > > On 26 November 2016 at 10:39, Slawa Olhovchenkov wrote: > > On Sat, Nov 26, 2016 at 09:44:49AM -0800, Adrian Chadd wrote: > > > >> The ACPI SRAT parsing code - sys/x86/acpica/srat.c . > >> > >> I'd start by enabling bootverbose - adds one echo (SLIT.Localities and > >> the table); adds CPU affinity info (legacy, XAPIC, ACPI) and other > >> locality stuff. > > > > I am use r308809 of HEAD. ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On Sat, Nov 26, 2016 at 09:44:49AM -0800, Adrian Chadd wrote: > The ACPI SRAT parsing code - sys/x86/acpica/srat.c . > > I'd start by enabling bootverbose - adds one echo (SLIT.Localities and > the table); adds CPU affinity info (legacy, XAPIC, ACPI) and other > locality stuff. I am use r308809 of HEAD. ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On Sat, Nov 26, 2016 at 09:35:08AM -0800, Adrian Chadd wrote: > It may be something to do with memory topology parsing. Maybe we need > some more debugging there to try and catch it. What debug you need? > On 26 November 2016 at 01:21, Slawa Olhovchenkov wrote: > > I am try to enable NUMA in bios and can't boot FreeBSD. > > Boot stoped after next messages: > > > > === > > Booting... > > KDB: debugger backends: ddb > > KDB: current backend: ddb > > === > > > > This is verbose boot. > > No reaction to ~^B, NMI. > > > > Same for head and 10.3-RELEASE. > > > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. > > > > On slight different hardware > > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) > > 10.3 boot ok w/ BIOS NUMA enabled. > > > > ___ > > 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: Enabling NUMA in BIOS stop booting FreeBSD
On Sat, Nov 26, 2016 at 07:07:20PM +0300, Slawa Olhovchenkov wrote: > On Sat, Nov 26, 2016 at 05:57:47PM +0200, Konstantin Belousov wrote: > > > On Sat, Nov 26, 2016 at 12:21:24PM +0300, Slawa Olhovchenkov wrote: > > > I am try to enable NUMA in bios and can't boot FreeBSD. > > > Boot stoped after next messages: > > > > > > === > > > Booting... > > > KDB: debugger backends: ddb > > > KDB: current backend: ddb > > So at least the hammer_time() has a chance to initialize the console. > > Do you have serial console ? Set the loader tunable debug.late_console > > Via ipmi sol > > > to 1 and see if any NMI reaction appear. > > I am try this late. > > > > === > > > > > > This is verbose boot. > > > No reaction to ~^B, NMI. > > > > > > Same for head and 10.3-RELEASE. > > > > > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. > > Is there a BIOS option for 'on-chip cluster' or 'HPC computing' ? > > No > > > What if you try to frob it ? > > > > > > > > On slight different hardware > > > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) > > > 10.3 boot ok w/ BIOS NUMA enabled. > > > > I think the only way to debug this is to add printf() lines to hammer_time() > > to see where does it break. Note that amd64_kdb_init() call succeeded, > > so you can start bisect the code from there. > > > > I am not expert in this code. I am think code halted in later getmemsize() (or before it), I am don't see any messages from init_ops.parse_memmap()/native_parse_memmap(). ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On Sat, Nov 26, 2016 at 05:57:47PM +0200, Konstantin Belousov wrote: > On Sat, Nov 26, 2016 at 12:21:24PM +0300, Slawa Olhovchenkov wrote: > > I am try to enable NUMA in bios and can't boot FreeBSD. > > Boot stoped after next messages: > > > > === > > Booting... > > KDB: debugger backends: ddb > > KDB: current backend: ddb > So at least the hammer_time() has a chance to initialize the console. > Do you have serial console ? Set the loader tunable debug.late_console Via ipmi sol > to 1 and see if any NMI reaction appear. I am try this late. > > === > > > > This is verbose boot. > > No reaction to ~^B, NMI. > > > > Same for head and 10.3-RELEASE. > > > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. > Is there a BIOS option for 'on-chip cluster' or 'HPC computing' ? No > What if you try to frob it ? > > > > > On slight different hardware > > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) > > 10.3 boot ok w/ BIOS NUMA enabled. > > I think the only way to debug this is to add printf() lines to hammer_time() > to see where does it break. Note that amd64_kdb_init() call succeeded, > so you can start bisect the code from there. > I am not expert in this code. ___ 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"
Enabling NUMA in BIOS stop booting FreeBSD
I am try to enable NUMA in bios and can't boot FreeBSD. Boot stoped after next messages: === Booting... KDB: debugger backends: ddb KDB: current backend: ddb === This is verbose boot. No reaction to ~^B, NMI. Same for head and 10.3-RELEASE. Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. On slight different hardware (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) 10.3 boot ok w/ BIOS NUMA enabled. ___ 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: GOST in OPENSSL_BASE
On Mon, Jul 18, 2016 at 12:39:46PM -0400, Jung-uk Kim wrote:
> On 07/18/16 08:12 AM, Mathieu Arnold wrote:
> > Hi,
> >
> > +--On 11 juillet 2016 22:56:00 +0300 Slawa Olhovchenkov
> > wrote:
> > | On Mon, Jul 11, 2016 at 03:00:39PM -0400, Jung-uk Kim wrote:
> > |> > .if ( ${PORT_OPTIONS:MGOST} || ${PORT_OPTIONS:MGOST_ASN1} ) &&
> > |> > ${SSL_DEFAULT} == base BROKEN= OpenSSL from the base system does not
> > |> > support GOST, add \ DEFAULT_VERSIONS+=ssl=openssl to your
> > |> > /etc/make.conf and rebuild everything \ that needs SSL.
> > |> > .endif
> > |>
> > |> FreeBSD 9.3 is still supported but GOST is not available there. It
> > |
> > | Thanks for clarifications.
> > |
> > |> seems the ports maintainer didn't want to break it on 9.3 (CC added).
> > |> Version check may be needed there.
> > |
> > | Thanks!
> >
> >
> > The idea is that you can't have mixed openssl usage. If you link half your
> > ports with openssl from base, and half with openssl from ports, you are
> > going to have dragons attacks, and core dumps. Also, if you are using
> > openssl from ports, you cannot use GSSAPI from base, for the same reasons.
>
> Exactly. That's why we should *allow* using base OpenSSL for 10.x and
> later because many packages are already linked against base OpenSSL by
> default.
Ports still refuse to GOST from base openssl.
___
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: Large patch/diff refuses to apply
On Thu, Oct 06, 2016 at 07:57:57AM -0600, Sean Bruno wrote: > I'm doing a large amount of change to ixgbe(4) in support of IFLIB > implementations and running into failures when trying to apply large > diffs. This is causing phabricator reviews to be unuseable as well. > > I've setup two trees to test this. The first tree is used to generate > the diff and the second (vanilla) is used to apply the diff. The entire > patch fails to apply, so I'm assuming that the size of the diff is > failing because of a sanity check or something. No. This is expanded/collapsed keywords issuse: === -**/ -/*$FreeBSD$*/ === svn diff over repo generate patch w/ collapsed keywords. At working copy all keywords expanded. ___ 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: Heimdal in base
On Wed, Sep 14, 2016 at 10:07:15PM -0400, Garrett Wollman wrote: > < > said: > > > Well, it's definitely too late for 11, now. > > > But, Debian is preparing to remove their heimdal package entirely, > > imminently: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837728 > > The primary issue, so far as I can see, is that Heimdal and MIT were > only compatible in the parts of the API that were formally > standardized. For those of us who need MIT (to have a working kadmin, > for example), that has pretty much always boiled down to completely > disabling Heimdal in base (and anything that depends on it, like > OpenSSH, pam_krb5, and GSSAPI-authenticated NFS), and installing > replacement bits from ports/packages. > > If we're going to remove Heimdal from base, we should completely > deorbit (or disable, as appropriate) all of the things that depend on > it, and make sure that there are ports that provide replacement > functionality. (AFAIK the only thing missing is gssd, the user-mode > side of the authenticated NFS support.) My bet would be that very few > FreeBSD users actually take advantage of this support, and unless > they're running in an all-FreeBSD or all-Heimdal shop probably have to > install MIT Kerberos anyway. I am use gssd. For $HOME over NFS. ___ 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: 11.0-RELEASE status update
On Thu, Sep 01, 2016 at 09:10:00PM +, Glen Barber wrote: > As some of you may be aware, a few last-minute showstoppers appeared > since 11.0-RC1 (and before RC1). > > One of the showstoppers has been fixed in 12-CURRENT, and merged to > stable/11 and releng/11.0 that affected booting from large volumes: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212139 > > There is one issue that is still being investigated, which we are > classifying as an EN candidate, given the manifestations of the issue > and reproducibility: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212168 > > There is one blocker before 11.0-RELEASE, that affects libarchive, which > we are waiting for feedback. Once feedback is received, the schedule > for 11.0-RELEASE will be updated on the website to reflect reality. > > There are a few post-release EN items on our watch list as well, so if > something was not mentioned here, that does not mean it will not be > fixed in 11.0-RELEASE. > > Apologies for the delay, and as always, thank you for your patience. > > Glen > On behalf of: re@ > Do you planed to fix issuse with missied and delete libmap32.conf? ___ 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: [PATCH] randomized delay in locking primitives, take 2
On Mon, Aug 01, 2016 at 02:16:59PM +0300, Andriy Gapon wrote: > > Mateusz, > > just out of curiosity, have you tried to explore alternative spinlock > implementations like a ticket lock? It would be interesting to see if > there are any improvements to be gained there. Effective ticket lock implementation as I see limited to 256 (255?) concurent locks. And anyway may be need randomize delay (QPI bus on x86 have very limited performance). ___ 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: (boost::)asio and kqueue problem
On Wed, Jul 20, 2016 at 07:38:09AM +0300, Konstantin Belousov wrote:
> On Tue, Jul 19, 2016 at 05:35:59PM +0200, Hartmut Brandt wrote:
> > Hi,
> >
> > I'm trying to use asio (that's boost::asio without boost) to handle
> > listening sockets asynchronuosly. This appears not to work. There are also
> > some reports on the net about this problem. I was able to reproduce the
> > problem with a small C-programm that does the same steps as asio. The
> > relevant sequence of system calls is:
> >
> > kqueue() = 3 (0x3)
> > socket(PF_INET,SOCK_STREAM,6)= 4 (0x4)
> > setsockopt(0x4,0x,0x800,0x7fffea2c,0x4) = 0 (0x0)
> > kevent(3,{ 4,EVFILT_READ,EV_ADD|EV_CLEAR,0x0,0x0,0x0
> > 4,EVFILT_WRITE,EV_ADD|EV_CLEAR,0x0,0x0,0x0 },2,0x0,0,0x0) = 0 (0x0)
> > setsockopt(0x4,0x,0x4,0x7fffea2c,0x4)= 0 (0x0)
> > bind(4,{ AF_INET 0.0.0.0:8080 },16) = 0 (0x0)
> > listen(0x4,0x80) = 0 (0x0)
> > ioctl(4,FIONBIO,0xea2c) = 0 (0x0)
> > kevent(3,{ 4,EVFILT_READ,EV_ADD|EV_CLEAR,0x0,0x0,0x0
> > 4,EVFILT_WRITE,EV_ADD|EV_CLEAR,0x0,0x0,0x0 },2,0x0,0,0x0) = 0 (0x0)
> > kevent(3,0x0,0,0x7fffe5a0,32,0x0)ERR#4 'Interrupted
> > system call'
> >
> > The problem here is that asio registers each file descriptor with
> > EVFILT_READ and EVFILT_WRITE as soon as it is opened (first kevent call).
> > After bringing the socket into the listening state and when async_accept()
> > is called it registers the socket a second time. According to the man page
> > this is perfectly legal and can be used to modify the registration.
> >
> > With this sequence of calls kevent() does not return when a connection is
> > established successfully.
> >
> > I tracked down the problem and the reason is in soo_kqfilter(). This is
> > called for the first EVFILT_READ registration and decides based on the
> > SO_ACCEPTCONN flag which filter operations to use solisten_filtops or
> > soread_filtops. In this case it chooses soread_filtops.
> >
> > The second EVFILT_READ registration does not call soo_kqfilter() again,
> > but just updates the filter from the data and fflags field so the
> > listening socket ends up with the wrong filter operations.
> >
> > The attached patch fixes this (kind of) by using the f_touch
> > operation (currently used only by the user filter). The filt_sotouch()
> > function changes the operation pointer in the knote when the socket is now
> > in the listening state. I suppose that the required locking is already
> > done in kqueue_register(), but I'm not sure. Asynchronous accepting now
> > works.
> >
> > A better fix would probably be to change the operation vector on all
> > knotes attached to the socket in solisten(), but I fear I don't have the
> > necessary understanding of the locking that is required for this.
> >
> > Could somebody with enough kqueue() knowledge look whether the patch is
> > correct lock-wise?
> I find it weird that the fix still requires re-registration of the socket
> event to get it working after socket is marked as listen. In other words,
> until the re-registration is done, the events for the registered filter
> are lost.
>
> IMO more correct solution would be to merge the filt_solisten and
> filt_soread, deciding which path to take by testing the SO_ACCEPTCON
> flag in the f_event() op.
>
> This should also eliminate the concerns with the patching of pointer
> which is not supposed to be changed.
may be this is related to netmap problem also?
___
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: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r
On Tue, Jul 12, 2016 at 02:05:32PM -0700, Chris H wrote: > On Tue, 12 Jul 2016 16:09:10 +0930 Shane Ambler wrote > > > On 12/07/2016 06:54, Conrad Meyer wrote: > > > DVD-R dates to 1997; cheap USB flash devices are now pervasive. Maybe > > > it's time to move on from CD. > > > > +1 on dropping CD images. I haven't burnt a CD in over 10 years and I > > don't believe I have seen a CD only drive in that time. Even with a CD > > size image I have burnt them to DVD, I first started this because > > transfer speeds of DVD's are faster and nowadays it costs almost the > > same to burn a DVD. So I see zero benefit to using CD's and that's > > before thinking of reusable USB devices. > > > > I do think there is a benefit to keeping the small boot only image > > available that can be used to start/recover a machine that can then > > download any data to be installed. > > > > -- > > FreeBSD - the place to B...Storing Data > > > > Shane Ambler > > > > -1 > There is no *good* reason that FreeBSD can't maintain the CD image. > I think the *real* question here is; *why* is it now so hard to fit > it on a CD? clang main binary now 50MB size (27MB for 10.x) -- on live FS and in base.txz. 11.x now ship lldb (on live FS too) -- 50MB also binary -- on live FS and in base.txz. kernel now 26M vs 12M on 10.3. kernel with modules now 115MB vs 54MB on 10.3 total size of *.a now 50M (vs 48M). All binaries slightly bigger: usr/bin/ld from 1580008 to 1615912 (+2%). ___ 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"
