Re: Deprecating ftpd in the FreeBSD base system?

2020-09-17 Thread Slawa Olhovchenkov
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

2020-09-09 Thread Slawa Olhovchenkov
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

2020-05-05 Thread Slawa Olhovchenkov
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

2020-05-05 Thread Slawa Olhovchenkov
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

2020-04-25 Thread Slawa Olhovchenkov
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 ?

2019-09-20 Thread Slawa Olhovchenkov
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 ?

2019-09-20 Thread Slawa Olhovchenkov
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 ?

2019-09-20 Thread Slawa Olhovchenkov
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?

2019-03-19 Thread Slawa Olhovchenkov
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?

2019-03-19 Thread Slawa Olhovchenkov
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?

2018-10-10 Thread Slawa Olhovchenkov
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?

2018-10-10 Thread Slawa Olhovchenkov
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

2018-07-13 Thread Slawa Olhovchenkov
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

2018-06-03 Thread Slawa Olhovchenkov
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

2018-05-28 Thread Slawa Olhovchenkov
On Mon, May 28, 2018 at 09:02:01AM +0200, Alexander Leidinger wrote:

> Quoting Slawa Olhovchenkov <s...@zxy.spb.ru> (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

2018-05-27 Thread Slawa Olhovchenkov
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

2018-05-22 Thread Slawa Olhovchenkov
On Tue, May 22, 2018 at 04:16:32PM +0200, Alexander Leidinger wrote:

> 
> Quoting Slawa Olhovchenkov <s...@zxy.spb.ru> (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

2018-05-22 Thread Slawa Olhovchenkov
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

2018-05-19 Thread Slawa Olhovchenkov
On Sat, May 19, 2018 at 08:38:20PM +0200, Jan Beich wrote:

> Slawa Olhovchenkov <s...@zxy.spb.ru> 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

2018-05-19 Thread Slawa Olhovchenkov
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

2018-05-19 Thread Slawa Olhovchenkov
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

2018-03-25 Thread Slawa Olhovchenkov
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)

2018-03-13 Thread Slawa Olhovchenkov
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 <s...@zxy.spb.ru> wrote:
> 
> > On Fri, Mar 09, 2018 at 09:58:55AM -0500, Ed Maste wrote:
> >
> > > On 9 March 2018 at 07:01, Slawa Olhovchenkov <s...@zxy.spb.ru> 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)

2018-03-09 Thread Slawa Olhovchenkov
On Fri, Mar 09, 2018 at 09:58:55AM -0500, Ed Maste wrote:

> On 9 March 2018 at 07:01, Slawa Olhovchenkov <s...@zxy.spb.ru> 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)

2018-03-09 Thread Slawa Olhovchenkov
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

2017-09-03 Thread Slawa Olhovchenkov
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?

2017-06-04 Thread Slawa Olhovchenkov
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?

2017-06-04 Thread Slawa Olhovchenkov
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

2017-05-14 Thread Slawa Olhovchenkov
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

2017-05-08 Thread Slawa Olhovchenkov
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)

2017-04-05 Thread Slawa Olhovchenkov
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

2017-03-23 Thread Slawa Olhovchenkov
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

2017-03-19 Thread Slawa Olhovchenkov
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

2017-03-19 Thread Slawa Olhovchenkov
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

2017-03-17 Thread Slawa Olhovchenkov
On Fri, Mar 17, 2017 at 06:31:11PM +0100, O. Hartmann wrote:

> Am Fri, 17 Mar 2017 20:07:35 +0300
> Slawa Olhovchenkov <s...@zxy.spb.ru> 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 <s...@zxy.spb.ru> 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<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> >   
> > Features2=0x7ffefbff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
> > 
> >
> > ^^
> >   AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
> >   AMD Features2=0x121<LAHF,ABM,Prefetch>
> >   Structured Extended
> > Features=0x21cbfbb<FSGSBASE,TSCADJ,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,NFPUSG,PQE,RDSEED,ADX,SMAP,PROCTRACE>
> > 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<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  
Features2=0x7ffefbff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>

^
  AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
  AMD Features2=0x21<LAHF,ABM>
  Structured Extended 
Features=0x37ab<FSGSBASE,TSCADJ,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,NFPUSG>
  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

2017-03-17 Thread Slawa Olhovchenkov
On Fri, Mar 17, 2017 at 05:53:24PM +0100, O. Hartmann wrote:

> Am Fri, 17 Mar 2017 15:04:29 +0300
> Slawa Olhovchenkov <s...@zxy.spb.ru> 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<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  
Features2=0x7ffefbff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>

   ^^
  AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
  AMD Features2=0x121<LAHF,ABM,Prefetch>
  Structured Extended 
Features=0x21cbfbb<FSGSBASE,TSCADJ,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,NFPUSG,PQE,RDSEED,ADX,SMAP,PROCTRACE>
  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

2017-03-17 Thread Slawa Olhovchenkov
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?

2017-01-18 Thread Slawa Olhovchenkov
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?

2017-01-16 Thread Slawa Olhovchenkov
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

2016-12-27 Thread Slawa Olhovchenkov
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

2016-12-23 Thread Slawa Olhovchenkov
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

2016-12-23 Thread Slawa Olhovchenkov
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

2016-12-23 Thread Slawa Olhovchenkov
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

2016-12-17 Thread Slawa Olhovchenkov
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 <s...@zxy.spb.ru> 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

2016-12-17 Thread Slawa Olhovchenkov
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=180=profiling=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() ?

2016-12-16 Thread Slawa Olhovchenkov
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();
CPU_SET(i, );
pthread_attr_init();
pthread_attr_setaffinity_np(, sizeof(mask), );
pthread_create([i].tid, , balancer_thread, [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

2016-12-15 Thread Slawa Olhovchenkov
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

2016-12-15 Thread Slawa Olhovchenkov
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

2016-12-15 Thread Slawa Olhovchenkov
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

2016-12-14 Thread Slawa Olhovchenkov
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

2016-12-14 Thread Slawa Olhovchenkov
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

2016-12-14 Thread Slawa Olhovchenkov
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  322

Re: Enabling NUMA in BIOS stop booting FreeBSD

2016-12-14 Thread Slawa Olhovchenkov
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

2016-12-14 Thread Slawa Olhovchenkov
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

2016-12-14 Thread Slawa Olhovchenkov
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

2016-12-13 Thread Slawa Olhovchenkov
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

2016-12-13 Thread Slawa Olhovchenkov
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

2016-12-13 Thread Slawa Olhovchenkov
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

2016-12-13 Thread Slawa Olhovchenkov
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(>msg_lock, sizeof(mbp->msg_lock));
>   mtx_init(>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

2016-12-13 Thread Slawa Olhovchenkov
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

2016-12-13 Thread Slawa Olhovchenkov
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

2016-12-12 Thread Slawa Olhovchenkov
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

2016-12-12 Thread Slawa Olhovchenkov
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

2016-12-12 Thread Slawa Olhovchenkov
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

2016-12-12 Thread Slawa Olhovchenkov
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

2016-12-12 Thread Slawa Olhovchenkov
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 
SMAP type=04 base=

Re: Enabling NUMA in BIOS stop booting FreeBSD

2016-12-11 Thread Slawa Olhovchenkov
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

2016-12-11 Thread Slawa Olhovchenkov
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

2016-12-11 Thread Slawa Olhovchenkov
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=6400 attr=01 
>  

Re: Enabling NUMA in BIOS stop booting FreeBSD

2016-12-11 Thread Slawa Olhovchenkov
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/sfxge.ko ESC[02;00HSMAP type=02 
base=7c00 len=0

Re: Enabling NUMA in BIOS stop booting FreeBSD

2016-12-11 Thread Slawa Olhovchenkov
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

2016-12-11 Thread Slawa Olhovchenkov
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 0x80538d

Re: Enabling NUMA in BIOS stop booting FreeBSD

2016-12-11 Thread Slawa Olhovchenkov
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?

2016-12-06 Thread Slawa Olhovchenkov
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?

2016-12-06 Thread Slawa Olhovchenkov
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?

2016-12-06 Thread Slawa Olhovchenkov
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?

2016-12-06 Thread Slawa Olhovchenkov
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?

2016-12-06 Thread Slawa Olhovchenkov
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

2016-12-02 Thread Slawa Olhovchenkov
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

2016-11-26 Thread Slawa Olhovchenkov
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 <s...@zxy.spb.ru> 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 <s...@zxy.spb.ru> 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

2016-11-26 Thread Slawa Olhovchenkov
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 <s...@zxy.spb.ru> 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

2016-11-26 Thread Slawa Olhovchenkov
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

2016-11-26 Thread Slawa Olhovchenkov
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 <s...@zxy.spb.ru> 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

2016-11-26 Thread Slawa Olhovchenkov
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

2016-11-26 Thread Slawa Olhovchenkov
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

2016-11-26 Thread Slawa Olhovchenkov
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

2016-11-01 Thread Slawa Olhovchenkov
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 <s...@zxy.spb.ru>
> > 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

2016-10-06 Thread Slawa Olhovchenkov
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

2016-09-15 Thread Slawa Olhovchenkov
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

2016-09-01 Thread Slawa Olhovchenkov
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

2016-08-01 Thread Slawa Olhovchenkov
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

2016-07-19 Thread Slawa Olhovchenkov
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

2016-07-13 Thread Slawa Olhovchenkov
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"


Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

2016-07-12 Thread Slawa Olhovchenkov
On Tue, Jul 12, 2016 at 09:58:08PM +0100, Steven Hartland wrote:

> On 12/07/2016 21:50, Slawa Olhovchenkov wrote:
> > On Tue, Jul 12, 2016 at 01:39:34PM -0700, Conrad Meyer wrote:
> >
> >> Maybe Tier 2 can deal with just bootonly.iso.  Or your machines should
> >> be dropped from Tier 2 if they don't support USB and we aren't okay
> >> with dropping disc1 support for all of Tier 2.
> >>
> >> There's lots of aging hardware we don't support in modern FreeBSD,
> >> including alpha and ia64.  USB is 20 years young at this point.
> > Not all BIOS can be boot from USB.
> > I am have Fujitsu notebook not support USB boot.
> >
>  From a USB Pen drive I can understand but from a USB DVD Drive that 
> would be some seriously antiquated hardware!

They have CD-ROM. Why I need buy USB DVD Drive?

___
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

2016-07-12 Thread Slawa Olhovchenkov
On Tue, Jul 12, 2016 at 01:39:34PM -0700, Conrad Meyer wrote:

> Maybe Tier 2 can deal with just bootonly.iso.  Or your machines should
> be dropped from Tier 2 if they don't support USB and we aren't okay
> with dropping disc1 support for all of Tier 2.
> 
> There's lots of aging hardware we don't support in modern FreeBSD,
> including alpha and ia64.  USB is 20 years young at this point.

Not all BIOS can be boot from USB.
I am have Fujitsu notebook not support USB boot.

> Best,
> Conrad
> 
> On Tue, Jul 12, 2016 at 12:52 PM, Mark Linimon  wrote:
> > On Tue, Jul 12, 2016 at 04:09:10PM +0930, Shane Ambler wrote:
> >> +1 on dropping CD images.
> >
> > I have 24U of things that don't have DVD players, including some tier-2
> > machines for which no upgrade is available.
> >
> > mcl
> ___
> 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: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

2016-07-11 Thread Slawa Olhovchenkov
On Mon, Jul 11, 2016 at 09:41:44PM +, Glen Barber wrote:

> On Mon, Jul 11, 2016 at 03:32:34PM -0600, Alan Somers wrote:
> > > On Mon, Jul 11, 2016 at 2:01 PM, Ronald Klop  wrote:
> > >> Hi,
> > >>
> > >> Just downloaded the amd64 BETA1 ISO (873MB) and tried to burn a CD on
> > >> Windows 10. It complained that the ISO is too big for my 700 MB CD-r.
> > >>
> > >> The bootonly iso (281MB) burns and runs ok.
> > >>
> > >> Regards,
> > >> Ronald.
> > 
> > Please open a PR.  Those images should be able to fit on a CD.
> 
> This was actually a known "going to be problem" thing for 11.0.  I'm
> looking into how to fix this for 11.0-RELEASE, but right now, there is
> not much more we can exclude from it. :(

Reduce GENERIC to MINIMAL?
___
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

2016-07-11 Thread Slawa Olhovchenkov
On Mon, Jul 11, 2016 at 07:48:44PM +0300, Andrey Chernov wrote:

> On 11.07.2016 19:29, Slawa Olhovchenkov wrote:
> > On Mon, Jul 11, 2016 at 11:04:33AM -0500, Mark Felder wrote:
> > 
> >>
> >>
> >> On Mon, Jul 11, 2016, at 05:29, Slawa Olhovchenkov wrote:
> >>>
> >>> I.e. GOST will be available in openssl.
> >>> Under BSD-like license.
> >>> Can be this engine import in base system and enabled at time 1.1.0?
> >>> And can be GOST enabled now?
> >>>
> >>
> >> I think the wrong question is being asked here. Instead we need to focus
> >> on decoupling openssl from base so this can all be handled by ports.
> > 
> > This is wrong direction with current policy.
> > ports: unsupported by FreeBSD core and securite team, no guaranted to 
> > comaptible
> > between options and applications.
> > 
> > base: supported by FreeBSD core and securite team, covered by CI,
> > checked for forward and backward API and ABI compatibility.
> > 
> 
> Ports are supported by secteam, and recently I notice "headsup" mail
> with intention to make base openssl private and switch all ports to
> security/openssl port.

I mean `support` is commit reviewing, auditing and etc.
Secteam do it for ports?

> Adding of GOST as 3rd party plugin is technically possible in both
> (base, ports) cases, the rest of decision is up to FreeBSD openssl
> maintainers and possible contributors efforts.
> 
> I need to specially point to "patches" section of the 3rd party GOST
> plugin, from just viewing I don't understand, are those additional
> openssl patches should be applied to openssl for GOST, or they are just
> reflect existent changes in the openssl.
> 
> ___
> freebsd-secur...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-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: GOST in OPENSSL_BASE

2016-07-11 Thread Slawa Olhovchenkov
On Mon, Jul 11, 2016 at 03:00:39PM -0400, Jung-uk Kim wrote:

> On 07/11/16 02:41 PM, Slawa Olhovchenkov wrote:
> > On Mon, Jul 11, 2016 at 02:28:45PM -0400, Jung-uk Kim wrote:
> > 
> >> On 07/10/16 10:10 AM, Andrey Chernov wrote:
> >>> On 10.07.2016 16:30, Slawa Olhovchenkov wrote:
> >>>> I am surprised lack of support GOST in openssl-base.
> >>>> Can be this enabled before 11.0 released?
> >>>
> >>> AFAIK openssl maintainers says something like they can't support this
> >>> code and it will become rotten shortly with new changes, so they drop it.
> >>
> >> [OpenSSL-maintainer-for-the-base hat on]
> >>
> >> GOST is supported on FreeBSD 10.x and 11.x.  We will not drop it on
> >> these branches unless secteam explicitly ask us to do so.  However, we
> >> *may* drop it from 12.0 *iff* we import OpenSSL 1.1.0 branch.
> >>
> >> [OpenSSL-maintainer-for-the-base hat off]
> >>
> >> Jung-uk Kim
> >>
> > 
> > Thanks!
> > 
> > May be need file PR for dns/bind910?
> > 
> > # grep -3 BROK /poudriere/ports/default/dns/bind910/Makefile
> > .include 
> > 
> > .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!

> Jung-uk Kim
> 
___
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

2016-07-11 Thread Slawa Olhovchenkov
On Mon, Jul 11, 2016 at 02:28:45PM -0400, Jung-uk Kim wrote:

> On 07/10/16 10:10 AM, Andrey Chernov wrote:
> > On 10.07.2016 16:30, Slawa Olhovchenkov wrote:
> >> I am surprised lack of support GOST in openssl-base.
> >> Can be this enabled before 11.0 released?
> > 
> > AFAIK openssl maintainers says something like they can't support this
> > code and it will become rotten shortly with new changes, so they drop it.
> 
> [OpenSSL-maintainer-for-the-base hat on]
> 
> GOST is supported on FreeBSD 10.x and 11.x.  We will not drop it on
> these branches unless secteam explicitly ask us to do so.  However, we
> *may* drop it from 12.0 *iff* we import OpenSSL 1.1.0 branch.
> 
> [OpenSSL-maintainer-for-the-base hat off]
> 
> Jung-uk Kim
> 

Thanks!

May be need file PR for dns/bind910?

# grep -3 BROK /poudriere/ports/default/dns/bind910/Makefile
.include 

.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-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

2016-07-11 Thread Slawa Olhovchenkov
On Mon, Jul 11, 2016 at 11:04:33AM -0500, Mark Felder wrote:

> 
> 
> On Mon, Jul 11, 2016, at 05:29, Slawa Olhovchenkov wrote:
> > 
> > I.e. GOST will be available in openssl.
> > Under BSD-like license.
> > Can be this engine import in base system and enabled at time 1.1.0?
> > And can be GOST enabled now?
> > 
> 
> I think the wrong question is being asked here. Instead we need to focus
> on decoupling openssl from base so this can all be handled by ports.

This is wrong direction with current policy.
ports: unsupported by FreeBSD core and securite team, no guaranted to comaptible
between options and applications.

base: supported by FreeBSD core and securite team, covered by CI,
checked for forward and backward API and ABI compatibility.
___
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"


  1   2   3   4   >