[Bug 262263] ahci: Unaligned free to UMA zone (ada_ccb)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262263 Hans Petter Selasky changed: What|Removed |Added Assignee|u...@freebsd.org |b...@freebsd.org Component|usb |kern -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262263] ahci: Unaligned free to UMA zone (ada_ccb)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262263 --- Comment #6 from Hans Petter Selasky --- Try entering these commands before booting the kernel (in the loader prompt) set kern.cam.ada.enable_uma_ccbs=0 boot --HPS -- You are receiving this mail because: You are the assignee for the bug.
[Bug 261059] Kernel panic XEN + ZFS volume.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261059 --- Comment #1 from Janis --- I've been digging further with this bug. Found one ZFS problem, which i can repeat 100%, reported as bug #262189. For me though it seems that these two bugs might not be related. What i have found though, is that less RAM for Dom0, helps to panic system sooner. Thus i assume, that ZFS stress script, just helped to fill memory sooner. Another thing i did, is install FreeBSD on UFS separate disk, and ZFS pool on the other disk. System still crashes, but it is easier to try out different combinations. My latest xen command line params are: xen_cmdline="dom0_mem=2048M cpufreq=dom0-kernel dom0_max_vcpus=2 dom0=pvh,verbose=1 console=vga,com1 com1=9600,8n1 guest_loglvl=all loglvl=all sync_console=1 reboot=no" So now it seems that i can see more verbose panic messages on serial output. While investigating, there are few things i have noticed; it has given me a suspicion that actually there is not just a single bug, but multiple, which trigger themselves at different times. Sometimes when system does not crash, it crashes when i destroy all DomU instances, not when i create them, sometimes after all DomU's have been destroyed, system crashes on init 0 call. 1. While stressing ZFS, at some point i get messages like these in console: xnb(xnb_frontend_changed:1391): frontend_state=Connected, xnb_state=InitWait xnb(xnb_connect_comms:787): rings connected! (XEN) d2v0: upcall vector 93 xbbd2: Error 12 Unable to allocate request bounce buffers xbbd2: Fatal error. Transitioning to Closing State xbbd5: Error 12 Unable to allocate request bounce buffers xbbd5: Fatal error. Transitioning to Closing State xnb(xnb_frontend_changed:1391): frontend_state=Connected, xnb_state=InitWait xnb(xnb_connect_comms:787): rings connected! Mar 1 10:31:55 lab-01 kernel: pid 1117 (qemu-system-i386), jid 0, uid 0, was killed: out of swap space Mar 1 10:32:59 lab-01 kernel: pid 1264 (qemu-system-i386), jid 0, uid 0, was killed: out of swap space Mar 1 10:33:06 lab-01 kernel: pid 1060 (zsh), jid 0, uid 0, was killed: out of swap space Mar 1 10:33:11 lab-01 kernel: pid 1053 (zsh), jid 0, uid 0, was killed: out of swap space For me this seems somehow weird, could it be a sign for memleak? That some resources are not cleaned up after DomU's destroy? Because all that the scripts are doing is start DomU, write some data in disk, stop DomU. 2. On domain creation part, sometimes i get an error like this: Parsing config from /service/crash/cfg/xen-vm2-zvol-5.conf libxl: error: libxl_device.c::device_backend_callback: Domain 9:unable to add device with path /local/domain/0/backend/vbd/9/51712 libxl: error: libxl_device.c::device_backend_callback: Domain 9:unable to add device with path /local/domain/0/backend/vbd/9/51728 libxl: error: libxl_device.c::device_backend_callback: Domain 9:unable to add device with path /local/domain/0/backend/vbd/9/51744 libxl: error: libxl_device.c::device_backend_callback: Domain 9:unable to add device with path /local/domain/0/backend/vbd/9/51760 libxl: error: libxl_device.c::device_backend_callback: Domain 9:unable to add device with path /local/domain/0/backend/vbd/9/51776 libxl: error: libxl_create.c:1613:domcreate_launch_dm: Domain 9:unable to add disk devices libxl: error: libxl_domain.c:1182:libxl__destroy_domid: Domain 9:Non-existant domain libxl: error: libxl_domain.c:1136:domain_destroy_callback: Domain 9:Unable to destroy guest libxl: error: libxl_domain.c:1063:domain_destroy_cb: Domain 9:Destruction of domain failed Is it possible to know more info for why Dom0 was "unable to add device with path"? More verbosity? Was it that ZFS held some locks or that previous DomU is still holding the same ZVOL? 3. Since i am following information at https://docs.freebsd.org/en/books/handbook/virtualization/#virtualization-host-xen, it seems that command: echo 'vm.max_wired=-1' >> /etc/sysctl.conf is obsolete, because in FreeBSD 13.0, there is no such sysctl knob, "sysctl: unknown oid 'vm.max_wired'". I do not know which is equivalent to this one. I found "vm.max_user_wired=-1", is it the same? Maybe manual should be updated. Even if i set this to -1, still quemy-system is killed with out of swap space error. Maybe there is a different sysctl for that purpose now? At one point i got an unseen error, but i do not remember what was the system state, what did i do. It is as follows: xnb(xnb_rxpkt2rsp:2059): Got error -1 for hypervisor gnttab_copy status xnb(xnb_ring2pkt:1526): Unknown extra info type 255. Discarding packet xnb(xnb_dump_txreq:299): netif_tx_request index =0 xnb(xnb_dump_txreq:300): netif_tx_request.gref =0 xnb(xnb_dump_txreq:301): netif_tx_request.offset=0 xnb(xnb_dump_txreq:302): netif_tx_request.flags =8 xnb(xnb_dump_txreq:303): netif_tx_request.id=69 xnb(xnb_dump_txreq:304): netif_tx_request.size =1000 xnb(xnb_dump_txreq:299): netif_tx_request index =1 xnb(xnb_dump_txreq:300
[Bug 261059] Kernel panic XEN + ZFS volume.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261059 --- Comment #2 from Janis --- Oh, and i forgot to add, that system crashes when disks are raw files on ZFS datasets as well. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262263] ahci: Unaligned free to UMA zone (ada_ccb)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262263 --- Comment #7 from Lamia --- Done but no difference for the 13.1PreRelease. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 261059] Kernel panic XEN + ZFS volume.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261059 Roger Pau Monné changed: What|Removed |Added CC||roy...@freebsd.org --- Comment #3 from Roger Pau Monné --- Using only 2GB of memory for dom0 together with ZFS is likely too less, you should use at least 4GB of memory for dom0 when using ZFS. Try to change the line: xen_cmdline="dom0_mem=2048M cpufreq=dom0-kernel dom0_max_vcpus=2 dom0=pvh console=vga,com1 com1=9600,8n1 guest_loglvl=all loglvl=all" To: xen_cmdline="dom0_mem=4096M dom0_max_vcpus=2 dom0=pvh console=vga,com1 com1=9600,8n1 guest_loglvl=all loglvl=all" Note that cpufreq=dom0-kernel is likely not functional, and also not a good idea. The FreeBSD dom0 kernel has no idea about the real load of the system, as it doesn't see the load created by VMs. Xen (the hypervisor) is the only one that has the full picture of the system. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 261059] Kernel panic XEN + ZFS volume.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261059 --- Comment #4 from Janis --- Thank you for fast response. Well, the system crashes with 8G of Dom0 RAM as well; i am using 2G for test environment to provoke the bug sooner. With 8G, the symptoms are more or less the same, just i can not panic it in 5-30 min, but have to wait a day or so. For the option cpufreq=dom0-kernel... reading config manual, this seemed the only way to ensure that if i press power button, system (Dom0) does init 0 and shuts down. The same is that i would like to have an ability with init 0 to shut down the machine, but on panic to reboot. If there are better ways to achieve that, i just do not know how. I will remove cpufreq=dom0-kernel and see, if it changes system behavior. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262086] usr.bin.diff.diff_test.functionname fails
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262086 --- Comment #2 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=4be7d087c2b566f4910683836be279d55c1a81c6 commit 4be7d087c2b566f4910683836be279d55c1a81c6 Author: Tom Jones AuthorDate: 2022-03-01 13:23:25 + Commit: Tom Jones CommitDate: 2022-03-01 13:27:21 + diff: Use start of change when searching for function Use the start of change when searching for a function rather than the start of the context. In short functions if this could result in search for the function name starting from before the function definition. PR: 262086 Reviewed by:bapt, mckusick, mhorne Sponsored by: Klara Inc. Differential Revision: https://reviews.freebsd.org/D34328 usr.bin/diff/diffreg.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262263] ahci: Unaligned free to UMA zone (ada_ccb)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262263 --- Comment #8 from Edward Tomasz Napierala --- None of this was (or is going to be) MFC-Ed, so if it happens in 13, it must be something else. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262273] Subsuquent Calls to clock_gettime(CLOCK_THREAD_CPUTIME_ID,... ) return time in the past
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262273
Bug ID: 262273
Summary: Subsuquent Calls to
clock_gettime(CLOCK_THREAD_CPUTIME_ID,... ) return
time in the past
Product: Base System
Version: Unspecified
Hardware: amd64
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: b...@freebsd.org
Reporter: donaldshar...@gmail.com
When I run:
```
#include
#include
void main(void)
{
struct timespec before, after;
while (1) {
clock_gettime(CLOCK_THREAD_CPUTIME_ID, &before);
clock_gettime(CLOCK_THREAD_CPUTIME_ID, &after);
printf("before: %lu:%lu after %lu:%lu\n",
before.tv_sec, before.tv_nsec,
after.tv_sec, after.tv_nsec);
if (after.tv_nsec < before.tv_nsec)
exit(-1);
}
}
```
I get this output:
before: 0:18195000 after 0:18198000
before: 0:26005000 after 0:18258000
The after time is prior to the before time.
I am running on 12.1-Release in a vm on a ryzen 3900x. I also asked a friend
to run it on bare metal and got the same issue:
before: 0:444288000 after 0:444288000
before: 0:446097000 after 0:44429
They are running on FreeBSD 12.3-STABLE stable/12-n163-259bedb8f
It is my expectation that there should not be jumps backwards in time. Is my
assumption incorrect?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 262273] Subsuquent Calls to clock_gettime(CLOCK_THREAD_CPUTIME_ID,... ) return time in the past
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262273 f...@cantconnect.ru changed: What|Removed |Added CC||f...@cantconnect.ru --- Comment #1 from f...@cantconnect.ru --- That could happen when CPU frequency still not reached its maximum value. The cpu_time is calculated as cpu_time = cpu_ticks / max_cpu_tickrate, and when max_cpu_tickrate increasing, cpu_time decreasing. Did you tested this on not just-powered-up system? Try to run the test multiple times. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262273] Subsuquent Calls to clock_gettime(CLOCK_THREAD_CPUTIME_ID,... ) return time in the past
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262273 --- Comment #2 from Donald Sharp --- I am able to reproduce this issue at will on my system. Just have to run this test program and it happens -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262273] Subsuquent Calls to clock_gettime(CLOCK_THREAD_CPUTIME_ID,... ) return time in the past
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262273 Joe Marcus Clarke changed: What|Removed |Added CC||mar...@freebsd.org --- Comment #3 from Joe Marcus Clarke --- My understanding is that the thread_cputime clock is monotonic for a given resolution (e.g., 1.0002e-06). On the 12.3-STABLE system below, this i5 machine has been up for nearly three days. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262155] atkbd: ~16s delay at initial kernel boot on Framework laptop
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262155 --- Comment #2 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=84369dd52369cbae28970dca20a53d3de1719907 commit 84369dd52369cbae28970dca20a53d3de1719907 Author: Mark Johnston AuthorDate: 2022-03-01 14:39:35 + Commit: Mark Johnston CommitDate: 2022-03-01 14:39:35 + x86: Probe the TSC frequency earlier This lets us use the TSC to implement early DELAY, limiting the use of the sometimes-unreliable 8254 PIT. PR: 262155 Reviewed by:emaste Tested by: emaste, mike tancsa , Stefan Hegnauer MFC after: 1 month Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D34367 sys/amd64/amd64/machdep.c | 14 +- sys/i386/i386/machdep.c | 11 - sys/x86/include/clock.h | 3 +- sys/x86/isa/clock.c | 4 +- sys/x86/x86/tsc.c | 123 +- 5 files changed, 94 insertions(+), 61 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262155] atkbd: ~16s delay at initial kernel boot on Framework laptop
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262155 Mark Johnston changed: What|Removed |Added Assignee|b...@freebsd.org|ma...@freebsd.org Status|Open|In Progress -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262273] Subsuquent Calls to clock_gettime(CLOCK_THREAD_CPUTIME_ID,... ) return time in the past
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262273
--- Comment #4 from f...@cantconnect.ru ---
I can't reproduce this (but that's not on Ryzen)
Try this
#include
#include
int main(void)
{
struct timespec before, after;
clockid_t cid;
if(clock_getcpuclockid2(0, CPUCLOCK_WHICH_TID, &cid)<0) return -1;
while (1) {
clock_gettime(cid, &before);
clock_gettime(cid, &after);
printf("before: %lu:%lu after %lu:%lu\n",
before.tv_sec, before.tv_nsec,
after.tv_sec, after.tv_nsec);
if (after.tv_nsec < before.tv_nsec)
return -1;
}
}
same problem?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 262273] Subsuquent Calls to clock_gettime(CLOCK_THREAD_CPUTIME_ID,... ) return time in the past
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262273 --- Comment #5 from Joe Marcus Clarke --- This has run for over 15 seconds without fail on my i5. Though still not sure why the other clock is not monotonic. I think the goal is to have somewhat portable code between Linux and *BSD. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262273] Subsuquent Calls to clock_gettime(CLOCK_THREAD_CPUTIME_ID,... ) return time in the past
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262273 --- Comment #6 from f...@cantconnect.ru --- Please run both tests multiple times to ensure that the first fails from time to time and the second not. If this is true, it is surely a bug that should be fixed. The difference between these two timers is that CLOCK_THREAD_CPUTIME_ID is designed to be fully realtime, while clock_getcpuclockid2(0,CPUCLOCK_WHICH_TID) may return slightly outdated value. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262273] Subsuquent Calls to clock_gettime(CLOCK_THREAD_CPUTIME_ID,... ) return time in the past
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262273 --- Comment #7 from Joe Marcus Clarke --- Yeah, I've been running both and I get 100% failure on Donald's original code (at different times), but thus far your code has not failed minutes in. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262263] ahci: Unaligned free to UMA zone (ada_ccb)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262263 --- Comment #9 from Lamia --- USB_Err_Stalled started before 13.1Prelease, same as Stable. I could run poudriere builds on Stable despite the error before now. Suddenly, a poudriere command breaks display and tonnes of the error are emitted on the terminal. Then I updated Stable, and it turned to 13.1PreRelease, but the error would not vanish. I did all possible combinations - Bluetooth, USB disabled too, but no luck. Make InstallWorld was problematic at "mt ree./" but I got around it. I upgraded to Current on a new BE then the kernel crashed. PS: In another related matter, there is a live ECC-mem server that automatically restarts at an attempt to run portmaster in one of its jails. The server runs 13.0-RELEASE and is regularly updated. Using pkgs is not an option. I must have mentioned it in the previous post@Forums. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262263] ahci: Unaligned free to UMA zone (ada_ccb)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262263 --- Comment #10 from Alexander Motin --- @Lamia, there seem to be two independent issues here: one for USB, one for AHCI. Please do not mix them. I have doubts that panic you see on 14 should be reproducible on 13.1, but please correct me if I read your wrong. @trasz I think I see the problem, and it may indeed be related to your change. In ahci_issue_recovery() I see such a line: ccb->ccb_h = ch->hold[i]->ccb_h;/* Reuse old header. */ , which should also copy alloc_flags from read periph CCB to the locally allocated one. When it comes time to free the CCB, it is probably getting freed to the wrong zone. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262263] ahci: Unaligned free to UMA zone (ada_ccb)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262263 --- Comment #11 from Lamia --- You are correct. Panic on 14.0 is likely not reproducible on 13.1. The update on stable went fine though errors were still emitted. I suspect they are two issues too - AHCI & USB. I have had issues with the drives for the board. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262273] Subsuquent Calls to clock_gettime(CLOCK_THREAD_CPUTIME_ID,... ) return time in the past
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262273 --- Comment #8 from Donald Sharp --- When I run my test program it fails within 2 seconds every time I have ever run it. When I run f...@cantconnect.ru 's test, I ran it for over 5 minutes without it failing. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262273] Subsuquent Calls to clock_gettime(CLOCK_THREAD_CPUTIME_ID,... ) return time in the past
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262273 --- Comment #9 from f...@cantconnect.ru --- Created attachment 232188 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=232188&action=edit attempt to fix the problem Please try this patch to kernel. Looks like it is a conflict between switchtime/runtime reading in kern_thread_cputime() and switchtime/runtime updating in statclock(). Fixing statclock will be to expensive, so just make workaround in kern_thread_cputime(). -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262278] file(1) fails to identify a JAR file
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262278 Bug ID: 262278 Summary: file(1) fails to identify a JAR file Product: Base System Version: 13.0-STABLE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: y...@freebsd.org For this JAR: https://repo1.maven.org/maven2/org/opentest4j/opentest4j/1.1.1/opentest4j-1.1.1.jar file prints: > opentest4j-1.1.1.jar: Zip archive data, at > least v1.0 to extract when for JARs it normally prints: "Java archive data (JAR)" -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262278] file(1) fails to identify a JAR file
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262278 Ed Maste changed: What|Removed |Added CC||ema...@freebsd.org --- Comment #1 from Ed Maste --- JAR files are in fact ZIP files, just with special metadata. libmagic's JAR detection was added here: https://github.com/file/file/commit/e45cd303713418af058361f5711a768550e1c867 JAR files often have 0xcafe at a specific location in the ZIP file and libmagic keys on this, but it is not required, and the file you've linked does not have this field. Useful links: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6211008 https://bugs.openjdk.java.net/browse/JDK-6808540 This should probably be reported/discussed at http://www.darwinsys.com/file/ -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262278] file(1) fails to identify a JAR file
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262278 --- Comment #2 from Yuri Victorovich --- (In reply to Ed Maste from comment #1) JAR files also have META-INF/MANIFEST.MF. * https://www.baeldung.com/java-jar-manifest -- You are receiving this mail because: You are the assignee for the bug.
[Bug 261751] vt mouse pointer background display bug
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261751 Ed Maste changed: What|Removed |Added Summary|vt newcons mouse pointer|vt mouse pointer background |background display bug |display bug -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262282] Framework laptop touchpad latency
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262282 Bug ID: 262282 Summary: Framework laptop touchpad latency Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: ema...@freebsd.org Blocks: 262152 There is observable latency between certain touchpad actions and mouse movement. In the vt(4) console with moused running if I start without touching the touchpad, then touch and immediately move my finger there seems to be a delay of about 3/4 of a second before the cursor starts moving. If I place my finger on the touchpad but wait at least a second before moving there is a short (just barely perceptible) delay before the cursor moves. There is little delay while in X - seems to be barely perceptible if starting without touching the touchpad, and imperceptible if starting with a finger on the touchpad. FreeBSD main and drm-kmod master as of Feb 24 2022. Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262152 [Bug 262152] Framework Laptop: Feature support, bugs and improvements -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262152] Framework Laptop: Feature support, bugs and improvements
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262152 Ed Maste changed: What|Removed |Added Depends on||262282 Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262282 [Bug 262282] Framework laptop touchpad latency -- You are receiving this mail because: You are the assignee for the bug.
[Bug 259230] Touching the touchpad on a frame.work laptop causes reboot or poweroff
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259230 Ed Maste changed: What|Removed |Added Blocks||262152 Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262152 [Bug 262152] Framework Laptop: Feature support, bugs and improvements -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262152] Framework Laptop: Feature support, bugs and improvements
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262152 Ed Maste changed: What|Removed |Added Depends on||259230 Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259230 [Bug 259230] Touching the touchpad on a frame.work laptop causes reboot or poweroff -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262283] encoding of + in libfetch
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262283 Bug ID: 262283 Summary: encoding of + in libfetch Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: ronald-li...@klop.ws Created attachment 232193 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=232193&action=edit git diff in /lib/libfetch against 14-CURRENT Because of this mail thread https://lists.freebsd.org/archives/freebsd-ports/2022-February/001461.html I took a look at fetch. There is also information in the github link in the mails. What I found is that it is pretty easy to encode the + in the path of the URL. Although libfetch is spec compliant with and without this patch. This patch would provide more compatibility with non-spec compliant servers like S3/Cloudflare. My experience as a programmer is that encoding a space as a + is only done when building the query string so if we leave the query string as is we don't change valid URLs. If somebody encodes a space as a + in the host or path of an URI before passing it to libfetch the request will not work with the major (spec compliant) web servers. So I do not see possibilities for regression. So I think encoding the + as %2B in the path is very safe for requests to spec compliant servers and will prevent ambiguous requests to servers who do not follow the specs. An example of the encoding I implemented: fetch -vv "http://example.com/plus+space test?&q=a+b c" scheme: "http" user: "" password: "" host: "example.com" port: "0" document: "/plus%2bspace%20test?&q=a+b%20c" ... So the + and space before the question mark are percent-escaped. In the query string only the space is escaped for a correct http request line. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262283] encoding of + in libfetch
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262283 Ronald Klop changed: What|Removed |Added CC||d...@freebsd.org Attachment #232193||maintainer-approval?(des@Fr Flags||eeBSD.org) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262152] Framework Laptop: Feature support, bugs and improvements
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262152 Ed Maste changed: What|Removed |Added Depends on||260161 Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260161 [Bug 260161] usb enumeration stalls on a framework laptop -- You are receiving this mail because: You are the assignee for the bug.
[Bug 260161] usb enumeration stalls on a framework laptop
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260161 Ed Maste changed: What|Removed |Added Blocks||262152 Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262152 [Bug 262152] Framework Laptop: Feature support, bugs and improvements -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262086] usr.bin.diff.diff_test.functionname fails
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262086 --- Comment #3 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=adce4585ca56638801d12790c8f7fcb30e7408d0 commit adce4585ca56638801d12790c8f7fcb30e7408d0 Author: Li-Wen Hsu AuthorDate: 2022-03-01 21:37:25 + Commit: Li-Wen Hsu CommitDate: 2022-03-01 21:37:25 + Revert "Temporarily skip usr.bin.diff.diff_test.functionname in CI" This reverts commit 85eeb6ea62d45c5df893a16b87969bd7313a3dbb. The issue has been fixed by 4be7d087c2b566f4910683836be279d55c1a81c6. PR: 262086 usr.bin/diff/tests/diff_test.sh | 4 1 file changed, 4 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262086] usr.bin.diff.diff_test.functionname fails
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262086 Li-Wen Hsu changed: What|Removed |Added Resolution|--- |FIXED Assignee|b...@freebsd.org|t...@freebsd.org Status|New |Closed -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262152] Framework Laptop: Feature support, bugs and improvements
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262152 Bug 262152 depends on bug 259230, which changed state. Bug 259230 Summary: Touching the touchpad on a frame.work laptop causes reboot or poweroff https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259230 What|Removed |Added Status|In Progress |Closed Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug.
[Bug 259230] Touching the touchpad on a frame.work laptop causes reboot or poweroff
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259230 Vladimir Kondratyev changed: What|Removed |Added Resolution|--- |FIXED Status|In Progress |Closed --- Comment #20 from Vladimir Kondratyev --- MFC-ed to 13-STABLE: https://cgit.freebsd.org/src/commit/?id=77ec8dd61cb77ce7471dc0009bc8ec48b5e2cf81 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262282] Framework laptop touchpad latency
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262282 Vincent Milum Jr changed: What|Removed |Added CC||free...@darkain.com --- Comment #1 from Vincent Milum Jr --- In my particular case, the latency even in xorg is still very noticeable. It isn't the full ~1s delay as seen on the console, but it is probably somewhere in the neighborhood of 100ms. This delay is NOT seen when using Windows on the same laptop, and makes it a little frustrating to actually use with FreeBSD, as a user who is extremely sensitive to latency. The latency on FreeBSD isn't just the initial movement, it is continual throughout the entirety of moving the cursor on the screen, the feedback is always ~100ms behind the actual input being given. This same latency is NOT seen when using an external USB mouse on the same machine. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 246192] installer does not allow user to enter WiFi details if no networks found
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246192 --- Comment #2 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=912df915c266cc19ba6a8465c7e9e35eba0e3d85 commit 912df915c266cc19ba6a8465c7e9e35eba0e3d85 Author: Alfonso S. Siciliano AuthorDate: 2022-03-01 23:01:13 + Commit: Alfonso S. Siciliano CommitDate: 2022-03-01 23:04:57 + wlanconfig: allow to enter WiFi details if no networks found Improve the installer: wlanconfig allows user to enter WiFi details if no networks found, useful to connect to a hidden SSID. PR: 246192 Reported by:emaste Approved by:bapt (mentor) Differential Revision: https://reviews.freebsd.org/D34149 usr.sbin/bsdinstall/scripts/wlanconfig | 31 +++ 1 file changed, 15 insertions(+), 16 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262263] ahci: Unaligned free to UMA zone (ada_ccb)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262263 --- Comment #12 from Alexander Motin --- Created attachment 232194 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=232194&action=edit AHCI patch I think this patch should fix the 14 crash inside AHCI by not overwriting alloc_flags field in CCB header. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262263] ahci: Unaligned free to UMA zone (ada_ccb)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262263 Alexander Motin changed: What|Removed |Added Status|New |In Progress Assignee|b...@freebsd.org|m...@freebsd.org --- Comment #13 from Alexander Motin --- Please try the patch attached. I only checked that it builds, but haven't really tested. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 261751] vt mouse pointer background display bug
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261751 Stefan B. changed: What|Removed |Added Keywords||vt --- Comment #3 from Stefan B. --- I have made a photo, sorry for the bad quality. I can make other photos or vbox screenshots if needed for better quality. https://postimg.cc/CRxSJ3RK Please zoom into the upper-left corner and look at the red box surrounding the mouse cursor, below the letters "unk". This can be reproduced on any program that uses dialog, for example bsdinstall. The color background of all character boxes intersecting with the mouse cursor is affected. So the shape of the "red box" varies as you move the mouse, causing a less-than-ideal first impression of FreeBSD. I have not yet encountered any hardware on which this artifact does not happen. With the SC console, I have never seen this. So I am quite sure that it is not a hardware issue, but a vt newcons issue. BTW, as you can see, ensuring functional suspend/resume by autoconfiguring the "correct console to use" caused some substantial work for me while writing the Skunk Installer. It would be awesome if from some FreeBSD RELEASE version onward the Skunk Installer would no longer have to revert the computer to using the SC console. Thus I highly appreciate your work on fixing/improving vt newcons! Thank you very much! -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262241] gpart(8) destroy: option -F seems to not effectively destroy all partitions in some situations
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262241 Stefan B. changed: What|Removed |Added CC||sblachm...@gmail.com --- Comment #3 from Stefan B. --- Hmm. So "gpart destroy -F geom" does _not_ actually wipe the partition block, at least if it is a MBR one. Now I think I understand that strange error that I encountered when attempting to create a clone on a (formerly) MBR partitioned USB stick while testing my new Skunk Cloner (https://github.com/SkunkOS/SkunkCloner). If gpart destroy does _not_ work under some configurations, the only work-around to ensure clean partition data then would be to zero-dd the partition table. Honestly, I would rather prefer to be able to use gpart destroy to clear out any old partition data! I don't like having no other choice than to hackingly use dd to clear partition data. -- You are receiving this mail because: You are the assignee for the bug.
