Steve Kargl writes:
> Someone broke dependence checking in /usr/src
Maybe related: Some days ago I got compile errors with
make -j12 buildworld
but not with -j6
make -j6 buildworld
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.
Renato Botelho writes:
> On 22/07/25 16:14, Poul-Henning Kamp wrote:
> > I updated to -current and ran "make delete-old-libs" today, and that
> > broke libcurl and as we all know, he doesn't live in Nebraska but
> > rather Sweden, so a lot o
David Chisnall writes:
> I've replaced jemalloc with snmalloc (to which I am a contributor)
It looks interesting, but rather than all of us having to do our
own homework, can you give us the "elevator pitch" for it ?
--
Poul-Henning Kamp | UNIX since
favor of simplicity
and minimum performance impact.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
mation (a syscall or per-thread
sysctl), the kernel validates that the kld is still present before
copyout'ing the const char *.
4. Kernel code adds calls like:
errmsg("Grammeter must be connected first")
before return (EINVAL)
Done.
--
Poul-Henning Kamp
t of the error message:
Invalid argument: Too few mazel-vanes per dingle-arm (min: 6)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Baptiste Daroussin writes:
> Listing like this is clearly not any useful, the problem we have is the
> performance changes depending on what is happening in parallel on the
> machines.
Sounds like increased memory footprint to me ?
--
Poul-Henning Kamp | UNIX since Z
-28
(The "Open Circuits" book is highly recommeded!)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
critter phk> /tmp/a.out
1 1
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
y be accidental.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
erent kinds of devices and interfaces which masqurade as "disks".
But we already have infrastructure for swap-spaces and dumping to
them, even when the kernel is pretty hosed, so one would not have
to start the project from scratch.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p
nt is here:
https://phk.freebsd.dk/misc/t14sarm.patch
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
bob prohaska writes:
> Can anybody suggest a suitable X11-wm to try on this quite
> elderly laptop? LXQT failed with a core dump, next I'll try
> twm while hoping for a better suggestion.
ctwm ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org
load 132%, current freq 3692 MHz ( 0), wanted freq 5606 MHz
But it is not entirely obvious to me that powerd actually does anything...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
> Does that print anything useful?
Yes, that's where I noticed the "gradually run slower and slower"...
Initially I thought it was some kind of thermal throttling, but leaving the
computer
idle overnight did not lead to automatic recovery, whereas reboots and as far
as I
can tell
Bob Bishop writes:
> Possibly buggy ACPI on the Thinkpad not reporting any frequency higher
> than it's actually running at?
But that wouldn't explain why restarting powerd helps ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org |
of what the (current) top frequency is and thus gradually drags the
machine slower or slower...
I have had a faint feeling for some time that this machine runs significantly
faster after a reboot, but I have no observations to support that.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
ion, so I have to remember to bring the
packages.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
ual difference left ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Michael Gmelin writes:
> @phk From which version did you upgrade?
To be totally honest: I'm not entirely sure. Probably 13.x
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
n my lawn :-)"
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
is
> ifconfig/netlink or the old kernel change from like two years(?) ago?
>
> Do you have a time window when this broke as that'll help people to
> bisect?
I have no idea, sorry, I just freebsd-updated this one box...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p.
ace, or at least make it much more obvious to them, where the problem
is to be found.
Defaulting to a /8 netmask for 192.168.x.y does not make *any* sense ever.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD si
works, so you have no
route to it ?
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
deploy RFC1918.
A third option is to default any missing netmask to /24 instead of /8,
which would be what I would personally have done in the first place.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committe
that it would be nice if this stuff (&TB) worked better.
Poul-Henning
PS: In other news: I think my main-n268442-2f4cbf459d4a kernel has
managed to suspend&resume more times with iwlwifi than I've ever
seen before :->
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p.
it to
use the if_cdce driver instead with this quirk:
/* This works much better with if_cdce than if_ure */
USB_QUIRK(LENOVO, TBT3LAN, 0x0000, 0x, UQ_CFG_INDEX_1),
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD c
D disklabels were
> historically maintained with bsdlabel. It does not yet have a
> deprecation notice - I have proposed a man page addition in
> https://reviews.freebsd.org/D43563.
By all means!
It may even be possible to shave some of the weirder bits out of
GEOM when they're go
Addendum:
I have only installed the new kernel, userland is still from dec18.
(Even if that is the cause, we should not panic on bad syscall args.)
Poul-Henning Kamp writes:
> With fresh current:
>
> commit e179d9739b1438ae9acb958f80a983eff7e3dce9
> Author: Mi
the full panic if desired...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
nce you get it set up right, it seems to get the job done...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
em will hang.
Does it make any difference if you load the module from single-user mode ?
I've seen similar problems on my T14s if I try to load it from multi-user.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer
This surprised me:
# mkdir /tmp/P
# cd /tmp/P
# touch FOO
# touch bar
# env LANG=C.UTF-8 find . -name '[A-Z]*' -print
./FOO
# env LANG=en_US.UTF-8 find . -name '[A-Z]*' -print
./FOO
./bar
Really ?!
-
Alan Somers writes:
> On Fri, Apr 7, 2023 at 2:22=E2=80=AFAM Poul-Henning Kamp
> wrote:
> > I would expect them to be limited by the serial console speed before
> > the video system speed ?
>
> That was my first guess, too. But my serial console is 115200 baud
o system.
I would expect them to be limited by the serial console speed before
the video system speed ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can a
It has served it's purpose, and GELI is better maintained.
I have added a message+sleep to gbde(8) in -current.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice
Emmanuel Vadot writes:
> On Thu, 02 Feb 2023 20:58:58 +
> "Poul-Henning Kamp" wrote:
>
> >
> > parv/FreeBSD writes:
> >
> > > > Does backlight(8) works for you?
> > >
> > > Thanks for the clue. It does!
is may be intentional: When it
comes out of screen-blanking, it goes to 100 (and reports 100).
Also happens when an external monitor is connected, which is a
bit annoying...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD com
hk> backlight
brightness: 0
critter phk> backlight 10
critter phk> backlight
brightness: 9
critter phk> backlight 20
critter phk> backlight
brightness: 19
critter phk> backlight 30
critter phk> backlight
bri
ht/backlight.c?id=e26ef41f79902991c772b59927c721aa7fa5fc64
> It's not in 13.1 but will be in 13.2
I'm running
14.0-CURRENT #0 main-n260119-7f2109f240c2: Mon Jan 16 22:54:18 UTC 2023
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
ded in
some script, which then "sometimes does not work"...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
ace size and to ignore any extra swap
> space in the swap partition.
Last I looked at that code, that is precisely what happens
if you add a too big swap-device ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | B
ist the little piece of cartilage which
can close into your ear, and hold the other end against the suspect
disk-drive, and you hear if there are any mechanical issues.
It also works for fans, motors, bikes etc.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP
I recompiled kernel, world and wireguard-kmod, and it still happens.
Have opened
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264115
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3
gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0x130
fork_exit() at fork_exit+0x88
fork_trampoline() at fork_trampoline+0x14
KDB: enter: panic
[ thread pid 0 tid 100280 ]
Stopped at kdb_enter+0x40: undefined f907827f
db>
Poul-Henning Kamp wri
I understand it, that is in "undefined instruction" territory,
so it could be anything from LLVM over compiler flags to kernel ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never at
Alan Somers writes:
> Strangers are submitting pull requests to our Github mirror, [...]
The are not "strangers".
They are enthusiastic FreeBSD users and potential future committers,
and should be treated as such!
--
Poul-Henning Kamp | UNIX since Zilo
to use it.
-s is already used to select "scan" mode.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be
break pretty much every
single script.
Alternatively [-c count] could be changed to be hex like the rest.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can
ignals.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freeb
Poul-Henning Kamp writes:
> I have two 12.2-R systems where the serial console is attached to a terminal
> server.
>
> When there are no TCP connections to the terminal server, getty soaks up 1.5%
> of the
> CPU in the kernel (sleeping in "ttyin"), ktrace sho
nal server, which raises the
modem-handshake
on the DE-9 connector, the CPU usage stops.
Anybody else seeing something like this ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute
ause disk-I/O (which may not matter with SSD's) or even how much
memory it might free, if anything.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can a
rush-hour, in order to
increase the amount of memory which can be released "without major delay".
Today that happens largely as a side effect of the periodic syncer, which does
a really bad job at it, because it still expects VAX-era hardware performance
and workloads.
--
Poul-Henni
r validity that heuristic had
was lost, and we tweaked the bogomath in various ways until it
seemed to mostly work, trusting the users for which it did not, to
tweak things themselves.
Please dont tweak the Finagle Constants again.
Rip all that crap out and come up with something fundamental
oul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mail
t's time to stop asking it and move on.
And mind you: Nothing prevents you, or any other person who cannot live
without SVN, from providing that service yourself.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer
)
This is why I am very sceptical of the recent fashion of "GREASING"
which the TLS WG have invented: To me that sounds like somebody
is allocating wiggle-room for advanced cryptographic skullduggery.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org |
that
the ranting finish guy *by fiat* had the golden tree.
The fact that people, like us, dress git up and call it a VCS does
not wash the stripes of the tiger.
To me, personally, having a distributed collaboration tool has been
much more valuable than any "pure" or "real" V
e committer in question.
Without taking a position on the merits of this design-choice, I
just want to point out that it means that timestamps should be
viewed very sceptically, since they depend on the *local* clock on
somebodys computer, not on the central repos machine.
--
Poul-Henning
ore the entire human and political
aspect of the problem.
See also: "Operation Orchestra" by yours truly.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to m
cryptography can or will protect against that.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
either remove the state-file or run "make config" again and
select UDEV.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can
When I last tried this on my T480/T3-Dock/xorg, the screen comes back, but
xrandr shows it with ever increasing names "DP-3", "DP-4" etc.
For now I've given up and use the T480's HDMI output instead.
--
Poul-Henning Kamp | UNIX since Zi
he ability to do so is largely why phone scammers can fake the calling
number when they annoy you.)
Unless somebody else know of other uses, you can kill it.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD
wn further...
My T480 runs:
FreeBSD 13.0-CURRENT #1 r364533M: Mon Aug 24 00:02:01 UTC 2020
and
drm-devel-kmod-5.3.g20200724
And I have not seen any suspend/resume problems.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC
ne the repo ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
free
Rick Macklem writes:
> Poul-Henning Kamp wrote:
> Is https://reviews.freebsd.org/D26225
> sufficient to allow me to use 1.3.6.1.4.1.2238.1.1.1 for a user@domain
> name in this otherName component of subjAltName in the X.509 cert?
> (I didn't list the UserName as t
Rick Macklem writes:
> For the NFS over TLS work, I have a need for an Internet OID.
> (I understand that IETF assigns ones for things like SNMP under
> 1.3.6.1.4.1...)
See:
/usr/share/snmp/mibs/FREEBSD-MIB.txt
--
Poul-Henning Kamp | UNIX since Zilog Ze
Michael Gmelin writes:
>
>
> > On 29. Jul 2020, at 21:29, Poul-Henning Kamp wrote:
> >
> > Michael Gmelin writes:
> >
> >> I meant which xorg driver - modesetting or Intel?
> >
> > It looks like "modesetting":
> >
&g
t;X.Org Foundation"
[ 149.039]compiled for 1.20.8, module version = 1.20.8
[ 149.039]Module class: X.Org Video Driver
[ 149.039] ABI class: X.Org Video Driver, version 24.1
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org
irmware i915/kbl_dmc_ver1_04.bin (v1.4)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_
Ed Maste writes:
> On Wed, 29 Jul 2020 at 06:20, Poul-Henning Kamp wrote:
> >
> > I just noticed that KiCad's scroll-bars flash a lot whenever the mouse
> > pointer is moved, that sounds like it could be the focus-event-flooding.
>
> For me KiCad
a3f8000, ) lost focus even
> though it didn't have it
>
> But this message exists even here. It's from wxWidgets (wx31-gtk3,
> pulled in via wxPython) and the whole wx-thingy is slightly messy...
> Anyways, I'd think this message itself is harmless.
Ok, I will disregard th
Poul-Henning Kamp writes:
>
> Michael Gmelin writes:
>
> > I might try to reproduce the issue myself later this week (if I happen
> > to find some time and nobody else comes up with a solution). Which WM
> > are you using?
>
> I just noticed tha
d, that sounds like it could be the focus-event-flooding.
I'm using ctwm :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explai
ng the issue).
Dont have any at hand this week :-(
> - try using a different WM and see if the problem persists.
I dont see any reason to think this is WM related, it happens while
the cursor stays firmly inside kicad's windows.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3
Hans Petter Selasky writes:
> Try to install "xev" and see if the log is full of events.
I only see problems in kicad, everything else, including firefox
and xev works fine (as far as I can tell)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org
s is a kicad, Xorg or libinput related.
In my Xorg log I have a lot of (rate-limited):
SynPS/2 Synaptics TouchPad: kernel bug: Touch jump detected and
discarded.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer
In message <65670198-e725-5b66-646c-5b147c943...@daemonic.se>, Niclas Zeising
writes:
>With my touchpad, ctrl left click and ctrl right click opens two
>different menus in xterm, main menu and vt font menu, respectively.
ctrl-middle should open "VT Options"
ing the trackpoint?
No, the touchpad.
>Did you set the trackpoint sysctl?
>(hw.psm.trackpoint_support=1)
That seems to default to one ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-taho
.29.0
In my case, with the default
sysctl kern.evdev.rcpt_mask=12
CTRL + middle button would not activate the menu in xterm.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attr
d a lot with my sanity on my T480
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained
ng; even if
> they would be set to "FALSE" or "NO". The presence of an option
>causes it to be honored by make(1).
That is not even close to POLA-compliance...
Obviously negative values ("false", "no") should either be reported as
errors or pre
would have thought the rather counter-intuitive
behaviour I saw yesterday, even if you had told me in those very
words that the scan-codes had changed :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since
ning I had...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freeb
Just to conclude this:
Whatever is in 13.0-CURRENT #1 r356602M has solved the problem.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can
ut that can now be disregarded as a false lead.
On this kernel I have had an instance where X got killed for
out-of-swap, at a time where that certainly should not have been
the case.
Am I the only one seeing this ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org
seems to work fine so far.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incomp
In message
, Warner Losh writes:
>We are working on making drm ports less problematic on upgrade...
Yes, I know.
But when you track current, it seems that it takes a port-reinstall
to get on that wagon...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.
der /boot
3. Reinstall drm port
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
3d:a2:e9
<3>WPA: Key negotiation completed with 6c:3b:6b:3d:a2:e9 [PTK=CCMP
GTK=CCMP]
<3>CTRL-EVENT-CONNECTED - Connection to 6c:3b:6b:3d:a2:e9 completed
[id=3 id_str=]
<3>WPA: Group rekeying completed with 6c:3b:6b:3d:a2:e9 [GTK=CCMP]
And yes, wor
l 3 drm-current-kmod 4 "
true "XXX B drm-current-kmod 2 /usr/local 3 drm-current-kmod 4 "
If I leave in the ".if !empty(module)" line in, I only get:
true "XXX A drm-current-kmod 2 /usr/local 3 drm-current-kmod 4 "
suggestions welcome...
--
Pou
m address 0:
>hdac0: Unexpected unsolicited response from address 0:
>[...]
I used to get a lot of similar-ish noise on my T480, but it seems
to have disappeared with my latest update to -CURRENT.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org
is in wrong mode.
You may have to adjust the precise "cdev" name (ls /dev/iso9660) and
vendor/product numbers (usbconfig dump_device_desc), and obviously
you have to install the usb_modeswitch port.
The -J argument seems to be what all newer Huawei devices want.
Add ifconfig_ue0=DHCP i
e pulled out per source-file...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
;use hashes" flags
in the superblocks of all filesystems they mount R/W, to limit
the amount havoc this will cause when people start playing with 13.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3
e time ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-c
hat
>take about 10 ms to return a result. So, I think that it makes sense to play
>nice with such devices by default.
>
>Probably I'll add a sysctl for that parameter while I'll be there.
sysctl or ioctl ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@free
1 - 100 of 1804 matches
Mail list logo
