Re: ls colour (COLORTERM / CLICOLOR)

2020-07-20 Thread James Wright




On 20/07/2020 14:26, Kyle Evans wrote:

On Sat, Jul 18, 2020 at 7:51 PM James Wright
 wrote:


 Updated to 12.1-STABLE r363215 a few days ago (previous build was
circa 1st June)
but seem to have lost "ls" colour output with "COLORTERM=yes" set in my env.

Setting "CLICOLOR=yes" seems to enable it again, however the man page
states that
setting either should work?


Hi,

Indeed, sorry for the flip-flopping. The short version of the
situation is that I had flipped ls(1) to --color=auto by default based
on a misunderstanding of defaults elsewhere due to shell aliases that
I hadn't realized were in use. The ls(1) binary is historically and
almost universally configured for non-colored by default where color
support exists, and you should instead use appropriate shell alias for
ls=`ls -G` or `ls --color=auto`.

I can see where the manpage could describe the differences a little
better. CLICOLOR (On FreeBSD) historically meant that we'll enable
color if the terminal supports it, and setting it would have the same
effect as the above shell alias. COLORTERM is less aggressive and
won't imply any specific --color option, you would still --color=auto
to go with it for it to have any effect.

Thanks,

Kyle Evans


Thank you for the clarifying the diferences between CLICOLOR and COLORTERM,
that makes sense to me now. I'll set the shell alias and remove COLORTERM.
Only raised this in case it was an unintended consequence of recent 
changes. :-)



___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


ls colour (COLORTERM / CLICOLOR)

2020-07-18 Thread James Wright


   Updated to 12.1-STABLE r363215 a few days ago (previous build was 
circa 1st June)

but seem to have lost "ls" colour output with "COLORTERM=yes" set in my env.

  Setting "CLICOLOR=yes" seems to enable it again, however the man page 
states that

setting either should work?

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: Random system lockups with 12.1-STABLE r354241 amd64

2019-11-13 Thread James Wright


  Yesterday evening I fetched the lastest from svn stable (r354662), 
created a custom kernel configuration with the following options, and 
rebuilt everything;


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
include GENERIC
ident MACBOOK

# For full debugger support use (turn off in stable branch):
options BUF_TRACKING    # Track buffer history
options DDB # Support DDB.
options FULL_BUF_TRACKING   # Track more buffer history
options GDB # Support remote GDB.
options DEADLKRES   # Enable the deadlock resolver
options INVARIANTS  # Enable calls of extra sanity 
checking
options INVARIANT_SUPPORT   # Extra sanity checks of 
internal structures, required by INVARIANTS
options WITNESS # Enable checks to detect 
deadlocks and cycles
options WITNESS_SKIPSPIN    # Don't run witness on spinlocks 
for speed

options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones
options VERBOSE_SYSINIT=0   # Support debug.verbose_sysinit, 
off by default


<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

  Then this evening, another system hang, no debugger messages or any 
sort of output whatsoever! :-( The only upside is that I'm experiencing 
these hangs almost daily now, so going to try a process of elimination. 
The hangs generally seem to occur when I'm working using Sublime Text 3 
(via the linuxulator), with an open xterm window or two with X11 
(currently using the Intel video driver). So might try switching to 
modesetting video driver, or using an editor that is native, or ditch 
the graphical environment altogether and see if I still get issues 
working on the console.


  If anyone has any ideas on how else I may be able to track down the 
issue, please let me know! :-)



Thanks,
James


On 07/11/2019 21:21, James Wright wrote:


On 06/11/2019 23:42, Julian Elischer wrote:

On 11/6/19 2:58 PM, James Wright wrote:

Hi,

[...]

  Can anyone offer some advice as to how I can track down this issue?
The first question which I couldn't see from your dmesg is "do you 
have ht krnel debugger configured into your kernel?"




  Nope it isn't, I will build it in, is it just adding options KDB and 
DDB?


  Another problem I have is I don't seemt to get any crash dumps even 
though I have 'dumpdev="AUTO"' in my /etc/rc.conf, could this be due 
to my system using a swap file (md) rather than a dedicated swap 
partition?





___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: Random system lockups with 12.1-STABLE r354241 amd64

2019-11-07 Thread James Wright


On 06/11/2019 23:42, Julian Elischer wrote:

On 11/6/19 2:58 PM, James Wright wrote:

Hi,

[...]

  Can anyone offer some advice as to how I can track down this issue?
The first question which I couldn't see from your dmesg is "do you 
have ht krnel debugger configured into your kernel?"




  Nope it isn't, I will build it in, is it just adding options KDB and DDB?

  Another problem I have is I don't seemt to get any crash dumps even 
though I have 'dumpdev="AUTO"' in my /etc/rc.conf, could this be due to 
my system using a swap file (md) rather than a dedicated swap partition?



___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Random system lockups with 12.1-STABLE r354241 amd64

2019-11-06 Thread James Wright

Hi,

   Since upating to r354241 a few days ago I've been experiencing more 
frequent complete system lockups, with around 4 happening over the last 
couple of days. Prior to this I would get the occasional lockup, perhaps 
once a month on my laptop which is used daily.


  I'm finding it hard to determine the issue as it seems completely 
random, and the only course of action left open once it occurs is to 
hard power down the machine, which *always* seems to lead to filesystem 
inconsistencies upon restarting, (the file system is UFS with SU+J).


  Can anyone offer some advice as to how I can track down this issue?

# uname -a
FreeBSD macbook 12.1-STABLE FreeBSD 12.1-STABLE r354241 GENERIC amd64


# dmesg
---<>---
Copyright (c) 1992-2019 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
    The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.1-STABLE r354241 GENERIC amd64
FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on 
LLVM 8.0.1)

VT(efifb): resolution 1440x900
CPU: Intel(R) Core(TM) i7-5650U CPU @ 2.20GHz (2200.05-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x306d4  Family=0x6  Model=0x3d Stepping=4
Features=0xbfebfbff
Features2=0x7ffafbff
  AMD Features=0x2c100800
  AMD Features2=0x121
  Structured Extended 
Features=0x21c2fbb

  Structured Extended Features3=0x9c000400
  XSAVE Features=0x1
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 8589934592 (8192 MB)
avail memory = 8154464256 (7776 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads
random: unblocking device.
ioapic0  irqs 0-39 on motherboard
Launching APs: 1 2 3
Timecounter "TSC-low" frequency 1100025386 Hz quality 1000
random: entropy device external interface
kbd0 at kbdmux0
000.23 [4336] netmap_init   netmap: loaded module
[ath_hal] loaded
module_register_init: MOD_LOAD (vesa, 0x81131fa0, 0) error 19
random: registering fast source Intel Secure Key RNG
random: fast provider: "Intel Secure Key RNG"
nexus0
efirtc0:  on motherboard
efirtc0: registered as a time-of-day clock, resolution 1.00s
cryptosoft0:  on motherboard
acpi0:  on motherboard
acpi_ec0:  port 0x62,0x66 on acpi0
acpi0: Power Button (fixed)
hpet0:  iomem 0xfed0-0xfed03fff irq 0,8 
on acpi0

Timecounter "HPET" frequency 14318180 Hz quality 950
Event timer "HPET" frequency 14318180 Hz quality 550
Event timer "HPET1" frequency 14318180 Hz quality 440
Event timer "HPET2" frequency 14318180 Hz quality 440
Event timer "HPET3" frequency 14318180 Hz quality 440
Event timer "HPET4" frequency 14318180 Hz quality 440
cpu0:  on acpi0
atrtc0:  port 0x70-0x77 on acpi0
atrtc0: registered as a time-of-day clock, resolution 1.00s
Event timer "RTC" frequency 32768 Hz quality 0
attimer0:  port 0x40-0x43,0x50-0x53 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
vgapci0:  port 0x3000-0x303f mem 
0xc000-0xc0ff,0xb000-0xbfff at device 2.0 on pci0

vgapci0: Boot video device
hdac0:  mem 0xc161-0xc1613fff at 
device 3.0 on pci0
xhci0:  mem 
0xc160-0xc160 at device 20.0 on pci0

xhci0: 32 bytes context size, 64-bit DMA
xhci0: Port routing mask set to 0x
usbus0 on xhci0
usbus0: 5.0Gbps Super Speed USB v3.0
pci0:  at device 22.0 (no driver attached)
hdac1:  mem 0xc1614000-0xc1617fff at 
device 27.0 on pci0

pcib1:  at device 28.0 on pci0
pci1:  on pcib1
pcib2:  at device 28.1 on pci0
pci2:  on pcib2
pci2:  at device 0.0 (no driver attached)
pcib3:  at device 28.2 on pci0
pci3:  on pcib3
pci3:  at device 0.0 (no driver attached)
pcib4:  at device 28.4 on pci0
pci4:  on pcib4
pcib5:  at device 28.5 on pci0
pci5:  on pcib5
ahci0:  mem 0xc130-0xc1301fff at device 0.0 on 
pci5

ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier not supported
ahcich0:  at channel 0 on ahci0
isab0:  at device 31.0 on pci0
isa0:  on isab0
battery0:  on acpi0
acpi_acad0:  on acpi0
acpi_lid0:  on acpi0
acpi_button0:  on acpi0
acpi_button1:  on acpi0
asmc0:  port 0x300-0x31f 
iomem 0xfef0-0xfef0 irq 6 on acpi0

uart0: <8250 or 16450 or compatible> at port 0x3f8 irq 4 flags 0x10 on isa0
uart0: non-PNP ISA device will be removed from GENERIC in FreeBSD 12.
coretemp0:  on cpu0
est0:  on cpu0
Timecounters tick every 1.000 msec
hdacc0:  at cad 0 on hdac0
hdaa0:  at nid 1 on hdacc0
pcm0:  at nid 3 on hdaa0
hdacc1:  at cad 0 on hdac1
hdaa1:  at nid 1 on hdacc1
pcm1:  at nid 18,16 and 24 on 
hdaa1

ugen0.1: <0x8086 XHCI root HUB> at usbus0
uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr