Re: cannot get touchpad mouse, no psm device, on Dell Precision 3520

[Pete Wright]

On 06/07/2018 14:01, Anton Shterenlikht wrote:

On Thu, Jun 07, 2018 at 01:34:31PM -0700, Pete Wright wrote:


On 06/07/2018 13:21, Anton Shterenlikht wrote:

Please help get touchpad mouse on
Dell Precision 3520.
The usb mouse works fine.


pciconf isn't really applicable here i think.  does your dmesg buffer
reference any PS/2 devices being detected?  here is CURRENT detecting my
synaptics touchpad:

$ dmesg|grep psm
psm0:  irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: model Synaptics Touchpad, device ID 0

z> dmesg|grep psm
z>

Perhaps this relatively modern laptop
uses a different device for its touchpad?


hrm, looks like it should be a pretty well supported touchpad.  did you 
try updating loader.conf and rebooting to see if it shows up?


it looks like this is the touchpad vendor according to the dell/ubuntu docs:

Aquantia Corp. DLL07A9:01 044E:120B

-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
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: rust broken?

[Matthew Macy]

On Thu, Jun 7, 2018 at 10:33 Michael Butler 
wrote:

> Ah - I'll re-enable that to see if it makes a difference ..
>


It's not a question of enabling. It doesn't explicitly use the 11 symbols.
Rust developers assume that every OS has a frozen ABI like Linux. The rust
from rustup will only work on 11. This is why you need to use the port /
pkg.

-M


> I missed that in the comparison between my two build environments :-(
>
> Michael
>
> On 06/07/18 13:21, Matthew Macy wrote:
> >
> > Rustup uses the 11 ABI.
> >
> > On Thu, Jun 7, 2018 at 10:11 Alan Somers  > > wrote:
> >
> > Can you reproduce the problem using rust installed from rustup
> > instead of
> > from Ports?  If so, you should file a bug report with the Rust
> > developers.
> > Hint: when using Rustup, you'll have to use vresion 1.26.1 instead of
> > 1.26.0.
> > -Alan
> >
> > On Thu, Jun 7, 2018 at 9:44 AM, Michael Butler
> > mailto:i...@protected-networks.net>>
> > wrote:
> >
> > > In response to a Firefox update, I tried to build the new version.
> > > However, rust now fails with a core-dump in the build process.
> > >
> > > checking for libffi > 3.0.9... yes
> > > checking MOZ_FFI_CFLAGS... -I/usr/local/lib/libffi-3.2.1/include
> > > checking MOZ_FFI_LIBS... -L/usr/local/lib -lffi
> > > checking for rustc... /usr/local/bin/rustc
> > > checking for cargo... /usr/local/bin/cargo
> > > checking rustc version...
> > > DEBUG: Executing: `/usr/local/bin/rustc --version --verbose`
> > > DEBUG: The command returned non-zero exit status -12.
> > > DEBUG: Its output was:
> > > DEBUG: | rustc 1.26.0
> > > DEBUG: | binary: rustc
> > > DEBUG: | commit-hash: unknown
> > > DEBUG: | commit-date: unknown
> > > DEBUG: | host: x86_64-unknown-freebsd
> > > DEBUG: | release: 1.26.0
> > > ERROR: Command `/usr/local/bin/rustc --version --verbose` failed
> with
> > > exit status -12.
> > >
> > > Attempts to rebuild rust (and cargo) from the bootstrap files fail
> in
> > > similar fashion.
> > >
> > > On a machine running a SVN r334538 kernel but more recent
> > user-land, it
> > > builds successfully. With (the only difference being) a kernel at
> SVN
> > > r334748, it does not.
> > >
> > > Any hints/thoughts?
> > >
> > > imb
> > > ___
> > > 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
> > "
> >
>
>
___
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: panic: Assertion td->td_lock == TDQ_LOCKPTR(tdq) failed at /usr/src/sys/kern/sched_ule.c:2137

[bob prohaska]

On Thu, Jun 07, 2018 at 05:13:45PM -0700, bob prohaska wrote:
> 
> I'll try again, this time with USB swap turned off.

The circle closed, back to the original panic in the subject line.
Console, top and buildworld.log files are at 
http://www.zefox.net/~fbsd/rpi3/crashes/20180607

Thanks for reading,

bob prohaska

___
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: rust broken?

[Matthew Macy]

Rustup uses the 11 ABI.

On Thu, Jun 7, 2018 at 10:11 Alan Somers  wrote:

> Can you reproduce the problem using rust installed from rustup instead of
> from Ports?  If so, you should file a bug report with the Rust developers.
> Hint: when using Rustup, you'll have to use vresion 1.26.1 instead of
> 1.26.0.
> -Alan
>
> On Thu, Jun 7, 2018 at 9:44 AM, Michael Butler  >
> wrote:
>
> > In response to a Firefox update, I tried to build the new version.
> > However, rust now fails with a core-dump in the build process.
> >
> > checking for libffi > 3.0.9... yes
> > checking MOZ_FFI_CFLAGS... -I/usr/local/lib/libffi-3.2.1/include
> > checking MOZ_FFI_LIBS... -L/usr/local/lib -lffi
> > checking for rustc... /usr/local/bin/rustc
> > checking for cargo... /usr/local/bin/cargo
> > checking rustc version...
> > DEBUG: Executing: `/usr/local/bin/rustc --version --verbose`
> > DEBUG: The command returned non-zero exit status -12.
> > DEBUG: Its output was:
> > DEBUG: | rustc 1.26.0
> > DEBUG: | binary: rustc
> > DEBUG: | commit-hash: unknown
> > DEBUG: | commit-date: unknown
> > DEBUG: | host: x86_64-unknown-freebsd
> > DEBUG: | release: 1.26.0
> > ERROR: Command `/usr/local/bin/rustc --version --verbose` failed with
> > exit status -12.
> >
> > Attempts to rebuild rust (and cargo) from the bootstrap files fail in
> > similar fashion.
> >
> > On a machine running a SVN r334538 kernel but more recent user-land, it
> > builds successfully. With (the only difference being) a kernel at SVN
> > r334748, it does not.
> >
> > Any hints/thoughts?
> >
> > imb
> > ___
> > 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"
>
___
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: r334533 renders head unbootable on XenServer 7.4

[Mateusz Guzik]

On Wed, Jun 6, 2018 at 6:50 PM, Trond Endrestøl <
trond.endres...@fagskolen.gjovik.no> wrote:

> After trial and error, I found r334533 to be responsible for rendering
> head unbootable on XenServer 7.4. Neither of the two available
> XenServer patches has been applied on the host server.
>
> Normal and verbose boot messages stops non-deterministically at:
>
> hpet0:  iomem 0xfed0-0xfed003ff on acpi0
>
> Or at:
>
> granttable0:  on xenpv0
>
> This is on a non-critical VM, but I think this issue should be
> resolved by the time stable/12 becomes available, or if stable/11
> will be impacted by a MFH of r334533 in the near future.
>
> The host server will be upgraded to XenServer 7.5 by the end of the
> week, in case that makes the issue go away.
>

Thanks for the report. Next time if you identify the culprit please cc:
the committer - not everyone watches mailing lists too closely.

I set it up on FreeBSD as dom0 and verified the problem exists.
I fixed it with the following:
https://svnweb.freebsd.org/changeset/base/334820

-- 
Mateusz Guzik 
___
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: panic: Assertion td->td_lock == TDQ_LOCKPTR(tdq) failed at /usr/src/sys/kern/sched_ule.c:2137

[bob prohaska]

On Wed, Jun 06, 2018 at 10:28:58PM -0700, Mark Millard wrote:
> 
> Looks like there has been another stab at avoiding some
> unnecessary Out Of Memory killing of processes:
> 
> Author: alc
> Date: Thu Jun  7 02:54:11 2018
> New Revision: 334752
> URL: https://svnweb.freebsd.org/changeset/base/334752
> 
> 
> Log:
>   . . .  One visible
>   effect of this error was that processes were being killed by the
>   virtual memory system's OOM killer when in fact there was plentiful
>   free memory.
> 

An RPI3 kernel at 334800 still reported 
 Jun  7 16:28:21 www kernel: pid 71329 (c++), uid 0, was killed: out of swap 
space

during a -j4 buildworld.

I wasn't watching top at the time, so I don't know how much swap was in
use. Total available was 4 GB, which certainly seems like it ought to be
enough. The swap was on both microSD and USB flash.

I've run make clean in /usr/src/lib/clang/libllvm and restarted
a -j4 buildworld with the -DNO_CLEAN option, and also set
sysctl vm.pageout_update_period=0 to see what would happen.

Within a few minutes buildworld stopped, the tail of the log file
contained


--- X86GenEVEX2VEXTables.inc ---
llvm-tblgen -gen-x86-EVEX2VEX-tables  -I /usr/src/contrib/llvm/include -I 
/usr/src/contrib/llvm/lib/Target/X86  -d X86GenEVEX2VEXTables.inc.d -o 
X86GenEVEX2VEXTables.inc  /usr/src/contrib/llvm/lib/Target/X86/X86.td
--- X86GenFastISel.inc ---
llvm-tblgen -gen-fast-isel  -I /usr/src/contrib/llvm/include -I 
/usr/src/contrib/llvm/lib/Target/X86  -d X86GenFastISel.inc.d -o 
X86GenFastISel.inc  /usr/src/contrib/llvm/lib/Target/X86/X86.td
--- X86GenDAGISel.inc ---
Killed
*** [X86GenDAGISel.inc] Error code 137

make[6]: stopped in /usr/src/lib/clang/libllvm
1 error

make[6]: stopped in /usr/src/lib/clang/libllvm
*** [all_subdir_lib/clang/libllvm] Error code 2

make[5]: stopped in /usr/src/lib/clang

I'll try again, this time with USB swap turned off.



Thanks for reading!

bob prohaska

___
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: cannot get touchpad mouse, no psm device, on Dell Precision 3520

[Anton Shterenlikht]

On Thu, Jun 07, 2018 at 01:34:31PM -0700, Pete Wright wrote:
> 
> 
> On 06/07/2018 13:21, Anton Shterenlikht wrote:
> > Please help get touchpad mouse on
> > Dell Precision 3520.
> > The usb mouse works fine.
> 
> 
> pciconf isn't really applicable here i think.  does your dmesg buffer 
> reference any PS/2 devices being detected?  here is CURRENT detecting my 
> synaptics touchpad:
> 
> $ dmesg|grep psm
> psm0:  irq 12 on atkbdc0
> psm0: [GIANT-LOCKED]
> psm0: model Synaptics Touchpad, device ID 0

z> dmesg|grep psm
z> 

Perhaps this relatively modern laptop
uses a different device for its touchpad?

Thanks

Anton
___
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: cannot get touchpad mouse, no psm device, on Dell Precision 3520

[Pete Wright]

On 06/07/2018 13:21, Anton Shterenlikht wrote:

Please help get touchpad mouse on
Dell Precision 3520.
The usb mouse works fine.



pciconf isn't really applicable here i think.  does your dmesg buffer 
reference any PS/2 devices being detected?  here is CURRENT detecting my 
synaptics touchpad:


$ dmesg|grep psm
psm0:  irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: model Synaptics Touchpad, device ID 0


assuming it is being detected, have you set:

moused_enable="YES"

in /etc/rc.conf?

If you have set that but do not see your touchpad being detected, and 
assuming it's a synaptics device, have you set the following in 
/boot/loader.conf?


hw.psm.synaptics_support="1"

Cheers,
-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
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"

cannot get touchpad mouse, no psm device, on Dell Precision 3520

[Anton Shterenlikht]

Please help get touchpad mouse on
Dell Precision 3520.
The usb mouse works fine.

z> pciconf -lv
hostb0@pci0:0:0:0:  class=0x06 card=0x07a91028 chip=0x19108086 rev=0x07 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host 
Bridge/DRAM Registers'
class  = bridge
subclass   = HOST-PCI
pcib1@pci0:0:1:0:   class=0x060400 card=0x07a91028 chip=0x19018086 rev=0x07 
hdr=0x01
vendor = 'Intel Corporation'
device = 'Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor PCIe 
Controller (x16)'
class  = bridge
subclass   = PCI-PCI
vgapci1@pci0:0:2:0: class=0x03 card=0x07a91028 chip=0x191b8086 rev=0x06 
hdr=0x00
vendor = 'Intel Corporation'
device = 'HD Graphics 530'
class  = display
subclass   = VGA
none0@pci0:0:4:0:   class=0x118000 card=0x07a91028 chip=0x19038086 rev=0x07 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal 
Subsystem'
class  = dasp
xhci0@pci0:0:20:0:  class=0x0c0330 card=0x07a91028 chip=0xa12f8086 rev=0x31 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H USB 3.0 xHCI Controller'
class  = serial bus
subclass   = USB
none1@pci0:0:20:2:  class=0x118000 card=0x07a91028 chip=0xa1318086 rev=0x31 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H Thermal subsystem'
class  = dasp
none2@pci0:0:21:0:  class=0x118000 card=0x07a91028 chip=0xa1608086 rev=0x31 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H Serial IO I2C Controller'
class  = dasp
none3@pci0:0:21:1:  class=0x118000 card=0x07a91028 chip=0xa1618086 rev=0x31 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H Serial IO I2C Controller'
class  = dasp
none4@pci0:0:22:0:  class=0x078000 card=0x07a91028 chip=0xa13a8086 rev=0x31 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H CSME HECI'
class  = simple comms
ahci0@pci0:0:23:0:  class=0x010601 card=0x07a91028 chip=0xa1028086 rev=0x31 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H SATA controller [AHCI mode]'
class  = mass storage
subclass   = SATA
pcib2@pci0:0:28:0:  class=0x060400 card=0x07a91028 chip=0xa1118086 rev=0xf1 
hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib3@pci0:0:28:2:  class=0x060400 card=0x07a91028 chip=0xa1128086 rev=0xf1 
hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib4@pci0:0:28:4:  class=0x060400 card=0x07a91028 chip=0xa1148086 rev=0xf1 
hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib5@pci0:0:29:0:  class=0x060400 card=0x07a91028 chip=0xa1188086 rev=0xf1 
hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
isab0@pci0:0:31:0:  class=0x060100 card=0x07a91028 chip=0xa1548086 rev=0x31 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H LPC Controller'
class  = bridge
subclass   = PCI-ISA
none5@pci0:0:31:2:  class=0x058000 card=0x07a91028 chip=0xa1218086 rev=0x31 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PMC'
class  = memory
hdac0@pci0:0:31:3:  class=0x040300 card=0x07a91028 chip=0xa1718086 rev=0x31 
hdr=0x00
vendor = 'Intel Corporation'
device = 'CM238 HD Audio Controller'
class  = multimedia
subclass   = HDA
none6@pci0:0:31:4:  class=0x0c0500 card=0x07a91028 chip=0xa1238086 rev=0x31 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H SMBus'
class  = serial bus
subclass   = SMBus
em0@pci0:0:31:6:class=0x02 card=0x07a91028 chip=0x15e38086 rev=0x31 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Ethernet Connection (5) I219-LM'
class  = network
subclass   = ethernet
vgapci0@pci0:1:0:0: class=0x030200 card=0x07a91028 chip=0x13b410de rev=0xa2 
hdr=0x00
vendor = 'NVIDIA Corporation'
device = 'GM107GLM [Quadro M620 Mobile]'
class  = display
subclass   = 3D
iwm0@pci0:2:0:0:class=0x028000 card=0x00508086 chip=0x24fd8086 rev=0x78 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Wireless 8265 / 8275'
class  = network
none7@pci0:3:0:0:   class=0xff card=0x07a91028 chip=0x525a10ec rev=0x01 
hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTS525A PCI Express Card 

Re: rust broken?

[Matthew Macy]

On Thu, Jun 7, 2018 at 10:50 Michael Butler 
wrote:

> On 06/07/18 13:36, Matthew Macy wrote:
> > On Thu, Jun 7, 2018 at 10:33 Michael Butler  > > wrote:
> >
> > Ah - I'll re-enable that to see if it makes a difference ..
> >
> >
> >
> > It's not a question of enabling. It doesn't explicitly use the 11
> > symbols. Rust developers assume that every OS has a frozen ABI like
> > Linux. The rust from rustup will only work on 11. This is why you need
> > to use the port / pkg.
>
> I commented out this line in my kernel config ..
>
> nooption   COMPAT_FREEBSD11



Ah. Yes. The port uses  the 11 ABI symbols explicitly.

>
>
>  .. and the port's bootstrap files now run as they should :-)
>
> Sorry for the noise - self-inflicted wound :-(
>
> imb
>
___
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: rust broken?

[Michael Butler]

On 06/07/18 13:36, Matthew Macy wrote:
> On Thu, Jun 7, 2018 at 10:33 Michael Butler  > wrote:
> 
> Ah - I'll re-enable that to see if it makes a difference ..
> 
> 
> 
> It's not a question of enabling. It doesn't explicitly use the 11
> symbols. Rust developers assume that every OS has a frozen ABI like
> Linux. The rust from rustup will only work on 11. This is why you need
> to use the port / pkg.

I commented out this line in my kernel config ..

nooption   COMPAT_FREEBSD11

 .. and the port's bootstrap files now run as they should :-)

Sorry for the noise - self-inflicted wound :-(

imb
___
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: rust broken?

[Michael Butler]

Ah - I'll re-enable that to see if it makes a difference ..

I missed that in the comparison between my two build environments :-(

Michael

On 06/07/18 13:21, Matthew Macy wrote:
> 
> Rustup uses the 11 ABI.
> 
> On Thu, Jun 7, 2018 at 10:11 Alan Somers  > wrote:
> 
> Can you reproduce the problem using rust installed from rustup
> instead of
> from Ports?  If so, you should file a bug report with the Rust
> developers.
> Hint: when using Rustup, you'll have to use vresion 1.26.1 instead of
> 1.26.0.
> -Alan
> 
> On Thu, Jun 7, 2018 at 9:44 AM, Michael Butler
> mailto:i...@protected-networks.net>>
> wrote:
> 
> > In response to a Firefox update, I tried to build the new version.
> > However, rust now fails with a core-dump in the build process.
> >
> > checking for libffi > 3.0.9... yes
> > checking MOZ_FFI_CFLAGS... -I/usr/local/lib/libffi-3.2.1/include
> > checking MOZ_FFI_LIBS... -L/usr/local/lib -lffi
> > checking for rustc... /usr/local/bin/rustc
> > checking for cargo... /usr/local/bin/cargo
> > checking rustc version...
> > DEBUG: Executing: `/usr/local/bin/rustc --version --verbose`
> > DEBUG: The command returned non-zero exit status -12.
> > DEBUG: Its output was:
> > DEBUG: | rustc 1.26.0
> > DEBUG: | binary: rustc
> > DEBUG: | commit-hash: unknown
> > DEBUG: | commit-date: unknown
> > DEBUG: | host: x86_64-unknown-freebsd
> > DEBUG: | release: 1.26.0
> > ERROR: Command `/usr/local/bin/rustc --version --verbose` failed with
> > exit status -12.
> >
> > Attempts to rebuild rust (and cargo) from the bootstrap files fail in
> > similar fashion.
> >
> > On a machine running a SVN r334538 kernel but more recent
> user-land, it
> > builds successfully. With (the only difference being) a kernel at SVN
> > r334748, it does not.
> >
> > Any hints/thoughts?
> >
> >         imb
> > ___
> > 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
> "
> 

___
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 kern.sched.preempt_thresh=0 a sensible default?

[Andriy Gapon]

On 03/05/2018 12:41, Andriy Gapon wrote:
> I think that we need preemption policies that might not be expressible as one 
> or
> two numbers.  A policy could be something like this:
> - interrupt threads can preempt only threads from "lower" classes: real-time,
> kernel, timeshare, idle;
> - interrupt threads cannot preempt other interrupt threads
> - real-time threads can preempt other real-time threads and threads from 
> "lower"
> classes: kernel, timeshare, idle
> - kernel threads can preempt only threads from lower classes: timeshare, idle
> - interactive timeshare threads can only preempt batch and idle threads
> - batch threads can only preempt idle threads


Here is a sketch of the idea: https://reviews.freebsd.org/D15693

-- 
Andriy Gapon
___
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: rust broken?

[Alan Somers]

Can you reproduce the problem using rust installed from rustup instead of
from Ports?  If so, you should file a bug report with the Rust developers.
Hint: when using Rustup, you'll have to use vresion 1.26.1 instead of
1.26.0.
-Alan

On Thu, Jun 7, 2018 at 9:44 AM, Michael Butler 
wrote:

> In response to a Firefox update, I tried to build the new version.
> However, rust now fails with a core-dump in the build process.
>
> checking for libffi > 3.0.9... yes
> checking MOZ_FFI_CFLAGS... -I/usr/local/lib/libffi-3.2.1/include
> checking MOZ_FFI_LIBS... -L/usr/local/lib -lffi
> checking for rustc... /usr/local/bin/rustc
> checking for cargo... /usr/local/bin/cargo
> checking rustc version...
> DEBUG: Executing: `/usr/local/bin/rustc --version --verbose`
> DEBUG: The command returned non-zero exit status -12.
> DEBUG: Its output was:
> DEBUG: | rustc 1.26.0
> DEBUG: | binary: rustc
> DEBUG: | commit-hash: unknown
> DEBUG: | commit-date: unknown
> DEBUG: | host: x86_64-unknown-freebsd
> DEBUG: | release: 1.26.0
> ERROR: Command `/usr/local/bin/rustc --version --verbose` failed with
> exit status -12.
>
> Attempts to rebuild rust (and cargo) from the bootstrap files fail in
> similar fashion.
>
> On a machine running a SVN r334538 kernel but more recent user-land, it
> builds successfully. With (the only difference being) a kernel at SVN
> r334748, it does not.
>
> Any hints/thoughts?
>
> imb
> ___
> 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"

rust broken?

[Michael Butler]

In response to a Firefox update, I tried to build the new version.
However, rust now fails with a core-dump in the build process.

checking for libffi > 3.0.9... yes
checking MOZ_FFI_CFLAGS... -I/usr/local/lib/libffi-3.2.1/include
checking MOZ_FFI_LIBS... -L/usr/local/lib -lffi
checking for rustc... /usr/local/bin/rustc
checking for cargo... /usr/local/bin/cargo
checking rustc version...
DEBUG: Executing: `/usr/local/bin/rustc --version --verbose`
DEBUG: The command returned non-zero exit status -12.
DEBUG: Its output was:
DEBUG: | rustc 1.26.0
DEBUG: | binary: rustc
DEBUG: | commit-hash: unknown
DEBUG: | commit-date: unknown
DEBUG: | host: x86_64-unknown-freebsd
DEBUG: | release: 1.26.0
ERROR: Command `/usr/local/bin/rustc --version --verbose` failed with
exit status -12.

Attempts to rebuild rust (and cargo) from the bootstrap files fail in
similar fashion.

On a machine running a SVN r334538 kernel but more recent user-land, it
builds successfully. With (the only difference being) a kernel at SVN
r334748, it does not.

Any hints/thoughts?

imb
___
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 do I use the make universe machines?

[Rick Macklem]

Just replying to one of the messages at random...
Benjamin Kaduk wrote:
[stuff snipped]
>I think https://www.freebsd.org/internal/machines.html sounds like
>the page you're looking for.  (universe is just a top-level make
>target like buildworld, but will take a while on non-beefy
>hardware.)
Yea, the last time I tried it on an i386 was FreeBSD9 and even then it took
a week to complete.;-)

Thanks everyone, it is working fine. In particular, I;d like to thank cem@ for
the hint about reading "motd" to see what the command is.

Thanks again, rick
___
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: panic: Assertion td->td_lock == TDQ_LOCKPTR(tdq) failed at /usr/src/sys/kern/sched_ule.c:2137

[Mark Millard]

bob prohaska fbsd at www.zefox.net wrote on
Wed Jun 6 23:57:57 UTC 2018 : 

> On Wed, Jun 06, 2018 at 08:55:39PM +0200, Ronald Klop wrote:
> > On Sat, 02 Jun 2018 13:40:27 +0200, Ronald Klop  >  
> > wrote:
> > 
> > 
> > How do you ever run a -j4 buildworld? My RPI3 starts building clang/llvm  
> > with sometimes 500 MB+ per process so everything starts swapping like hell  
> > and takes forever to run.
> >
> 
> Lately, never 8-)

Looks like there has been another stab at avoiding some
unnecessary Out Of Memory killing of processes:

Author: alc
Date: Thu Jun  7 02:54:11 2018
New Revision: 334752
URL: https://svnweb.freebsd.org/changeset/base/334752


Log:
  . . .  One visible
  effect of this error was that processes were being killed by the
  virtual memory system's OOM killer when in fact there was plentiful
  free memory.


(I do not have access to an appropriate test context at
this time.)


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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"