Re: An attempted test of main's "git: 2ad756a6bbb3" "merge openzfs/zfs@95f71c019" that did not go as planned
On Sep 4, 2023, at 22:06, Mark Millard wrote: > On Sep 4, 2023, at 18:39, Mark Millard wrote: > >> On Sep 4, 2023, at 10:05, Alexander Motin wrote: >> >>> On 04.09.2023 11:45, Mark Millard wrote: On Sep 4, 2023, at 06:09, Alexander Motin wrote: > per_txg_dirty_frees_percent is directly related to the delete delays we > see here. You are forcing ZFS to commit transactions each 5% of dirty > ARC limit, which is 5% of 10% or memory size. I haven't looked on that > code recently, but I guess setting it too low can make ZFS commit > transactions too often, increasing write inflation for the underlying > storage. I would propose you to restore the default and try again. While this machine is different, the original problem was worse than the issue here: the load average was less than 1 for the most part the parallel bulk build when 30 was used. The fraction of time waiting was much longer than with 5. If I understand right, both too high and too low for a type of context can lead to increased elapsed time and getting it set to a near optimal is a non-obvious exploration. >>> >>> IIRC this limit was modified several times since originally implemented. >>> May be it could benefit from another look, if default 30% is not good. It >>> would be good if generic ZFS issues like this were reported to OpenZFS >>> upstream to be visible to a wider public. Unfortunately I have several >>> other project I must work on, so if it is not a regression I can't promise >>> I'll take it right now, so anybody else is welcome. >> >> As I understand, there are contexts were 5 is inappropriate >> and 30 works fairly well: no good single answer as to what >> value range will avoid problems. >> An overall point for the goal of my activity is: what makes a good test context for checking if ZFS is again safe to use? May be other tradeoffs make, say, 4 hardware threads more reasonable than 32. >>> >>> Thank you for your testing. The best test is one that nobody else run. It >>> also correlates with the topic of "safe to use", which also depends on what >>> it is used for. :) >> >> Looks like use of a M.2 Samsung SSD 960 PRO 1TB with a >> non-debug FreeBSD build is suitable for the bulk -a -J128 >> test (no ALLOW_MAKE_JOBS variants enabled, USE_TMPFS=no in >> use) on the 32 hardware thread system. (The swap partition >> in use is from the normal environment's PCIe Optane media.) >> The %idle and the load averages and %user stayed reasonable >> in a preliminary test. One thing it does introduce is trim >> management (both available and potentially useful). (Optane >> media does not support or need it.) No >> per_txg_dirty_frees_percent adjustment involved (still 5). >> >> I've learned to not use ^T for fear of /bin/sh aborting >> and messing up poudriere's context. So I now monitor with: >> >> # poudriere status -b >> >> in a separate ssh session. >> >> I'll note that I doubt I'd try for a complete bulk -a . >> I'd probably stop it if I notice that the number of >> active builders drops off for a notable time (normal >> waiting for prerequisites appearing to be why). >> >> > > So much for that idea. It has reached a state of staying > under 3500 w/s and up to 4.5ms/w (normally above 2ms/w). > %busy wondering in the range 85% to 101%. Lots of top > showing tx->tx. There is some read and other activity as > well. Of course the kBps figures are larger than the > earlier USB3 context (larger kB figures). > > It reached about 1350 port->package builds over the first > hour after the 2nd "Buildee started". > > autotrim is off. Doing a "zpool trim -w zamd64" leads to > . . . larger w/s figures during the process. So > more exploring to do at some point. Possibly: > > autotrim > per_txg_dirty_frees_percent > > For now, I'm just running "zpool trim -w zamd64" once > and a while so the process continues better. > > Still no evidence of deadlocks. No evidence of builds > failing for corruptions. > > . . . At around the end of 2nd hour: 2920 or so built. > > Still no evidence of deadlocks. No evidence of builds > failing for corruptions. > > . . . I've turned on autotrim without stopping the bulk > build. > > . . . At around the end of 3rd hour: 4080 or so built. > > Still no evidence of deadlocks. No evidence of builds > failing for corruptions. > > Looks like the % idle has been high for a significant > time. I think I'll stop this specific test and clean > things out. > > Looks like lang/guile* are examples of not respecting > the lack of ALLOW_MAKE_JOBS use. > > Hmm. The ^C ended up with: > > ^C[03:41:07] Error: Signal SIGINT caught, cleaning up and exiting > [main-amd64-bulk_a-default] [2023-09-04_17h49m28s] [sigint:] Queued: 34588 > Built: 4331 Failed: 12Skipped: 303 Ignored: 335 Fetched: 0 > Tobuild: 29607 Time: 03:41:05 > [03:41:07] Logs: > /usr/local/poudriere/data/logs/bulk/main-amd64-bulk_a-defa
Re: Stray characters in command history
i'm experiencing kind of similar issue. unsure why or how. i have 13.2. console is sc. the other side, via serial, is running current. uart is from usb serial adapter. other side has native soc uart. when i establish connection to that thing with cu, which is embedded board btw, and log in, i get weird random chars as if i've typed them in. if i do some input right after, i don't seem to get it. it gets worse, if i let cu run in other terminal and do some testing that involves lot of reboot cycles, while doing some tasks on other terminal, sometimes weird chars get injected into my input elsewhere. eg i run editor and it's annoying for something to appear as if i've typed it in. is it related? thankfully target isn't untrusted, otherwise it would be pretty bad? or where this thing even comes from? i know that you can do funny stuff with tiocsti and co but this looks pretty bad. both the fact that something makes it and the fact that they get injected elsewhere. there is also a some recent bug around this. so i'm not sure what to think of it all? On Sunday, May 21, 2023, bob prohaska wrote: > Here is another example, perhaps a bit clearer. > > The ssh connection to the first Pi3 in the chain had dropped, so it was > re-establishing via a regular user login, then su was invoked and tip run: > . > To change this login announcement, see motd(5). > Want to go the directory you were just in? > Type "cd -" > bob@pelorus:~ % su > Password: > # tip ucom > Stale lock on cuaU0 PID=2487... overriding. > connected > osed by r31 www s This appeared spontaneously, then I hit return. > osed: Command not found. < I didn't type anything. > bob@www:/usr/src %< The shell prompt on the 2nd Pi3's serial console. > > Clearly nothing to do with sshd, might it simply be a misdirected echo of console > output generated by a (dead or broken) tip connection? The first example looked > possibly malicious, this does not > > Thanks for reading, > > bob prohaska > > > > On Sun, May 21, 2023 at 06:49:33AM -0700, bob prohaska wrote: >> Lately I've been playing with buildworld on a Pi3 running -current. The same machine >> acts as a terminal server for a second Pi3 also running -current in my "cluster". >> I ssh into the first Pi3, su to root and run tip to pick up a serial connection to >> the second Pi's console. Both machines are within a week of up-to-date. >> >> While building world on the first Pi3 the ssh connection frequently drops and must be >> re-established. If there was a shell running on the serial console of the second >> Pi3 it typically keeps running and when the tip session is restarted disgorges a >> stream of accumulated console message. >> >> This morning the same thing happened, but I noticed something odd. The stream of >> messages (all login failure announcements from ssh) ended with >> >> >> May 21 06:15:00 www sshd[33562]: error: Fssh_kex_exchange_identification: banner line contains invalid characters >> *+May 21 06:15:19 www sshd[33565]: error: Fssh_kex_exchange_identification: Connection closed by remote host >> May 21 06:15:33 www sshd[33613]: error: Protocol major versions differ: 2 vs. 1 >> >> At that point I hit carriage return and got >> *+: No match. >> >> I did not type the *+ so it looks like the characters were somehow introduced elsewhere, >> possibly from the ssh failure message. How they got into the command stream is unclear. >> >> This strikes me as undesirable at best and possibly much worse. The shell reporting >> the "no match" was a regular user shell, but if I'd been su'd to root it appears that >> the unmatched characters would be seen by the root shell as input. >> >> This more-or-less fits with the pattern seen earlier with reboots observed via serial >> console halting on un-typed keystrokes. Those halts were attributed to electrical noise >> on the serial line, but this looks like something injected via part of the network >> login process. Reboot pauses have been an ongoing phenomenon for months, this is the >> first time I've noticed the "invalid characters" message from ssh on the console. >> >> Thanks for reading, apologies if I'm being a worrywart. >> >> bob prohaska >> >> >> > >
Re: Possible issue with linux xattr support?
On Tue, Sep 05, 2023 at 07:52:52AM +0200, Felix Palmen wrote: > * Dmitry Chagin [20230904 21:49]: > > On Mon, Sep 04, 2023 at 08:43:02PM +0200, Felix Palmen wrote: > > > I guess I'll now do a full rebuild of my linuxulator userspace branch on > > > a kernel with that patch, just to be sure it won't break anything else, > > > this will take a few hours, I will report back. So far looking really > > > good :) > > This completed while I was sleeping. No issues! > > With ~120 "Linux ports" building fine, using all sorts of tools (like > python and some tools from coreutils), I think it's fair to assume it's > all fixed now. > Thank you!
Re: An attempted test of main's "git: 2ad756a6bbb3" "merge openzfs/zfs@95f71c019" possible file odd result
On Sep 5, 2023, at 00:00, Mark Millard wrote: > On Sep 4, 2023, at 22:06, Mark Millard wrote: > >> . . . > > So I tried 30 for per_txg_dirty_frees_percent for 2 contexts: > autotrim on > vs. > autotrim off > > where there was 100 GiByte+ to delete after a poudriere > bulk run. > > autotrim on: takes a fair time to delete even 1 GiByte of the 100+ GiByte > vs. > autotrim off: takes less time to delete more. > > The difference is very visible via "gstat -spod" use. > > autotrim on likely makes things less concurrent, somewhat > like USB3 storage having only one command to the device > at a time for FreeBSD. autotrim on seems to prevent the > larger unit of work from being an effective way to > decrease the time required, instead possibly increasing > the time requirement. > > That may be an example of the context dependendency for > what value of per_txg_dirty_frees_percent to use to > avoid wasting much time. Trying autotrim off with 30 for per_txg_dirty_frees_percent got me the oddity/extra-message (just using 32 builders to match the hardware thread count): . . . [00:03:25] [32] [00:00:00] Builder starting [00:03:43] [01] [00:00:18] Finished print/indexinfo | indexinfo-0.3.1: Success [00:03:43] [01] [00:00:00] Building devel/gettext-runtime | gettext-runtime-0.22_1 [00:05:20] [01] [00:01:37] Finished devel/gettext-runtime | gettext-runtime-0.22_1: Success 23/.p/cleaning/rdeps/gettext-runtime-0.22_1/chemtool-1.6.14_4 copy: open failed: No such file or directory [00:05:23] [01] [00:00:00] Building devel/gmake | gmake-4.3_2 [00:05:55] [02] [00:02:30] Builder started . . . (Not that I know if the context actually matters and I have no clue if I'll ever get a repetition.) === Mark Millard marklmi at yahoo.com
Re: Possible issue with linux xattr support?
On Tue, Sep 05, 2023 at 07:52:52AM +0200, Felix Palmen wrote:
> * Dmitry Chagin [20230904 21:49]:
> > On Mon, Sep 04, 2023 at 08:43:02PM +0200, Felix Palmen wrote:
> > > I guess I'll now do a full rebuild of my linuxulator userspace branch on
> > > a kernel with that patch, just to be sure it won't break anything else,
> > > this will take a few hours, I will report back. So far looking really
> > > good :)
>
> This completed while I was sleeping. No issues!
>
> With ~120 "Linux ports" building fine, using all sorts of tools (like
> python and some tools from coreutils), I think it's fair to assume it's
> all fixed now.
>
11e37048d
> Cheers, Felix
>
> --
> Felix Palmen {private} fe...@palmen-it.de
> -- ports committer -- {web} http://palmen-it.de
> {pgp public key} http://palmen-it.de/pub.txt
> {pgp fingerprint} 6936 13D5 5BBF 4837 B212 3ACC 54AD E006 9879 F231
Re: FYI: ^T use during poudriere bulk vs. /bin/sh operation: I got a "Unsafe ckmalloc() call" Abort trap that left a mess
On Mon, Sep 04, 2023 at 05:16:56PM -0700, Mark Millard wrote: > During a (zfs based) poudriere bulk -a run a ^T got a: > Unsafe ckmalloc() call > Abort trap (core dumped) > My attribution to ^T handling is unverified: I did not find the > sh.core file. It is just what the timing looked like. The error message means that ckmalloc() is being called without INTOFF in effect, i.e. at the time a SIGINT may cause an EXINT exception (longjmp()). Although malloc(3)'s data structures could be protected by surrounding the malloc() call with INTOFF and INTON, this would lead to a memory leak if a SIGINT happened at that time, since the pointer to the allocated memory would be lost. This check was added in git commit 9f9c9549fd4f7ce362e95e3a8a50f00ffd00175c. My first guess would be that there is a bug with a rare edge case of traps and/or errors, such as not applying INTOFF again after an exception has turned it off or doing INTON when interrupts are already enabled. A less likely possibility could be a violation related to volatile and synchronization between a signal handler and the main flow. Many common code paths are all exercised by the tests and normal use, so it must be something special in some way. -- Jilles Tjoelker
Re: 14.0-CURRENT boots fine but keyboard does not work
On Tue, Sep 5, 2023 at 12:13 AM Matthias Apitz wrote: > El día lunes, septiembre 04, 2023 a las 12:10:56p. m. -0600, Warner Losh > escribió: > > > On Mon, Sep 4, 2023, 11:40 AM Michael Gmelin wrote: > > > > > This could also be related: > > > > > > > > > > https://cgit.freebsd.org/src/commit/?id=319d2bf407b3762da6f1c67ffe8dce2fee587aaf > > > > > > You could try to undo that patch and build a new kernel. > > > > > > > It shouldn't make a difference... but I may have been given bad advice if > > it did... if it's this one, I'll help sort it out. > > > > Warner > > I've reverted the above change, compiled the kernel, copied it to the > USB key into /boot/kernel/kernel (only this file), removed > /boot/loader.conf and the keyboard is fine. Thanks, Michael. > > Warner, do you need a new PR for this? > No. Let's see if I can puzzle out what went awry here. First up: can you report what 'kenv' on a boot system returns? Warner
Re: Possible regression in main causing poor performance
On Sep 5, 2023, at 08:58, Cy Schubert wrote: > In message <20230830204406.24fd...@slippy.cwsent.com>, Cy Schubert writes: >> In message <20230830184426.gm1...@freebsd.org>, Glen Barber writes: >>> >>> >>> On Mon, Aug 28, 2023 at 06:06:09PM -0700, Mark Millard wrote: Has any more been learned about this? Is it still an issue? =20 >>> >>> I rebooted the machine before the ALPHA3 builds with no other changes, >>> and the overall times for 14.x builds went back to normal. I do not >>> like to experiment with builders during a release cycle, but as we are >>> going to have 15.x snapshots available moving forward, I will not reboot >>> that machine next week in hopes to get some useful data. >>> >>> If my memory serves correctly, mm@ has a pending ZFS import from >>> upstream for both main and stable/14 pending. Whether or not that will >>> resolve any issue here, I do not know. >> >> Two of my poudriere builder machines have experienced different panics >> since the ZFS import two days ago. The problems have been documented on the >> -current list. > > Just an update. > > The three pull requests amotin@ pointed to did resolve all my problems. A > subsequent update which included the latest ZFS commits worked just as > well, without any new regressions. AFAIAC this problem has been resolved. > > The random email corruptions have also been resolved. > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > e^(i*pi)+1=0 > > > > > 9O8 The just-above quoted line looks like a corruption to me. Otherwise, I'm just reporting more evidence from separate testing on amd64 . . . I will say that my separate-install/boot environment 10hr, 6366 port->package poudriere bulk -a prefix test of: # uname -apKU FreeBSD amd64-ZFS 15.0-CURRENT FreeBSD 15.0-CURRENT amd64 150 #118 main-n265152-f49d6f583e9d-dirty: Mon Sep 4 14:26:56 PDT 2023 root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG amd64 amd64 150 150 did not show any deadlocks. The only oddity that I've noticed is the 1 extra message shown in: . . . [00:03:25] [32] [00:00:00] Builder starting [00:03:43] [01] [00:00:18] Finished print/indexinfo | indexinfo-0.3.1: Success [00:03:43] [01] [00:00:00] Building devel/gettext-runtime | gettext-runtime-0.22_1 [00:05:20] [01] [00:01:37] Finished devel/gettext-runtime | gettext-runtime-0.22_1: Success 23/.p/cleaning/rdeps/gettext-runtime-0.22_1/chemtool-1.6.14_4 copy: open failed: No such file or directory [00:05:23] [01] [00:00:00] Building devel/gmake | gmake-4.3_2 [00:05:55] [02] [00:02:30] Builder started . . . I'm comfortable moving my normal environments forward to include this latest import of openzfs. The effort established a separate environment set up for doing testing of jumping to/past an openzfs import(s) in main. Too many recent imports have dangerous-to-the-file-system and/or had deadlocking issues for me to simply update to include them without first testing on separate media that does not have to stay operational. === Mark Millard marklmi at yahoo.com
Re: Possible regression in main causing poor performance
In message , Mark Millard write s: > On Sep 5, 2023, at 08:58, Cy Schubert wrote: > > > In message <20230830204406.24fd...@slippy.cwsent.com>, Cy Schubert = > writes: > >> In message <20230830184426.gm1...@freebsd.org>, Glen Barber writes: > >>>=20 > >>>=20 > >>> On Mon, Aug 28, 2023 at 06:06:09PM -0700, Mark Millard wrote: > Has any more been learned about this? Is it still an issue? > =3D20 > >>>=20 > >>> I rebooted the machine before the ALPHA3 builds with no other = > changes, > >>> and the overall times for 14.x builds went back to normal. I do not > >>> like to experiment with builders during a release cycle, but as we = > are > >>> going to have 15.x snapshots available moving forward, I will not = > reboot > >>> that machine next week in hopes to get some useful data. > >>>=20 > >>> If my memory serves correctly, mm@ has a pending ZFS import from > >>> upstream for both main and stable/14 pending. Whether or not that = > will > >>> resolve any issue here, I do not know. > >>=20 > >> Two of my poudriere builder machines have experienced different = > panics=20 > >> since the ZFS import two days ago. The problems have been documented = > on the=20 > >> -current list. > >=20 > > Just an update. > >=20 > > The three pull requests amotin@ pointed to did resolve all my = > problems. A=20 > > subsequent update which included the latest ZFS commits worked just as=20= > > > well, without any new regressions. AFAIAC this problem has been = > resolved. > >=20 > > The random email corruptions have also been resolved. > >=20 > >=20 > > --=20 > > Cheers, > > Cy Schubert > > FreeBSD UNIX: Web: https://FreeBSD.org > > NTP: Web: https://nwtime.org > >=20 > > e^(i*pi)+1=3D0 > >=20 > >=20 > >=20 > >=20 > > =C2=9C9O8 > > The just-above quoted line looks like a corruption to me. > Hmm. Just to rule out that a build of the exmh2 and nmh-devel packages might have been corrupt, I've rebuilt the two and will continue to monitor. This email was sent by a rebuilt exmh2 and nmh-devel. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 ÀÀÀÀÀÀÀÀ
Re: 14.0-CURRENT boots fine but keyboard does not work
El día martes, septiembre 05, 2023 a las 11:07:07a. m. -0600, Warner Losh escribió: > > https://cgit.freebsd.org/src/commit/?id=319d2bf407b3762da6f1c67ffe8dce2fee587aaf > > > > > > > > You could try to undo that patch and build a new kernel. > > > > > > > ... > > No. Let's see if I can puzzle out what went awry here. > > First up: can you report what 'kenv' on a boot system returns? Please find attached the output of kenv matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub COLUMNS="80" LINES="25" acpi.oem="CORE " acpi.revision="2" acpi.rsdp="0x000fdbb0" acpi.rsdt="0x7bf84030" acpi.xsdt="0x7bf840e0" acpi.xsdt_length="36" acpi_dsdt_load="NO" acpi_dsdt_name="/boot/acpi_dsdt.aml" acpi_dsdt_type="acpi_dsdt" acpi_video_load="NO" audit_event_load="NO" audit_event_name="/etc/security/audit_event" audit_event_type="etc_security_audit_event" bitmap_load="NO" bitmap_name="splash.bmp" bitmap_type="splash_image_data" bootenv_autolist="YES" bootfile="kernel" comconsole_pcidev="" comconsole_port="1016" comconsole_speed="9600" console="vidconsole" cpu_microcode_load="NO" cpu_microcode_name="/boot/firmware/ucode.bin" cpu_microcode_type="cpu_microcode" currdev="disk0s2a:" efi_max_resolution="1x1" entropy_cache_load="YES" entropy_cache_name="/boot/entropy" entropy_cache_type="boot_entropy_cache" entropy_efi_seed="YES" hostuuid_load="YES" hostuuid_name="/etc/hostid" hostuuid_type="hostuuid" kernel="kernel" kernel_options="" kernel_path="/boot/kernel" kernelname="/boot/kernel/kernel" kernels_autodetect="YES" loaddev="disk0s2a:" loader_conf_dirs="/boot/loader.conf.d" module_blacklist="drm drm2 radeonkms i915kms amdgpu" module_path="/boot/kernel;/boot/modules;/boot/dtb;/boot/dtb/overlays" module_verbose="2" nextboot_conf="/boot/nextboot.conf" pcibios.config1="1" pcibios.config2="0" pcibios.major="2" pcibios.maxbus="1" pcibios.minor="0" ram_blacklist_load="NO" ram_blacklist_name="/boot/blacklist.txt" ram_blacklist_type="ram_blacklist" screen.font="8x16" screen.textmode="1" screensave_load="NO" screensave_name="green_saver" script.lang="lua" smbios.bios.reldate="08/13/2014" smbios.bios.revision="4.0" smbios.bios.vendor="coreboot" smbios.bios.version=" " smbios.chassis.maker="Acer" smbios.chassis.type="Desktop" smbios.system.maker="Acer" smbios.system.product="Peppy" smbios.system.serial="123456789" smbios.system.version="1.0" smbios.version="2.7" splash_bmp_load="NO" splash_pcx_load="NO" splash_txt_load="NO" teken.bg_color="0" teken.fg_color="7" twiddle_divisor="16" vbe_max_resolution="" verbose_loading="NO" vesa_load="NO" vfs.root.mountfrom="ufs:/dev/ufs/FreeBSD_Install" vfs.root.mountfrom.options="rw,noatime" dev.ax.sph_enable="1"
Re: An attempted test of main's "git: 2ad756a6bbb3" "merge openzfs/zfs@95f71c019" possible file odd result
Just FYI: For the specific machine/storage media combination used for the openzfs import testing, the following combination seemed to work well relative to the subject of the "odd result": A) /etc/sysctl.conf having "vfs.zfs.per_txg_dirty_frees_percent=30" B) autotrim off but use of "zpool trim -w zamd64" first, after any freeing of space by deleting files. (Probably again after the build and any cleanout of the tempprary results.) C) Avoid having more poudriere builders than hardware threads. Of course, the combination does not apply to media that does not have trim accessible (USB3, for example) --and that may not support trim in some cases (Optane, for example). By contrast . . . In a USB3 context, vfs.zfs.per_txg_dirty_frees_percent=30 did not work well because of the delete sequence when a builder is to be reused for its next build. vfs.zfs.per_txg_dirty_frees_percent=5 allowed more overall progress on that aarch64 system. The big cleanout of all the builders at the end is not the only consideration in setting vfs.zfs.per_txg_dirty_frees_percent (for at least some systems). === Mark Millard marklmi at yahoo.com
Re: 14.0-CURRENT boots fine but keyboard does not work
Can you try this patch? (it's cut and paste inline, so if it fails, can you
apply it by hand... it's pretty straight forward)...
The reason is in the comments... Not 100% sure about using the version
being all spaces, though...
Nor the year 2018, honestly, but it beats having a longish list (see
https://mrchromebox.tech/#devices
for the list I worry about).
Warner
diff --git a/sys/dev/atkbdc/atkbdc.c b/sys/dev/atkbdc/atkbdc.c
index 6168b389841b..ee7c6cf59da6 100644
--- a/sys/dev/atkbdc/atkbdc.c
+++ b/sys/dev/atkbdc/atkbdc.c
@@ -147,6 +147,7 @@ atkbdc_getquirks(void)
char *maker = kern_getenv("smbios.system.maker");
char *product = kern_getenv("smbios.system.product");
char *version = kern_getenv("smbios.bios.version");
+char *reldate = kern_getenv("smbios.bios.reldate");
for (i = 0; i < nitems(quirks); i++)
if (QUIRK_STR_EQUAL(quirks[i].bios_vendor, bios_vendor) &&
@@ -154,6 +155,16 @@ atkbdc_getquirks(void)
QUIRK_STR_EQUAL(quirks[i].product, product) &&
QUIRK_STR_MATCH(quirks[i].version, version))
return (quirks[i].quirk);
+/*
+ * Some Chromebooks don't confirm to the google comment above so do the
+ * Chromebook workaround for all <= 2018 coreboot systems that have a
+ * 'blank' version. At least once Acer "Peppy" chromebook has this
issue,
+ * with a reldate of 08/13/2014.
+ */
+if (QUIRK_STR_EQUAL("coreboot", bios_vendor) &&
+ (version != NULL && *version == ' ') &&
+ (reldate != NULL && strlen(reldate) >= 10 && strcmp(reldate + 6,
"2018") <= 0))
+ return (CHROMEBOOK_WORKAROUND);
return (0);
}
On Tue, Sep 5, 2023 at 11:56 AM Matthias Apitz wrote:
> El día martes, septiembre 05, 2023 a las 11:07:07a. m. -0600, Warner Losh
> escribió:
>
> > >
> https://cgit.freebsd.org/src/commit/?id=319d2bf407b3762da6f1c67ffe8dce2fee587aaf
> > > > >
> > > > > You could try to undo that patch and build a new kernel.
> > > > >
> > > > ...
> >
> > No. Let's see if I can puzzle out what went awry here.
> >
> > First up: can you report what 'kenv' on a boot system returns?
>
> Please find attached the output of kenv
>
> matthias
>
> --
> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/
> +49-176-38902045
> Public GnuPG key: http://www.unixarea.de/key.pub
>
Re: 14.0-CURRENT boots fine but keyboard does not work
On Tue, Sep 05, 2023 at 01:29:34PM -0600, Warner Losh wrote: > +/* > + * Some Chromebooks don't confirm to the google comment above so do the s/confirm/conform ? > + * Chromebook workaround for all <= 2018 coreboot systems that have a > + * 'blank' version. At least once Acer "Peppy" chromebook has this > issue, s/once/one ? -- Steve
Re: 14.0-CURRENT boots fine but keyboard does not work
On Tue, Sep 5, 2023 at 2:22 PM Steve Kargl wrote: > On Tue, Sep 05, 2023 at 01:29:34PM -0600, Warner Losh wrote: > > +/* > > + * Some Chromebooks don't confirm to the google comment above so do > the > > s/confirm/conform ? > > > > + * Chromebook workaround for all <= 2018 coreboot systems that have > a > > + * 'blank' version. At least once Acer "Peppy" chromebook has this > > issue, > > s/once/one ? > Yes. Thanks! Dashed off the comment in a hurry since I wanted to get the patch out there in a hurry... But that was kinda sloppy of me.. fixed. Warner
Re: 14.0-CURRENT boots fine but keyboard does not work
El día martes, septiembre 05, 2023 a las 03:24:30p. m. -0600, Warner Losh
escribió:
> On Tue, Sep 5, 2023 at 2:22 PM Steve Kargl
> wrote:
>
> > On Tue, Sep 05, 2023 at 01:29:34PM -0600, Warner Losh wrote:
> > > +/*
> > > + * Some Chromebooks don't confirm to the google comment above so do
> > the
> >
> > s/confirm/conform ?
> >
> >
> > > + * Chromebook workaround for all <= 2018 coreboot systems that have
> > a
> > > + * 'blank' version. At least once Acer "Peppy" chromebook has this
> > > issue,
> >
> > s/once/one ?
> >
>
> Yes. Thanks! Dashed off the comment in a hurry since I wanted to get the
> patch out
> there in a hurry... But that was kinda sloppy of me.. fixed.
I've had to apply the patch manually (attached as context diff).
With this the keyboard works also fine.
Thanks
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
*** /usr/src/sys/dev/atkbdc/atkbdc.c.ORIG Sat Aug 5 12:50:44 2023
--- /usr/src/sys/dev/atkbdc/atkbdc.c Wed Sep 6 07:08:49 2023
***
*** 149,154
--- 149,155
char *maker = kern_getenv("smbios.system.maker");
char *product = kern_getenv("smbios.system.product");
char *version = kern_getenv("smbios.bios.version");
+ char *reldate = kern_getenv("smbios.bios.reldate");
for (i = 0; i < nitems(quirks); i++)
if (QUIRK_STR_EQUAL(quirks[i].bios_vendor, bios_vendor) &&
***
*** 156,161
--- 157,173
QUIRK_STR_EQUAL(quirks[i].product, product) &&
QUIRK_STR_MATCH(quirks[i].version, version))
return (quirks[i].quirk);
+
+ /*
+ * Some Chromebooks don't conform to the google comment above so do the
+ * Chromebook workaround for all <= 2018 coreboot systems that have a
+ * 'blank' version. At least one Acer "Peppy" chromebook has this issue,
+ * with a reldate of 08/13/2014.
+ */
+ if (QUIRK_STR_EQUAL("coreboot", bios_vendor) &&
+(version != NULL && *version == ' ') &&
+(reldate != NULL && strlen(reldate) >= 10 && strcmp(reldate + 6, "2018") <= 0))
+return (CHROMEBOOK_WORKAROUND);
return (0);
}
