Re: main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information
Jakob Alvermark writes: > I tried using the cdce driver, it gives me < 100Mb/s, while the ure > driver gets > 500Mb/s I'll take 100 stable Mb/s over 500 unstable Mb/s any day :-) (Back in my days we had only 10 Mb/s, and everybody shared them ) But yes, I agree that it would be nice if this stuff () worked better. Poul-Henning PS: In other news: I think my main-n268442-2f4cbf459d4a kernel has managed to suspend more times with iwlwifi than I've ever seen before :-> -- 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.
Re: main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information
>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP I consistently had similar problems with my 0x17ef/0x3066 "ThinkPad Thunderbolt 3 Dock MCU", but they went away after I forced 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 committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Removing fdisk and bsdlabel (legacy partition tools)
Ed Maste writes: > MBR (PC BIOS) partition tables were historically maintained with > fdisk(8), but gpart(8) has long been the preferred method for working > with partition tables of all types. fdisk has been declared as > obsolete in the man page since 2015. Similarly BSD 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 gone. -- 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.
Re: e179d973 insta-panics in nl_send_one()
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: Michael Tuexen > Date: Sat Jan 6 21:31:46 2024 +0100 > > tcpsso: support TIME_WAIT state > > I get an insta-panic as soon as any network interface comes up: > > --- trap 0xc, rip = 0x...f80d97b78, rsp = 0x... > nl_send_one() at nl_send_one+0x18/frame 0xf > nl_send_group() at nl_send_group+0x1bc/frame 0xf... > _nlmsg_flush() at _nlmsg_flush+0x37/frame 0xf... > rtnl_handle_ifevent() + 0xa1 > if_attach_internal + 0x3df > > I have a picture of 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. > -- 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.
e179d973 insta-panics in nl_send_one()
With fresh current: commit e179d9739b1438ae9acb958f80a983eff7e3dce9 Author: Michael Tuexen Date: Sat Jan 6 21:31:46 2024 +0100 tcpsso: support TIME_WAIT state I get an insta-panic as soon as any network interface comes up: --- trap 0xc, rip = 0x...f80d97b78, rsp = 0x... nl_send_one() at nl_send_one+0x18/frame 0xf nl_send_group() at nl_send_group+0x1bc/frame 0xf... _nlmsg_flush() at _nlmsg_flush+0x37/frame 0xf... rtnl_handle_ifevent() + 0xa1 if_attach_internal + 0x3df I have a picture of 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.
bl[ao]cklistd, some first impressions...
I have played around with bl[ao]cklistd on 13.2 and I am not terribly impressed: A) It would be nice to be able to specify in bl[ao]cklistd.conf that violations of a particular rule should get the IP banned for any trafic, not just the one they happened to trigger first. This is particular necessary/useful for instance when you run a "HTTP-sandwich", and spot the problem in the inner layers, but want to block access to the exterior port 443 from a process which does not hold that socket. (ie: varnish behind hitch) B) The OaM commands for pf take obscurity to a new level: pfctl -a blacklistd/80 -sr -v pfctl -a blacklistd/80 -t port80 -T show and that is just for one specific port: repeat manually for all of 22, 25, 443 etc. Going to a default "totally block IP's" policy would simplify this. C) Anchor-wildcards do not work in pfctl and the diagnostics are criminal: root@test-net:~ # pfctl -a 'blacklistd/*' -t port80 -T show pfctl: Unknown error: -1. root@test-net:~ # pfctl -t port80 -T show pfctl: Unknown error: -1. D) It would be nice to be able to have bl[ao]cklistd cooperate across machines, so that for instance all VM's on the same hardware could benefit from each others detections. E) It should be possible to inject an entry with bl[ao]cklistctl, so that simple text-based processing of logfiles can contribute too. Other than that, once 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.
Re: kabylake + drm-515-kmod/drm-510-kmod hangs
Pete Wright writes: > i've got a kabylake laptop that i've been using with drm-kmod for > several years without much hassle. after upgrading to a new CURRENT > this weekend I've found that when loading either the 510 or 515 drm-kmod > kernel modules my system 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 | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
find(1): I18N gone wild ?
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 ?! -- 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.
Re: textdumps are too slow
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, > which is faster than the low performance server grade video card. Ok, that must truly be sucky hardware... -- 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.
Re: textdumps are too slow
Alan Somers writes: > However, these servers also have about 10,000 threads > apiece, so textdumps are also slow. They take tens of minutes. > I have dual console setup: both serial and video. It seems to me that > the speed of the textdump might be limited by the video 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 adequately be explained by incompetence.
GBDE is deprecated and will be removed in 15.0
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 what can adequately be explained by incompetence.
Re: Could not change brightness anymore with i915kms & acpi_video modules c 202211
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! It does ... > > > > > > - I get the same number back via "backlight" without any arguments as > > > what I gave it earlier. There was no reporting of value being > > > subtracted by one; > > > > Sorry for the delay in reporting back. > > > > I consistently read one less back, except for 0 and 100. > > Even 50 ? # backlight brightness: 0 # backlight 50 # backlight brightness: 49 # backlight 25 # backlight brightness: 24 # backlight 75 # backlight brightness: 74 yes > So if you have, let's say brightness at 50%, and you plug an external > monitor, brightness goes up to 100% ? No, plugging and unplugging does not change the backlight. But when the screen saver has kicked in, and I wake it up again, it comes back at 100, (and reads back as 100) -- 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.
Re: Could not change brightness anymore with i915kms & acpi_video modules c 202211
parv/FreeBSD writes: > > Does backlight(8) works for you? > > Thanks for the clue. It does! It does ... > > - I get the same number back via "backlight" without any arguments as > what I gave it earlier. There was no reporting of value being > subtracted by one; Sorry for the delay in reporting back. I consistently read one less back, except for 0 and 100. (This could easily be a BIOS bug) It also looks like the "no-op" behaviour I reported previously have gone away with my latest kernel update. But I see a new behaviour, but this 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 committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Could not change brightness anymore with i915kms & acpi_video modules c 202211
Emmanuel Vadot writes: > What does backlight reports after you've unplugged the AC adaptor ? I cant make that experiment right now, I also ethernet through that connector, but I'll do it later today. But speaking of what backlight reports: critter phk> 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 brightness: 29 -- 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.
Re: Could not change brightness anymore with i915kms & acpi_video modules c 202211
Emmanuel Vadot writes: > > > Does backlight(8) works for you? > > > > Speaking of backlight(8): On my T14s, I see the following: > > > > If I set the light with backlight(8) to something, say 30%, and then > > change the power-situation, for instance by unplugging the charger, > > the backlight goes up to 100%. > > > > If I then try to set it back to 30% with backlight(8), nothing happens. > > > > If I use any other value, for instance 31%, backlight(8) does the job. > > > > I guess somewhere some code says "It's always 30%, just return" ? > > > > This might be a bit confusing if you have the intensity encoded in > > some script, which then "sometimes does not work"... > > Smells like > https://cgit.freebsd.org/src/commit/sys/dev/backlight/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.
Re: Could not change brightness anymore with i915kms & acpi_video modules c 202211
Oleksandr Kryvulia writes: > Does backlight(8) works for you? Speaking of backlight(8): On my T14s, I see the following: If I set the light with backlight(8) to something, say 30%, and then change the power-situation, for instance by unplugging the charger, the backlight goes up to 100%. If I then try to set it back to 30% with backlight(8), nothing happens. If I use any other value, for instance 31%, backlight(8) does the job. I guess somewhere some code says "It's always 30%, just return" ? This might be a bit confusing if you have the intensity encoded 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.
Re: An idea for swap partition size vs. swap space size in use handling
Mark Millard writes: > It would be nice if I could have just one swap partition > on a given boot media, one that is more than sufficient > in size for all but the biggest RAM system --but to then > be able to tell the system to just use up to the > recommended swap space 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 | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: CAM: extract HDD informations about failure/to fail?
Warner Losh writes: > It close to impossible to isolate the drive making the noise. Use a long thin piece of hard wood as a stethoscope. I keep a 30cm length of 6mm beech dowel in my tool-chest, but in a pinch you can use a pencil or the shaft from an art-brush. Press one end agaist 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/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: RockPRO64 exception 22 esr_el1 8a000000
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-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: RockPRO64 exception 22 esr_el1 8a000000
I managed to capture the full console output this time: Fatal data abort: x0:0 x1:6 x2:0 x3:0 x4:0 x5: a000beeb9b98 x6: ff x7: a0c2e100 x8: a000b79305a8 x9:0 x10:2 x11:0 x12:0 x13:0 x14: a0ce3700 x15:0 x16: e5cbfff8 (_DYNAMIC + 4a0) x17: 00589828 (sosend + 0) x18: e6707490 (ratelimit_v6 + a37280) x19:0 x20: e6707518 (ratelimit_v6 + a37308) x21:0 x22:0 x23: 14 x24: 40 x25: e6707538 (ratelimit_v6 + a37328) x26:0 x27:0 x28: a00081055d3c x29: e6707490 (ratelimit_v6 + a37280) sp: e6707490 lr: 00657724 (fib4_lookup + 40) elr:0 spsr: 6045 far:0 esr: 8604 panic: vm_fault failed: 0 error 1 cpuid = 4 time = 1652940940 KDB: stack backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x30 vpanic() at vpanic+0x174 panic() at panic+0x44 data_abort() at data_abort+0x2c4 handle_el1h_sync() at handle_el1h_sync+0x10 --- exception, esr 0x8604 (null)() at 0 ip_output() at ip_output+0x9a4 udp_send() at udp_send+0xb5c sosend_dgram() at sosend_dgram+0x4a4 sosend() at sosend+0x2c wg_send() at wg_send+0x108 wg_deliver_out() at wg_deliver_out+0x17c gtaskqueue_run_locked() at gtaskqueue_run_locked+0x17c 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 writes: > With GENERIC-NODEBUG 14.0-CURRENT #10 main-n255667-9b88ecd674a > > I reproducibly get: > > panic: Unknown kernel exception 22 esr_el1 8a00 > > Happens in: > > ip_output() at ip_output+0x9a4 > udp_send() at udp_send+0xb5c > sosend_dgram() at sosend_dgram+0x4a4 > [...] > > As 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 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.
RockPRO64 exception 22 esr_el1 8a000000
With GENERIC-NODEBUG 14.0-CURRENT #10 main-n255667-9b88ecd674a I reproducibly get: panic: Unknown kernel exception 22 esr_el1 8a00 Happens in: ip_output() at ip_output+0x9a4 udp_send() at udp_send+0xb5c sosend_dgram() at sosend_dgram+0x4a4 [...] As 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 attribute to malice what can adequately be explained by incompetence.
Re: Help wanted: volunteer yourselves in .github/CODEOWNERS
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 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.
Re: HEADSUP: i2c(8) has been washed and ironed
jake h writes: > > What about adding a new flag to enable strtoul behavior? > I have had a look at the available flag options for a potential strtoul > flag, and a flag that makes sense to me is [-s] / [--strtoul]. [-s] is not > currently being used in i2c, if we wanted 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 explained by incompetence. ___ 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"
HEADSUP: i2c(8) has been washed and ironed
I have renovated the i2c(8) program and while I belive all argument processing is 100% compatible, various undocumented aspects of the program may have changed, amongst these precisely what goes to stdout and stderr. Apologies if this breaks any of your scripts. There is one aspect of this program which I have not changed, but which bugs me utterly: All arguments are in hex, except [-c count] which is decimal. My personal preference would be if all the arguments called strtoul(3) with zero third argument, so that users can use decimal, octal or hex as they prefer, but I fear that would 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 adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: console getty uses 1.5% of CPU
Slawa Olhovchenkov writes: > T.e. if all system eat 985 ticks of CPU each second and getty eat 15 > ticks of CPU each second -- top show 1.5% for getty. That may be, but getty should not wake up at all in this situation, it should be sleeping, waiting for modem-control signals. -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: console getty uses 1.5% of CPU
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 shows no system calls. > > When a TCP connection is made to the terminal server, which raises the > modem-handshake > on the DE-9 connector, the CPU usage stops. > > Anybody else seeing something like this ? Just checked, also happens on a similar box running 13.0-ALPHA3 -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
console getty uses 1.5% of CPU
I have two 12.2-R systems where the serial console is attached to a terminal server. When there are no TCP connections to the terminal server, getty soaks up 1.5% of the CPU in the kernel (sleeping in "ttyin"), ktrace shows no system calls. When a TCP connection is made to the terminal server, which raises the modem-handshake on the DE-9 connector, the CPU usage stops. Anybody else seeing something like this ? -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [SOLVED] Re: Strange behavior after running under high load
Konstantin Belousov writes: > > B) We lack a nuanced call-back to tell the subsystems to release some of > > their memory "without major delay". > The delay in the wall clock sense does not drive the issue. I didnt say anything about "wall clock" and you're missing my point by a wide margin. We need to make major memory consumers, like vnodes take action *before* shortages happen, so that *when* they happen, a lot of memory can be released to relive them. > We cannot expect any io to proceed while we are low on memory [...] Which is precisely why the top level goal should be for that to never happen, while still allowing the freeable" memory to be used as a cache as much as possible. > > C) We have never attempted to enlist userland, where jemalloc often hang on > > to a lot of unused VM pages. > > > The userland does not add to this problem, [...] No, but userland can help solve it: The unused pages from jemalloc/userland can very quickly be released to relieve any imminent shortage the kernel might have. As can pages from vnodes, and for that matter socket buffers. But there are always costs, actual costs, ie: what it will take to release the memory (locking, VM mappings, washing) and potential costs (lack of future caching opportunities). These costs need to be presented to the central memory allocator, so when it decides back-pressure is appropriate, it can decide who to punk for how much memory. > But normally operating system does not have an issue with user pages. Only if you disregard all non-UNIX operating systems. Many other kernels have cooperated with userland to balance memory (and for that matter disk-space). Just imagine how much better the desktop experience would be, if we could send SIGVM to firefox to tell it stop being a memory-pig. (At least two of the major operating systems in the desktop world does something like that today.) > Io latency is not the factor there. We must avoid situations where > instantiating a vnode stalls waiting for KVA to appear, similarly we > must avoid system state where vnodes allocation consumed so much kmem > that other allocations stall. My argument is the precise opposite: We must make vnodes and the allocations they cause responsive to the sytems overall memory availability, well in advance of the shortage happening in the first place. > Quite indicative is that we do not shrink the vnode list on low memory > events. Vnlru also does not account for the memory pressure. The only reason we do not, is that we cannot tell definitively if freeing a vnode will cause 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 adequately be explained by incompetence. ___ 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: [SOLVED] Re: Strange behavior after running under high load
Konstantin Belousov writes: > But what would you provide as the input for PID controller, and what would be > the targets? Viewing this purely as a vnode related issue is wrong, this is about memory allocation in general. We may or may not want a PID regulator, but putting it on counts of vnode would not improve things, precisely, as you point out, because the amount of memory a vnode ties up has enormous variance. We should focus on the end goal: To ensure "sufficient" memory can always be allocated for any purpose "without major delay". Architecturally there are three major problems: A) While each subsystem generally have a good idea about memory that can be released "without major delay", the information does not trickle up through a summarizing NUMA aware tree. B) We lack a nuanced call-back to tell the subsystems to release some of their memory "without major delay". C) We have never attempted to enlist userland, where jemalloc often hang on to a lot of unused VM pages. As far as vnodes go: It used to be that "without major delay" meant "without disk-I/O" which again led to the "dirty buffers/VM pages" heuristic. With microsecond SSD backing store, that heuristic is not only invalid, it is down-right harmful in many cases. GEOM maintains estimates of per-provider latency and VM+VFS should use that to schedule write-back so that more of it happens outside 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-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 mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [SOLVED] Re: Strange behavior after running under high load
Mateusz Guzik writes: > It is high because of this: > msleep(_sig, _list_mtx, PVFS, "vlruwk", hz); > > i.e. it literally sleeps for 1 second. Before the line looked like that, it slept on "lbolt" aka "lightning bolt" which was woken once a second. The calculations which come up with those "constants" have always been utterly bogus math, not quite "square-root of shoe-size times sun-angle in Patagonia", but close. The original heuristic came from university environments with tons of students doing assignments and nethack behind VT102 terminals, on filesystems where files only seldom grew past 100KB, so it made sense to scale number of vnodes to how much RAM was in the system, because that also scaled the size of the buffer-cache. With a merged VM buffer-cache, whatever 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 fundamentally better. -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: fsck strange output
Rozhuk Ivan writes: > Disk is 100% alive, got same on other HW. A disk can be alive and still have individually unreadable sectors, that is, IMO, the most common failure mode. Try: recoverdisk -v /dev/whatever That will attempt to read all sectors on the disk. -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: git non-time-sequential logs
David G Lawrence writes: >Why is it that the project can't continue to operate the SVN server in > addition to Git, gatewaying with -current as is being done with 12-stable? David, With all due respect: That question has been asked and answered so many times now, that it'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 | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: HEADS UP: FreeBSD src repo transitioning to git this weekend
John-Mark Gurney writes: > SHAttered[1] (2017) created two valid PDF documents which had the same > SHA-1 hash. The issue was that they were able to choose the entire > document. Shattered is less impressive when you take into account that you can stuff as much much garbage into a PDF file as you need, without affecting the files normal function. Compact data formats, formats which leave no wiggle-room and do not offer extension-space for "attic-junk", are much harder to produce *meaningful* collisions for. (I take no opinion in where git is on that spectrum.) 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 | 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 mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: git non-time-sequential logs
Alan Somers writes: > I'll be more frank than phk: it sucks. Git's commit dates are basically > useless. Git is not built as, or to be, version control. Git is built to be distrbuted collaboration tool. The designed-in version control aspect was always, and only, 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" VCS ever were. -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: git non-time-sequential logs
John Kennedy writes: > This might be perfectly natural and just new to me, but when I look at the > git logs this morning I see things like this (editing by me): > > Date: Mon Jan 4 17:30:00 2021 +0100 > Date: Mon Dec 14 18:56:56 2020 +0100 > Date: Tue Dec 15 13:50:00 2020 +0100 > Date: Mon Jan 4 16:23:10 2021 +0100 > > I've always assumed that the "Date:" there was when the commit happened, It is, but it is the time it was committed in the first git repos it was committed to, in this case the repos of the 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 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 mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
grarpamp writes: > > No amount of cryptography can or will protect against that. > > Though it can help attribute that to a source, No. You would end up with the committer saying "it came in as a bug-report, I looked at it, and it looked sensible so I committed it." Unless you are going to *enforce* (how?!) that all committers only commit patches they received under full cryptographic & biometric custody from verified communications partners, it will always end up being unattributable. Even if you were able to pin the blame on a particular committer, that person would simply cease to exist, because it was only a cover identity to begin with. > > As interesting as this thread has been (not!) > > Contrare. > [...] > Defense in depth. ... is a lot harder than most IT-people realize, because most IT-people almost invariably ignore 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 malice what can adequately be explained by incompetence. ___ 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: HEADS UP: FreeBSD src repo transitioning to git this weekend
As interesting as this thread has been (not!), let me remind everybody that the cheapest, easiest and most efficient and profitable way for a Nation State Actor to trojan the FreeBSD code-base, is to assign an employee to a deniable job, and have them become a FreeBSD committer. No amount of 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. ___ 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: Issues with USB-C external monitors
Ali Abdallah writes: > Sorry for the noise, you can the patches at the following link: > > https://github.com/Alix82/FreeBSD-xorg-drm-hotplug Thanks a lot Ali! With these patches my T480+TB3 dock works, with the following footnotes: I have disabled "TB3 Bios assist" in the BIOS and use a USB-C cable instead of the TB-3 cable, to keep TB3 out of this. At some point, probably years ago, I ran "make config" in x11-servers/xorg-server, and the state-file left in /var/db/ports kept UDEV disabled, despite the patch to Makefile in the bundle above. You can 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 adequately be explained by incompetence. ___ 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: Issues with USB-C external monitors
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 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 mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Is "/usr/bin/sscop" still relevant? (related to ATM)
mj-mailingl...@gmx.de writes: > Is "/usr/bin/sscop" still relevant? The sscop tool implements the Q.2110 > transport protocol, [...] Q.2110 is ATM over ISDN B-channels, and the only use-case I have ever heard about is to run SS7 signalling over ISDN-30 connections. (The 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 since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: Wake from sleep kinda broken-ish? (ThinkPad Carbon X1 6th gen)
Warner Losh writes: > I too can report this for my Lenovo Yoga running code as of September 13, > but with manu's latest drm... It used to work fine, but my last build on > the system was from May. Most likely a new panic in that code path, but > I've not chased down 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 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: Please check the current beta git conversions
Goran Mekić writes: > While I can clone src nicely, it is very slow in Serbia/Europe. The best > speed I got is 1.45MB/s but it's mostly around 700kB/s (still cloning). I was about to ask about that: Any guidance on amount of diskspace and how long it takes to clone 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. ___ 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: Does FreeBSD have an assigned Internet OID?
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 the first item of the subtree. Should I?) You should add a comment about how suballocations (if allowed) happens under that branch. > Do I need to update the date/time for LAST-UPDATED and REVISION > when I commit it, I'd guess? Yes please. -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Does FreeBSD have an assigned Internet OID?
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 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 mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: KiCad is horrible on CURRENT
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": > > > > You could try installing xf86-video-intel and see if that makes a difference > (in terms of artifacts, can't imagine it has anything to do with the focus > issue?!). That seems to have taken care of the scroll-bar flickering, will see how it goes. -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: KiCad is horrible on CURRENT
Michael Gmelin writes: > I meant which xorg driver - modesetting or Intel? It looks like "modesetting": [ 149.032] (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so [ 149.038] (II) Module glx: vendor="X.Org Foundation" [ 149.038]compiled for 1.20.8, module version = 1.0.0 [ 149.038]ABI class: X.Org Server Extension, version 10.0 [ 149.038] (==) Matched intel as autoconfigured driver 0 [ 149.038] (==) Matched modesetting as autoconfigured driver 1 [ 149.038] (==) Matched scfb as autoconfigured driver 2 [ 149.038] (==) Matched vesa as autoconfigured driver 3 [ 149.038] (==) Assigned the driver to the xf86ConfigLayout [ 149.038] (II) LoadModule: "intel" [ 149.038] (WW) Warning, couldn't open module intel [ 149.038] (EE) Failed to load module "intel" (module does not exist, 0) [ 149.038] (II) LoadModule: "modesetting" [ 149.038] (II) Loading /usr/local/lib/xorg/modules/drivers/modesetting_drv.so [ 149.039] (II) Module modesetting: vendor="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 | 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 mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: KiCad is horrible on CURRENT
Michael Gmelin writes: > Which driver are you using? drm-devel-kmod-5.3.g20200724 dmesg: drmn0: on vgapci0 vgapci0: child drmn0 requested pci_enable_io vgapci0: child drmn0 requested pci_enable_io [drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-19). __pm_runtime_resume not implemented -- see your local kernel hacker pm_runtime_mark_last_busy not implemented -- see your local kernel hacker __pm_runtime_suspend not implemented -- see your local kernel hacker Failed to add WC MTRR for [0x8000-0x9fff]: -22; performance may suffer [drm] Got stolen memory base 0x7d80, size 0x200 [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] Driver supports precise vblank timestamp query. [drm] Connector eDP-1: get mode from tunables: [drm] - kern.vt.fb.modes.eDP-1 [drm] - kern.vt.fb.default_mode [drm] Connector DP-1: get mode from tunables: [drm] - kern.vt.fb.modes.DP-1 [drm] - kern.vt.fb.default_mode [drm] Connector HDMI-A-1: get mode from tunables: [drm] - kern.vt.fb.modes.HDMI-A-1 [drm] - kern.vt.fb.default_mode [drm] Connector DP-2: get mode from tunables: [drm] - kern.vt.fb.modes.DP-2 [drm] - kern.vt.fb.default_mode [drm] Connector HDMI-A-2: get mode from tunables: [drm] - kern.vt.fb.modes.HDMI-A-2 [drm] - kern.vt.fb.default_mode pm_runtime_get_if_in_use not implemented -- see your local kernel hacker kmem_cache_shrink not implemented -- see your local kernel hacker kmem_cache_shrink not implemented -- see your local kernel hacker kmem_cache_shrink not implemented -- see your local kernel hacker kmem_cache_shrink not implemented -- see your local kernel hacker register_oom_notifier not implemented -- see your local kernel hacker kmem_cache_shrink not implemented -- see your local kernel hacker kmem_cache_shrink not implemented -- see your local kernel hacker kmem_cache_shrink not implemented -- see your local kernel hacker sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)! [drm] Initialized i915 1.6.0 20190619 for drmn0 on minor 0 register_acpi_notifier not implemented -- see your local kernel hacker async_schedule is dodgy -- see your local kernel hacker pm_runtime_set_autosuspend_delay not implemented -- see your local kernel hacker __pm_runtime_use_autosuspend not implemented -- see your local kernel hacker async_synchronize_cookie not implemented -- see your local kernel hacker acpi_video0: on vgapci0 WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 13.0. VT: Replacing driver "vga" with new "fb". [drm] Reducing the compressed framebuffer size. This may lead to less power savings than a non-reduced-size. Try to increase stolen memory size if available in BIOS. start FB_INFO: type=11 height=1080 width=1920 depth=32 cmsize=16 size=14745600 pbase=0x8004 vbase=0xf8008004 name=drmn0 flags=0x0 stride=10240 bpp=32 cmap[0]=0 cmap[1]=7f cmap[2]=7f00 cmap[3]=c4a000 end FB_INFO drmn0: fb0: i915drmfb frame buffer device drmn0: successfully loaded firmware image with name: i915/kbl_dmc_ver1_04.bin [drm] Finished loading DMC firmware 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. ___ 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: KiCad is horrible on CURRENT
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's scroll bars are hidden, and flash briefly on and off > while the pointer's moving. This is with a USB mouse (trackball) > attached, and xfwm4. I'm seing similar stuff, and sometimes I am also seeing some screen artifacts which could implicate DRM :-( -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: KiCad is horrible on CURRENT
Christoph Moench-Tegeder writes: > KiCad maintainer writing. Many thanks maintaining KiCad, it's one of the tools I cannot live without. > > One of the few diagnostics I see related to this is: > > > > 07:33:34: Debug: window wxScrolledWindow(0x81a3f8000, ) 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 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. ___ 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: KiCad is horrible on CURRENT
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 that KiCad's scroll-bars flash a lot whenever the mouse > pointer is moved, that sounds like it could be the focus-event-flooding. I just checked: my x11-server is also -current as of sunday, so that D245854 patch is in place. -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: KiCad is horrible on CURRENT
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 that KiCad's scroll-bars flash a lot whenever the mouse pointer is moved, 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 explained by incompetence. ___ 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: KiCad is horrible on CURRENT
Michael Gmelin writes: > This sounds a bit like it could be related to > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245854 That sounds like something in the same zip code. > Two easy things you could check: > - try connecting a usb mouse (to rule out synaptics being 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.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 mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: KiCad is horrible on CURRENT
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 | 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 mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
KiCad is horrible on CURRENT
I updated to current three days ago: 13.0-CURRENT #0 r363533M: Sun Jul 26 08:39:48 UTC 2020 When I start cad/kicad (which I have not done in some time), the gui is horribly lagging and often downright confused about the cursors whereabouts. I've tried switching between "fall-back" and "accellerated" in kicad, but there does not seem to be any qualitative difference. One of the few diagnostics I see related to this is: 07:33:34: Debug: window wxScrolledWindow(0x81a3f8000, ) lost focus even though it didn't have it I have no idea if this 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 | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: Weird mouse behaviour
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" -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Weird mouse behaviour
In message <7549a5dd-3edc-4efd-bc0b-4d67232b4...@grem.de>, Michael Gmelin writes: >> In my case, with the default >> >>sysctl kern.evdev.rcpt_mask=12 >> >> CTRL + middle button would not activate the menu in xterm. >> > >Are you using 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-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: Weird mouse behaviour
In message <6dfad31c-68f2-c38f-28ac-0696e73b4...@daemonic.se>, Niclas Zeising writes: >On 2020-04-27 08:03, Malcolm Matalka wrote: >> I saw that there was another thread on this and I wanted to throw my >> experience in: my mouse was sluggish and tap-to-click did not work. I >> set the evdev mask back to 3 and it worked. >> >> I am on a Dell XPS 13. > >Hi! >Is this on CURRENT? When using X? >Can you verify that you have xf86-input-libinput installed? In my case yes, this is CURRENt and I have xf86-input-libinput-0.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 attribute to malice what can adequately be explained by incompetence. ___ 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: Weird mouse behaviour
In message <86imhlv518@gmail.com>, Malcolm Matalka writes: >I saw that there was another thread on this and I wanted to throw my >experience in: my mouse was sluggish and tap-to-click did not work. I >set the evdev mask back to 3 and it worked. Thanks! That helped 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 by incompetence. ___ 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: buildkernel failure because ctfconvert not installed
In message <9f03fb79-a0ad-3c11-9a50-bc7731882...@fastmail.com>, Yuri Pankov
writes:
>Trond Endrestøl wrote:
>> On Thu, 9 Apr 2020 10:56+0200, Gary Jennejohn wrote:
>>
>>> OK, I figured it out.
>>>
>>> I used to have MK_CTF=no in src.conf, but I recently changed it to
>>> WITH_CTF=no.
>>
>> It's either WITH_xxx=yes or WITHOUT_xxx=yes.
>
>Or even WITH_xxx= or WITHOUT_xxx=, src.conf(5) explicitly states that
>value is NOT checked:
>
>The values of variables are ignored regardless of their setting; 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 preferably be respected.
PS: [This is not the bikeshed you are looking for]
--
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@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: New Xorg - different key-codes
In message , Niclas Zeising w rites: >This has to do with switching to using evdev to handle input devices on >FreeBSD 12 and CURRENT. There's been several reports, and suggested >solutions to this, as well as an UPDATING entry detailing the change. I don't think I 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 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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"
New Xorg - different key-codes
I just updated my laptop from source, and somewhere along the way the key-codes Xorg sees changed. I have the right Alt key mapped to "Multi_key", which is now keycode 108 instead of 113, which is now arrow left instead. I hope this email saves somebody else from the frustrating morning 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. ___ 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: M_TEMP trouble in 13.0-CURRENT #0 r355131M
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 adequately be explained by incompetence. ___ 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"
M_TEMP trouble in 13.0-CURRENT #0 r355131M
I noticed yesterday that M_TEMP stats are screwed up, and rebooted my laptop for reasons of safety. However, it's back again now: critter phk> vmstat -m | grep temp temp 18446744073709546036 18014398509476380K - 963239 16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536 FreeBSD critter.freebsd.dk 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r355131M: Wed Nov 27 16:44:48 UTC 2019 r...@critter.freebsd.dk:/usr/obj/freebsd/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 I mentioned this on IRC yesterday and noted I had a "disk full" on a tmpfs mount, but 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 | 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 mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS with 32-bit, non-x86 kernel
In message , Ian Le pore writes: >There have also been some bug reports as recently as 2017 indicating >that people are still doing this on small armv7 systems. I actually have a potential off-site backup server in my lab right now, consisting of a BeagleBoneBlack and two USB disks, seems to work. The basic scheme is a cronjob which: zfs import inl run various rsyncs zfs snapshot -r inl@$YYMMDDHHMM zfs export inl The import/export is so the USB disks spin down. Not sure if ZFS will croak the 512M RAM on other workloads, but for this one it 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 incompetence. ___ 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: Booting anything after r352057 kills console
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.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 mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Booting anything after r352057 kills console
In message <11db909b-57ee-b452-6a17-90ec2765c...@acm.org>, Thomas Laus writes: >Where do I go from here? The computer is an Intel i5 Skylake with >onboard graphics. Based on personal experience: 1. Deinstall drm ports 2. Remove all remaining drm related files under /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. ___ 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: wlan can't discover known networks after relocating
In message <707bcd3f-fa6b-82eb-fa8f-09c4b800f...@freebsd.org>, Johannes Lundber g writes: >For a long time now I have had this problem with iwm and wlan0. Whenever >I move between work and home it won't reconnect automatically and I have >to do wlan0 scan manually for it to pick up the different network. I suffer from the dreaded "reason=0" when I move inside my house: > scan OK <3>CTRL-EVENT-SCAN-RESULTS <3>Trying to associate with 6c:3b:6b:3d:a2:e9 (SSID='Palombia' freq=2452 MHz) <3>CTRL-EVENT-DISCONNECTED bssid=6c:3b:6b:3d:a2:e9 reason=0 <3>CTRL-EVENT-SCAN-RESULTS <3>Trying to associate with 6c:3b:6b:ab:ce:d4 (SSID='Palombia' freq=2412 MHz) <3>Associated with 6c:3b:6b:ab:ce:d4 a2:e9 is the loudest AP here in my office, but my I have been in the other end of the house iwn consistently fails to associate with it and and keeps picking the weaker AP in the far end. Eventually (hours!) it disconnects from the weaker ap, also with "reason=0" and gets it right: <3>WPA: Group rekeying completed with 6c:3b:6b:ab:ce:d4 [GTK=CCMP] <3>CTRL-EVENT-DISCONNECTED bssid=6c:3b:6b:ab:ce:d4 reason=0 <3>CTRL-EVENT-SCAN-RESULTS <3>Trying to associate with 6c:3b:6b:3d:a2:e9 (SSID='Palombia' freq=2452 MHz) <3>Associated with 6c:3b:6b: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, working roaming would be nice too... -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Weird goings on with make::empty()
On:
Repository Root: svn+ssh://repo.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 351809
I built a kernel, but drm-current-kmod did not get compiled
from the new world order in /usr/local/sys/modules
Debugging I ended up doing this to src/sys/conf/kern.post.mk:
Index: sys/conf/kern.post.mk
===
--- sys/conf/kern.post.mk (revision 351809)
+++ sys/conf/kern.post.mk (working copy)
@@ -77,12 +77,14 @@
${target:S/^reinstall$/install/:S/^clobber$/cleandir/}
.endif
.for module in ${LOCAL_MODULES}
-.if !empty(module)
+ true "XXX A $(module) 2 ${LOCALBASE} 3 ${LOCAL_MODULES} 4
${MODULES_WITH_WORLD}"
+#.if !empty(module)
+ true "XXX B $(module) 2 ${LOCALBASE} 3 ${LOCAL_MODULES} 4
${MODULES_WITH_WORLD}"
@${ECHODIR} "===> ${module}
(${target:S/^reinstall$/install/:S/^clobber$/cleandir/})"
@cd ${LOCAL_MODULES_DIR}/${module}; ${MKMODULESENV} ${MAKE} \
DIRPRFX="${module}/" \
${target:S/^reinstall$/install/:S/^clobber$/cleandir/}
-.endif
+#.endif
.endfor
.endif
.endfor
This gives me the expected output from buildkernel:
true "XXX A drm-current-kmod 2 /usr/local 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...
--
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@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: hdac0: Unexpected unsolicited response from address 0: 00000000
In message <20190821132305.1c11bb9c@hermann>, "Hartmann, O." writes: >on a Lenovo E540 I get this weird error since I used 12-STABLE/CURRENT >[...] >hdac0: Unexpected unsolicited response from address 0: >hdac0: Unexpected unsolicited response from 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 | 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 mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Huawei mobile/wifi gadgets: HOWTO
This seems to be sort of a FAQ, and I had a chance to spend a couple of
quality minutes with one of these devices.
The fundamental problem is that they come up as a CD device, with Windows
software to do whatever it takes.
Sending them a magic USB command enables other interfaces, including
serial/modem, USB ethernet etc.
The remaining issue is: How to get FreeBSD do send the magic string?
A file in /etc/devd along these lines will do it:
notify 1000 {
match "system" "GEOM";
match "type""CREATE";
match "cdev""iso9660/MOBILEWIFI";
action "/usr/local/sbin/usb_modeswitch -v 0x12d1 -p 0x15ca -J";
};
It works by reacting to the CD device appearing, which seems to be a
sure-fire indication that the device 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 in /etc/rc.conf, and you should be set.
--
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@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: kernel module code coverage
In message , Slava Shwartsman writes: >Apparently, Bullseye are dropping support for FreeBSD. > >We are looking for an alternative for kernel module run time analysis. >Mostly interested in code coverage (for now). > >Any suggestions that work for you? Back in early days, I fixed it so that all the BB-counter blocks in the kernel were linked into a list which could be read out through /dev/(k)mem, and I belive I added a program to do that, named something like "kernbb". Today I would probably have made a subtree under sysctl where the counters could be 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. ___ 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: supeblock hash failure - CURRENT wrecking disks
In message <39fb31e6-a8ec-484c-b297-39c19a787...@gmail.com>, Enji Cooper writes : There is an "interesting" failure-mechanism when you move a disk between 13/current and older systems which do not support ufs-hashes. It will be prudent to make 11 and 12 clear the "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-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: i2c bit banging timeout for SCL
In message , Warner Losh writes: >The only issue, really, is that this timeout is a busy loop and there may >be I/O bus contention introduced on these systems. Does it have to be a busy loop for the entire duration ? Spin for the median, timeout+poll for the rest of the 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-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: i2c bit banging timeout for SCL
In message , Andriy Gapon writes: >iicbb driver has a hardcoded timeout that defines how long the driver waits for > SCL line to go high after the driver releases it to float. Sometimes slaves >hold the line low until they are ready to continue with the communication. >As a side note, the timeout means that the driver just goes on as if the line >became high. Maybe it should produce an error instead. > >Anyway, I would like to increase the current timeout of 100 x 10us to 1000 x >10us. The rationale is that there are many slave devices, like sensors, that >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...@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 mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Inconsistent behavior with wpa / devd / network interfaces
This sounds like handbook material ? -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Danish FreeBSD Developer hates jews collectively
In message <49cfcff55fe21d5d01df916e9f953...@redchan.it>, ossobserver@redchan.i t writes: You forgot to include this link: http://phk.freebsd.dk/sagas/israel/ -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ACPI Error: No handler for Region [ECOR]
In message <10399.1543270...@critter.freebsd.dk>, "Poul-Henning Kamp" writes: >>I'm seeing it on my ThinkPad x230 as well > >and on T480 running 13.0-CURRENT r340932M as well: And seems to be gone with this kernel: 13.0-CURRENT r341006M Havn't tried the ones in between. -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Hole-punching, TRIM, etc
In message , Warner Losh writes: >On a raw device it would be translated into a BIO_DELETE command directly, >correct? We already have ioctl(DIOCGDELETE) for that. newfs(8) uses it. -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
armv7 BETA3 panics when usb-disk inserted
= 0x swi_exit() at swi_exit pc = 0xc05cbcd4 lr = 0xc05cbcd4 (swi_exit) sp = 0xc35dce48 fp = 0x -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ctm(1) deprecation in the FreeBSD base system?
In message , Warner Losh writes: >> > I think Julian Stacy is still running CTM generation ? >> >> Ah, yes, that brought back enough brain cells, >> confirmed that is who I saw with ctm usage. > >Do we need it in base? Or can we make it a port? Absolutely make it a 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. ___ 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: ctm(1) deprecation in the FreeBSD base system?
In message <201810221957.w9mjvdxx012...@pdx.rh.cn85.dnsmgr.net>, "Rodney W. Gri mes" writes: >I do not know that other than I do know that I have seen >one data point in the last 14 days of a user who was infact >using ctm though I can not associate a username/email address >with that memory. > >A search of the last 30 days of @freebsd.org public mail >may yield a hit. I think Julian Stacy is still running CTM generation ? -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Not sure if this is an important bug...
In message <201810082255.w98mtn1p033...@pdx.rh.cn85.dnsmgr.net>, "Rodney W. Gri mes" writes: >> I tried running 12.0-BETA8 under bhyve on a Phenom-II+11.2 box and >> it explodes because of an unemulated instruction: >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232081 >> >> I have no idea what importance this has in relation to releasing 12.0 > >Can you try an earlier alpha for me? Specifically A3, I think this >may be some hand optimization of memmov stuff that included a new >instruction that we did not use before. ALPHA[3-6] works, ALPHA[78] fails as reported in the ticket -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Not sure if this is an important bug...
I tried running 12.0-BETA8 under bhyve on a Phenom-II+11.2 box and it explodes because of an unemulated instruction: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232081 I have no idea what importance this has in relation to releasing 12.0 -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Should 11.2-p4+bhyve be able to run 12.0-ALPHA8-amd64 ?
On a 11.2-p4 host, trying to run 12.0-ALPHA8-amd64 under bhyve. Right after console emits: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 4 package(s) x 1 core(s) arc4random: no preloaded entropy cache Bhyve quits with: Failed to emulate instruction [0x0f 0xae 0x3b 0x8b 0x04 0x25 0xf8 0x5d 0xb8 0x81 0x48 0x01 0xc3 0x4c 0x39] at 0x8104abb0 Abort trap According to a disassembler "0f ae 3b" is "clflush byte ptr [%rbx]" -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: devmatch sideeffec: No sound
In message <20180930114717.0cfb5e6cdc881f39dbf4b...@bidouilliste.com>, Emmanuel Vadot writes: >On Sun, 30 Sep 2018 07:51:38 + >> Yet to be discovered workaround: Prioritize sound devices, when >> there are multiple. > > hw.snd.default_unit=XXX > hw.snd.default_auto=0 > > in /etc/sysctl.conf should do the trick. Will try. >> This kind of thing may cause some support-work when 12 comes out... > > The only new "issue" is that now with devmatch every hardware got its >driver loaded, so on this case this would cause "problems" but for >other it solve the problem of finding which driver you need to load to >use your usb/pci/blah driver. Ohh, absolutely! Devmatch is a great improvement over "kldload /boot/kernel/*.ko" But until now I had not expected any sideeffects in the "stopped working" category. -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
devmatch sideeffec: No sound
HW: Thinkpad T480 with T3 Dock. SW: -current, r338952 With devmatch enabled in /etc/rc.conf (the default0, snd_uaudio gets loaded automatically and finds the audio stuff in the dock, which is connected to a screen output(s) I do not use. Firefox ends up with /dev/dsp2.0 which goes there, and as a result I get no sound through the laptops speakers where I expect it. Obvious workaround: Disable devmatch. Yet to be discovered workaround: Prioritize sound devices, when there are multiple. This kind of thing may cause some support-work when 12 comes out... -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Hooking RPi PWM driver into tree
I wrote a device driver for PWM on the RPi's, but I have not yet hooked it into the tree, because I'm unsure how we would want that. I personally think by default it should be a module which is only compiled for RPi kernels, but how does one do that ? (Needless to say, it should also be possible to compile it into the kernel for an RPi, but I know how to do that :-) And do we want it to live in sys/modules/rpi_pwm or sys/modules/rpi/pwm ? -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Onewire on BeagleBoneBlack example ?
In message <1513812077.77378.10.ca...@freebsd.org>, Ian Lepore writes: >For years, folks have been espousing the value of getting people hooked >on freebsd via rpi and beaglebone, I'm personally not that convinced about the value, for a number of complex and interlocking reasons and I was merely noting that I could see why it isn't happening - value or not. 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. ___ 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: Onewire on BeagleBoneBlack example ?
In message <97808.1513774...@critter.freebsd.dk>, Poul-Henning Kamp writes:
>Does anybody have a working example of getting onewire sensors
>working on beagleboneblack ?
Ok, with some hints from the usual IRC channel I managed to figure it out:
cd /boot/dfb
mv am335x-boneblack.dtb _am335x-boneblack.dtb
dtc -I dtb -O dts -o am335x-boneblack.dts _am335x-boneblack.dtb
patch am335x-boneblack.dts (see below)
dtc -I dts -O dtb -o am335x-boneblack.dtb am335x-boneblack.dts
echo "owc_load=YES" >> /boot/loader.conf
echo "ow_load=YES" >> /boot/loader.conf
echo "ow_temp_load=YES" >> /boot/loader.conf
The patching of am335x-boneblack.dts is black magic, but this patch
worked for me:
root@beaglebone:/boot/dtb # diff -u *dts
--- _am335x-boneblack.dts 2017-07-21 11:24:18.229468000 +
+++ am335x-boneblack.dts2017-07-21 19:19:35.166447000 +
@@ -2149,6 +2149,14 @@
status = "disabled";
};
+ // first number (0x36, 0x4b) refers to "phandle" of gpio#
+ // second number is bit on that *cpu* GPIO
+ // not sure if the third matter, but 1 works.
+ onewire0 { compatible = "w1-gpio"; gpios = <0x36 30 1>; }; //
P9::11
+ onewire1 { compatible = "w1-gpio"; gpios = <0x36 31 1>; }; //
P9::13
+ onewire2 { compatible = "w1-gpio"; gpios = <0x4b 16 1>; }; //
P9::15
+ onewire3 { compatible = "w1-gpio"; gpios = <0x36 3 1>; }; //
P9::21
+
__symbols__ {
l4_wkup = "/ocp/l4_wkup@44c0";
wkup_m3 = "/ocp/l4_wkup@44c0/wkup_m3@10";
Either device tree overlays just plain don't work, I can't figure out how to
write them (p=0.5).
I sure get why getting people hooked on FreeBSD with RPi's and
BeagleBones is not happening :-/
--
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@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Onewire on BeagleBoneBlack example ?
Does anybody have a working example of getting onewire sensors working on beagleboneblack ? -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r325250: panics on USB stick insert
I updated to r325250M amd64 last night, and now my laptop panics in geom when I plug my mobile phone in. I'll try to get a panic message when I'm in less of a hurry... -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cve-2017-13077 - WPA2 security vulni
In message <calm2memawo7q7gnylqzpovpvp3dqun5s4aa4j8cw2nk8g6u...@mail.gmail.com> , blubee blubeeme writes: >Does anyone on FreeBSD know if it's affected by this? >https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-13077 It is, same as Linux, we use the same wpa_supplicant software -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Removal of catman from base
In message
<canczdfoxe8haae+pvtvousyttyg7rgxcummwrak0lp0tgu9...@mail.gmail.com>, Warner
Losh writes:
>Back in school, our SunOS 3, SunOS 4 and VAX running BSD 4.{2,3} we had to
>run a special ditroff [...]
ditroff = Device Independent Troff
The original troff were hardwired to the C/A/T photo-typesetter which
by the time of SVR bare existed in the market anymore.
Ditroff took a configfile and emitted a documented output, which a
device-dependent postprocessor would convert into something the
actual hardware understood.
I think I wrote about a dozen ditroff config+preprocessor combos during
the late 1980ies.
--
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@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Removal of catman from base
In message <alpine.bsf.2.21.1709121210140.54...@orthanc.ca>, Lyndon Nerenberg writes: >> That was actually not why catman was brought into the world: ATT/USL >> thought text-processing was The Goods so they unbundled it base SVR >> and invented catman to make up for the missing nroff. > >Not quite. They (AT) sold the rights to sell typeset manuals to some >publishing house (I forget which), at which point they stopped shipping >the *roff source for the manpages on the source tapes. Instead, you got >pre-formatted "cat" pages on the source tape. I think this happened >starting with SVR3. I'm pretty sure that SVR1 had catman and roff was an extra and somewhat pricey software package. -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Removal of catman from base
In message <20170912184200.gd99...@gmail.com>, Gordon Tetlow writes: >With modern hardware, it doesn't seem to be necessary to have pre-formatted >man pages as rendering them is short enough to not be noticeable. That was actually not why catman was brought into the world: ATT/USL thought text-processing was The Goods so they unbundled it base SVR and invented catman to make up for the missing nroff. -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [bmake] bmake sigint handling causing tty corruption
In message <20170718205700.GA2131@hades.panopticon>, Dmitry Marakasov writes: >In short, when FreeBSD ports options dialog is interrupted by Ctrl+C, >there's chance of sporadic terminal corruption. They are not always >reproducible and seem to be dependent on a machine, shell, terminal, >tmux used, but are not tied to any specific configuration. I've noticed another quirk which may be related: Start vi(1) on some file. Type !some_command_producing_significant_output | less Ctrl-C This leaves the less(1) alive and competing vi(1) for the terminal in a most unworkable and annoying fashion. -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: regression suspend/resume on Lenovo T420
In message <20170514193006.GA1298@brick>, Edward Tomasz =?utf-8?Q?Napiera=C5=82
a?= writes:
>I've tried to verify that, and sadly it wasn't it for me. The commit
>that does break resume for me is r316767. The current -CURRENT with
>this one commit reverted ("svn merge -c -r316767 .") suspends and resumes
>correctly, at least in VT; I decided to take X out of the picture for
>now.
I can confirm that this also makes resume work on my T430s running:
FreeBSD 12.0-CURRENT #0 r318250M amd64
--
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@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r316958: booting a server takes >10 minutes!
In message <20170415160916.gy1...@albert.catwhisker.org>, David Wolfskill write s: >And I understand that the Cloudflare/f-root server issue isn't quite >that recent: "The new f-root servers appeared around two weeks ago" And isn't the zone cache expiry time around two weeks as well ? -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r316958: booting a server takes >10 minutes!
>Recent CURRENT running on a server makes the system booting in multiuser mode >booting >incredibly slow! On a machine, before I interrupted the booting process >hanging in >starting postgresql 9.6.2 server, it took > 10 minutes. Maybe this ticket ? https://lists.freebsd.org/pipermail/freebsd-ports/2017-April/108144.html -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: arm64 vs. jemalloc and swapping in and out, sh/su examples: being swapped out leads to later Failed assertion: "tsd_booted" after being swapped in
In message <41a51b66-4290-48e0-a3e3-aeb809b27...@dsl-only.net>, Mark Millard writes: >The evidence is that process-memory is trashed and so likely continued >operation of any previously swapped-out processes is unreliable. I can confirm process corruption on RPi3 as of r313567. -- 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
