[Bug 281218] Quectel LTE MODEM not working anymore
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281218 Bug ID: 281218 Summary: Quectel LTE MODEM not working anymore Product: Base System Version: 14.1-RELEASE Hardware: i386 OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: pickone...@yahoo.com Created attachment 253285 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=253285&action=edit SSH AT Commands Hi! I am using an intel N100 CPU config, with 16GB ram and 256 SSD, with OPNSense. The next issue I have it for about 3-4 weeks, after OPNSense released a new version. They said that the issue it is not from OPNSense, insteand, could be from FreeBSD, with the recommendation to fire a bug report here. FreeBSD version 14.1-RELEASE-p3 The issue is that my Quectel EP06-E it is not working anymore. I tried with USB adapter and directly to Mini PCI port, still not working. This is what I get into the OPNSense logs: 2024-08-12T14:18:23 Informational ppp [opt1_link0] Link: reconnection attempt 148 in 3 seconds 2024-08-12T14:18:23 Informational ppp [opt1_link0] LCP: Down event 2024-08-12T14:18:23 Informational ppp [opt1_link0] Link: DOWN event 2024-08-12T14:18:23 Informational ppp [opt1_link0] MODEM: chat script failed 2024-08-12T14:18:23 Informational ppp [opt1_link0] CHAT: The modem is not responding to "AT" at MomCmd: labeell. And the attachment is to see what I get with AT commands through SSH. Any solution to this? Thank you in advance! -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985 --- Comment #26 from Olivier Certner --- (In reply to Tomasz "CeDeROM" CEDRO from comment #24) Do you prefer "not able to test"? But to me, your own reactions so far, besides what you expressly wrote, border on "not willing to test". > There are various problems with AMDGPU / DRM / LinuxKPI that are reported by > various people Yes, but... > so I am not alone Well, judging by your stack traces and those reported by other users, it currently looks like you're alone, yes. > and those problems are disqualifying FreeBSD 14+ from a production use in > that setup Please stop spreading this FUD. Lots of people use FreeBSD 14 in production with DRM. I personally have several machines with AMD and Intel GPUs using stacks with 14 (and DRM 5.10, 5.15 and 6.1) and am really happy with them. And, at the risk of sounding repetitive, I also have a RX 580 like you, but contrary to you never saw a single crash on 14 (last ones were around 2 years ago... on 13-STABLE). There are some problems, more or less annoying, which I (and others) have reported in some bugs, but none are critical and more importantly they all can be worked around. Some people are also reporting crashes, part of which seem to happen in very specific situations (unlike what you're reporting). I have not seen any proof so far that these behaviors are regressions compared to an older stack (e.g., involving 13) or that the bug isn't present in a comparable Linux stack (same DRM version, and ideally same libraries). To my current knowledge, you're absolutely the only one claiming a regression from 13. If you don't have the time or will to test newer stacks, it's perfectly fine, and in any case you're responsible for your own strategy going forward. But you're also: - Spreading FUD by over-generalizing your own case. - Mixing problems by dumping your reports, traces and related advice in some bugs without having any evidence that these are really related (besides "my RX 580 crashes with amdgpu and 14"). Actually, a simple examination of stack traces in the various bugs could have lead you to see that on your own. When in doubt, create a new bug anyway, we can always mark it as a duplicate afterwards. This attitude is actively hampering, or even harming, problem reporting and resolution for *everyone*. So please stop it. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985 --- Comment #27 from Olivier Certner --- (In reply to feh from comment #22) Please build it from the graphics/drm-61-kmod ports directly then. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281218] Quectel LTE MODEM not working anymore
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281218 Franco Fichtner changed: What|Removed |Added CC||fra...@opnsense.org --- Comment #1 from Franco Fichtner --- I can't find a hint on why Quectel modems would stop behaving like they did on FreeBSD 13. We've recently tested Sierra just fine and the issue doesn't appear to be wide spread amongst modems. Tried reverting https://cgit.freebsd.org/src/commit/?id=d3a83456e1e3 but that didn't help. One thing of note in this commit's case is that it breaks the ascending order by device ID. What is absolutely out of whack is logging duplicated characters at the end of the comamnd: > CHAT: The modem is not responding to "AT" at MomCmd: labeell. > CHAT: line 358: label "MomIdentGeneriicc" not found Cheers, Franco -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281202] /usr/sbin/ntpd is broken in 13.4-RC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281202 Mark Linimon changed: What|Removed |Added Keywords||regression Summary|[regression] /usr/sbin/ntpd |/usr/sbin/ntpd is broken in |is broken in 13.4-RC|13.4-RC --- Comment #2 from Mark Linimon --- ^Triage: these days we denote regressions via the Keywords. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985 --- Comment #28 from f...@fehcom.de --- Hi, the drm-6.1.92 is installed and working now: $ kldstat | grep drm 232 0x8466700086090 drm.ko [erwin@amr5:~] $ pkg info drm* drm-61-kmod-6.1.92 Steps: 1. Download the ports tree. 2. In /usr/ports/graphics/drm-6.1-kmod did a make. 3. Disabled loading the AMD drivers (here in /etc/rc.conf) and automatic start of X11. 4. After reboot, removed the old drm driver; pkg delete drm.ko 5. make install in the ports dir (see 2.). 6. Enabled AMD graphic support again and 7. Rebooted the PC. So far, everything is working well. I'll update this bug report in case something significant needs to be added. Thanks for your support! --eh. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985 --- Comment #29 from Olivier Certner --- (In reply to feh from comment #28) Ok, great. I assume you tested your Nemo scenario? (In reply to Tomasz "CeDeROM" CEDRO from comment #19) Did you build the DRM modules you're using from the port? Or used an official binary package? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985 --- Comment #30 from Tomasz "CeDeROM" CEDRO --- (In reply to Olivier Certner from comment #26) Thanks Olivier. This is my last message in this thread. I will add another disk and create a dedicated install on this machine and report a separate bug as requested. As I explained before this is my main production workstation that keeps data and generates cash it cannot break for a second. I have other more powerful machines (i.e. recent MacStudio) but I prefer to stick to FreeBSD. After switching from 13 to 14 it crashed like crazy on exactly the same hardware setup, call it regression or whatever you like, for me it's not production ready because it does not allow me to work. I saw other people with AMGDPU problems so I added my info on my problem (not necessarily exactly the same problem I know). I am happy that your setup forks fine, and for your friends, but I would not ship a product like this knowing it does not work for me nor for some people. I just got used to comfort of a release being always rock solid. Thanks for pointing out its a different issue. Also thank you for pointing out I can work with 5.10, 5.15, and 6.10 on 14 release what is not possible on 13 (some documentation on this would be nice). If I knew what the problem is and how to fix it I would send patches not crash logs. Btw there is no need to use offensive aggressive and arrogant language (i.e. "you are not willing to test", "you're alone", "spreading FUD by over-generalizing your own case", etc). This is not a constructive and motivating language that I am used for to see here. I am not here to argue, especially with new kernel developer that may solve the problem, just to note "I also have serious problems with my AMDGPU drivers on 14 like the others reported and I do not know what the problem is". But I get the point. You see far more details and point the direction. And with no testing on the problematic hardware there will be no solution. I will create a dedicated install on a separate disk and try to help testing. I am just a bit scared to do this on a production machine you can imagine that - data loss here would cost me time, trust, and probably abandoning FreeBSD (on desktop). My last question - if you are the drm module maintainer / developer - would it be possible to mark following ports with incremental numbers like 510, 515, 610, not 61 for a newest release please (61 < 515)? Thank you for your time and have a good day Olivier.. its 12:00 here and I just finished writing a driver for external chip on RTOS after some ~36h non stop work.. all done on several FreeBSD machines.. tome to get some sleep :-) :-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281160] [PATCH] mfiutil: Fix unsafe assumptions of snprintf(3) return value in function 'mfi_autolearn_period'
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281160 WHR changed: What|Removed |Added Attachment #253207|0 |1 is obsolete|| --- Comment #3 from WHR --- Created attachment 253289 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=253289&action=edit proposed fix -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281160] [PATCH] mfiutil: Fix unsafe assumptions of snprintf(3) return value in function 'mfi_autolearn_period'
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281160 --- Comment #4 from WHR --- Included in https://github.com/freebsd/freebsd-src/pull/1405/ -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985 --- Comment #31 from f...@fehcom.de --- Hi, >> ok, great. I assume you tested your Nemo scenario? >> (In reply to Tomasz "CeDeROM" CEDRO from comment #19) >> Did you build the DRM modules you're using from the port? Or used an >> official binary package? as I said: drm-61 is coming from the ports. In my reply, I tried to make your upgrade easier while giving all the necessary hints. And well: The crash only happens *occassionally*. Of course I tried to copy files immediately. But as I said before: It is almost immpossible to prove the 'none-existance of bugs' - unless you have formal methods applied. Next, I'll have a look in the code to grasp the difference between 5.15 and 6.1. Since the crash-dumps provide some valuable information, at least I hope to come closer to understand the problem. --eh. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985 Bob Bishop changed: What|Removed |Added CC||r...@gid.co.uk --- Comment #32 from Bob Bishop --- (In reply to feh from comment #31) >> It is almost immpossible to prove the 'none-existance of bugs' - unless you >> have formal methods applied. "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Don Knuth -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985 --- Comment #33 from f...@fehcom.de --- Hi, > My last question - if you are the drm module maintainer / developer - would > it be > possible to mark following ports with incremental numbers like 510, 515, 610, > not 61 > for a newest release please (61 < 515)? AFAIK those numbers come from the Linux development. The AMD people build their drivers here and those numbers are related to the Kernel version: 5.15 => Linux Kernel 5.15 6.1 => Linux Kernel 6.1 (6.10 is current) It would not be a good idea to setup a new/different nameing scheme. As a developer/maintainer/porter I would rather stay close to upstream. --eh. PS: Linus doesn't follow Semantic Versioning strictly, thus there is no real breaking difference between the 5.x and 6.y branch. This may change with Rust in the kernel, but this is a different story. PPS: So far, the new DRM seems to work well. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985 --- Comment #34 from Olivier Certner --- (In reply to Tomasz "CeDeROM" CEDRO from comment #30) > Thanks Olivier. This is my last message in this thread. I hope not, and that you will answer the question I posted for you in comment #29. > I am happy that your setup forks fine, and for your friends, but I would not > ship a product like this knowing it does not work for me nor for some people. > I just got used to comfort of a release being always rock solid. I'm really amazed that this is your view on FreeBSD, especially on its graphics stack, after hanging around for so long. You must have forgotten the early 201x years, where, IIRC, you'd have to stick with >5 years old cards to get some acceleration. Of course, everyone supposedly tries its best to ship flawless (or, at least, functional) pieces of software. However, in practice, hardware support can be very difficult (and some hardware especially... uncooperative), and in particular the graphics stack is a beast of its own (I'm just a newbie here, gradually learning). It's not even developed in-house but rather imported from Linux, which gradually requires implementing the Linux KPI, and AFAIU we are undermanned for this task *alone*. Add to that the fact that even Linux DRM drivers are occasionally buggy (formerly, more often than not, but the situation seems to have improved in the past few years, but perhaps my view is biased as I avoid very recent hardware), and the numerous card models, even if based on the same chips. It's simply impossible to test all combinations. I can safely bet that if every amdgpu-supported GPUs really had been broken by the latest FreeBSD stacks, as you were insinuating, they wouldn't have been released as is, or they would have gotten a lot more attention. > Thanks for pointing out its a different issue. Well, to be crystal clear, while I responded also here for that point, I'm referring to what you posted in bug #278212, which seems clearly out of place. By contrast, in your stacks, I see one correspondence with earlier stacks posted here (bug #276985), one by feh@ and one by Vlad, where the crash happens in linux_rcu_cleaner_func() (and there's another one on Reddit). So there may be something in common, I just don't know at this time (perhaps someone else would have a hint). If you intend to post more traces/dumps or more explanations on your scenarios, it would be wise to open a new bug, yes. > Also thank you for pointing out I can work with 5.10, 5.15, and 6.10 on 14 > release what is not possible on 13 (some documentation on this would be nice). It's a very useful possibility indeed. It should have been documented, but can also be inferred by looking at the available ports and the content of their Makefile. However, I've heard that the plan going forward is to integrate back DRM into base. If carried out, such substitution isn't going to be possible anymore unfortunately. > If I knew what the problem is and how to fix it I would send patches not > crash logs. Sending crash logs is not the problem I'm pointing out. Crash logs are welcome. Not being able to fix isn't a problem per-se either. The problem is where you attached logs and posted comments, and the necessity to describe things factually, from the scenario of your interactions with the computer to the problem you're experiencing, with details on the hardware and software (versions in particular) used, without conflating or extrapolating things. In complex matters like this, it is also precious to be able to re-test with slight changes to be able to spot differences in behavior. These are areas where you can actually make progress and help. > Btw there is no need to use offensive aggressive and arrogant language (i.e. > "you are not willing to test", "you're alone", "spreading FUD by > over-generalizing your own case", etc). "not willing to test" was my feeling, although when I first wrote that I used "willing" in a broader sense than the one you actually received. "you're alone" is simply re-using your own words. And "spreading FUD by over-generalizing your own case", as I already explained, is just describing a factual reality. I certainly did not intend to be offensive nor arrogant, and I don't think I was. I've just been factual, and firm about some principles without which everybody is losing time, trust, etc. On the contrary, bragging in multiple, loosely related bugs that 14 with DRM is generally unsuitable for production use is what is aggressive, and more importantly, as I showed, wrong and unproductive. There is no denying that there are still problems (I already wrote some rough summary above), and my aim is precisely to nail them to be able to get rid of them, if possible. > This is not a constructive and motivating language that I am used for to see > here. On the contrary, my messages are (at least, aim to be) very constructive, and it is exactl
[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985 --- Comment #35 from Olivier Certner --- (In reply to feh from comment #33) > PPS: So far, the new DRM seems to work well. Great! I'm tempted to close this PR, but ideally would prefer some additional input from Vlad and Tomek before doing so (please install 14.1, self-compile the graphics/drm-61-kmod port, test and report success or failure). So, AFAIC, I'll leave it opened for a short while. We can always re-open it as necessary anyway. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985 --- Comment #36 from Olivier Certner --- (In reply to feh from comment #31) >> (In reply to Tomasz "CeDeROM" CEDRO from comment #19) >> Did you build the DRM modules you're using from the port? Or used an >> official binary package? > as I said: drm-61 is coming from the ports. In my reply, I tried to make your > upgrade easier while giving all the necessary hints. That question was for Tomasz, not you. :-) (In reply to Bob Bishop from comment #32) I wouldn't fly a plane whose code hasn't both been proved correct *and* tested. :-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985 --- Comment #37 from f...@fehcom.de --- (In reply to Olivier Certner from comment #35) I just checked both drm versions (5.15 and 6.1) briefly, but the difference is significant, so it will be hard to tell whether the new version is the correct solution. AMD needs of course to provide driver for their new GPUs. As said, their development focuses on the Linux kernel. One particular mechanism here is 'rcu' - Ready/Copy/Update. I'm wondering how is is realized under FreeBSD. @Oliver: Is there any whitepaper or so, detailing this, perhaps while reverse-engineering the code base? And regarding: > I wouldn't fly a plane whose code hasn't both been proved correct *and* > tested. In this sector of the industry, formal proof methods will be applied. Hardware redundancy/diversity is also important. We have to thank all volunteers here to come close that quality for an OS you can get for free and running realiably on HW for just $300 (like mine). --eh. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281242] .include directive in ctl.conf doesn't workfile as supposed to per UCL file standard
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281242
Bug ID: 281242
Summary: .include directive in ctl.conf doesn't workfile as
supposed to per UCL file standard
Product: Base System
Version: 14.1-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: conf
Assignee: b...@freebsd.org
Reporter: gnoma...@gbg.bg
At the bottom of my /etc/ctl.conf got the following directive:
.include /etc/ctl.d/proxmoxtest.conf
It's a valid configuration file, if I place it's content inside /etc/ctl.conf
it works perfectly fine.
Expected result:
ctld starts OK
Actual result:
root@mysystem:/usr/src/lib/libucl # /etc/rc.d/ctld start
Starting ctld.
ctld: error in configuration file at line 28 near '.include': syntax error
ctld: configuration error; exiting
/etc/rc.d/ctld: WARNING: failed to start ctld
root@mysystem:/usr/src/lib/libucl #
The behavior doesn't change if the included file is there or not, if included
the file syntax is correct or not.
This is the last part of "truss ctld -t"
open("/etc/ctl.conf",O_RDONLY,0666) = 5 (0x5)
ioctl(5,TIOCGETA,0xf380fced854) ERR#25 'Inappropriate ioctl
for device'
ioctl(5,TIOCGETA,0xf380fced854) ERR#25 'Inappropriate ioctl
for device'
fstat(5,{ mode=-rw-r- ,inode=571054,size=464,blksize=4096 }) = 0 (0x0)
read(5,"portal-group pg0 {\n\tdiscovery-"...,4096) = 464 (0x1d0)
read(5,0x33b37cc09000,4096) = 0 (0x0)
ctld: error in configuration file at line 28 near '.include': syntax error
write(2,"ctld: error in configuration fil"...,75) = 75 (0x4b)
open("/etc/localtime",O_RDONLY,01717)= 6 (0x6)
read(6,"TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0"...,54968) = 2077 (0x81d)
close(6) = 0 (0x0)
__sysctl("kern.hostname",2,0xf380fced530,0xf380fce9418,0x0,0) = 0 (0x0)
getpid() = 11333 (0x2c45)
sendto(3,"<28>1 2024-09-03T16:48:47.586183"...,146,0,NULL,0) = 146 (0x92)
close(5) = 0 (0x0)
ctld: configuration error; exiting
write(2,"ctld: configuration error; exiti"...,35) = 35 (0x23)
__sysctl("kern.hostname",2,0xf380fced700,0xf380fce95e8,0x0,0) = 0 (0x0)
getpid() = 11333 (0x2c45)
sendto(3,"<26>1 2024-09-03T16:48:47.586764"...,106,0,NULL,0) = 106 (0x6a)
exit(0x1)
process exit, rval = 1
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 281242] .include directive in ctl.conf file doesn't work as supposed to per UCL file standard
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281242 gnoma changed: What|Removed |Added Summary|.include directive in |.include directive in |ctl.conf doesn't workfile |ctl.conf file doesn't work |as supposed to per UCL file |as supposed to per UCL file |standard|standard -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281160] [PATCH] mfiutil: Fix unsafe assumptions of snprintf(3) return value in function 'mfi_autolearn_period'
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281160 --- Comment #5 from Mark Johnston --- (In reply to WHR from comment #2) Well, they're related in that they all touch mfiutil. It's ok for commits in a pull request to be unrelated, so long as each commit has a single, well-defined purpose. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985 --- Comment #38 from Olivier Certner --- (In reply to feh from comment #37) Could you also build drm-515-kmod yourself, install it in lieu of drm-61-kmod, and test again? I'd like to know if building the module by hand makes the crashes disappear. (Obviously, this is relevant only if you didn't do that from the start when testing drm-515-kmod.) > Is there any whitepaper or so, detailing this, perhaps while > reverse-engineering the code base? You can find plenty of information on the web about RCU, such as: https://www.kernel.org/doc/html/latest/RCU/whatisRCU.html if that is your question? We have a couple of mechanisms in the FreeBSD kernel doing similar things. > We have to thank all volunteers here to come close that quality for an OS you > can get for free and running realiably on HW for just $300 (like mine). Of course. And also paid people catering to other users' needs. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985 --- Comment #39 from Tomasz "CeDeROM" CEDRO --- Yes I have tried both from pkg and built from the ports no difference, but it was around 14.0, now 14.1 is out (working fine on my laptop with intel drm 5.15 even backlight control). I wish I could try it now but really don't have time to play at this moment sorry. I know the fix can be using 6.1 or even 5.10 on 14.1 that's good enough there is a light in the tunnel :-) To be honest I could even use SCFB as fallback if it only supported multi monitor setup with separate rotation per display as I mostly work in terminal + tmux + vim and some web browser (unless KiCAD/FreeCAD/Blender/OBS is required but not really right now). Thank you folks and have a good day :-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 267671] [libc] Remove unnecessary printf to stderr in stdlib/cxa_thread_atexit_impl.c
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267671 Erik Jensen changed: What|Removed |Added Version|13.1-RELEASE|Unspecified Hardware|amd64 |Any -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985 --- Comment #40 from f...@fehcom.de --- (In reply to Olivier Certner from comment #38) Hi Olivier, well, I tried, but was not successful: 1. Called make uninstall in /usr/ports/graphics/drm-61-kmod (ok). 2. Called make install in .../drm-515-kmod (ok). After reboot, I got the following messages via dmesg (X did not start): link_elf_obj: symbol dma_resv_add_ecl_fence undefined linker_load file: /boot/modules/ttm.ko - unsupported file type KLD ambdgpu.ko: depends on ttm - not available or version mismatch Warning: memory type debugfsint leaked memory on destroy (2 allocations, 80 bytes leaked). linker_load_file: /boot/modules/amdgpu.ko - unsupported file type 3. After removing 5.15 and re-installing 6.1 everythings seems fine again (dmesg): [drm] amdgpu kernel modesetting enabled. drmn0: on vgapci0 vgapci0: child drmn0 requested pci_enable_io vgapci0: child drmn0 requested pci_enable_io [drm] initializing kernel modesetting (RENOIR 0x1002:0x164C 0x1002:0x0123 0xC1). [drm] register mmio base: 0xFCA0 [drm] register mmio size: 524288 [drm] add ip block number 0 [drm] add ip block number 1 [drm] add ip block number 2 [drm] add ip block number 3 [drm] add ip block number 4 [drm] add ip block number 5 [drm] add ip block number 6 [drm] add ip block number 7 [drm] add ip block number 8 [drm] add ip block number 9 drmn0: Fetched VBIOS from VFCT amdgpu: ATOM BIOS: 113-LUCIENNE-016 drmn0: successfully loaded firmware image 'amdgpu/renoir_sdma.bin' [drm] VCN decode is enabled in VM mode [drm] VCN encode is enabled in VM mode [drm] JPEG decode is enabled in VM mode drmn0: Trusted Memory Zone (TMZ) feature enabled drmn0: PCIE atomic ops is not supported drmn0: MODE2 reset [drm] vm size is 262144 GB, 4 levels, block size is 9-bit, fragment size is 9-bit drmn0: VRAM: 512M 0x00F4 - 0x00F41FFF (512M used) drmn0: GART: 1024M 0x - 0x3FFF drmn0: AGP: 267419648M 0x00F8 - 0x [drm] Detected VRAM RAM=512M, BAR=512M [drm] RAM width 128bits DDR4 [drm] amdgpu: 512M of VRAM memory ready [drm] amdgpu: 7856M of GTT memory ready. [drm] GART: num cpu pages 262144, num gpu pages 262144 [drm] PCIE GART of 1024M enabled. [drm] PTB located at 0x00F41FC0 drmn0: successfully loaded firmware image 'amdgpu/renoir_asd.bin' drmn0: successfully loaded firmware image 'amdgpu/renoir_ta.bin' drmn0: PSP runtime database doesn't exist drmn0: PSP runtime database doesn't exist drmn0: successfully loaded firmware image 'amdgpu/renoir_dmcub.bin' [drm] Loading DMUB firmware via PSP: version=0x01010027 drmn0: successfully loaded firmware image 'amdgpu/renoir_pfp.bin' drmn0: successfully loaded firmware image 'amdgpu/renoir_me.bin' drmn0: successfully loaded firmware image 'amdgpu/renoir_ce.bin' drmn0: successfully loaded firmware image 'amdgpu/renoir_rlc.bin' drmn0: successfully loaded firmware image 'amdgpu/renoir_mec.bin' drmn0: successfully loaded firmware image 'amdgpu/renoir_vcn.bin' [drm] Found VCN firmware Version ENC: 1.20 DEC: 5 VEP: 0 Revision: 3 drmn0: Will use PSP to load VCN firmware [drm] reserve 0x40 from 0xf41f40 for PSP TMR drmn0: RAS: optional ras ta ucode is not available drmn0: RAP: optional rap ta ucode is not available [drm] psp gfx command LOAD_TA(0x1) failed and response status is (0x7) [drm] psp gfx command INVOKE_CMD(0x3) failed and response status is (0x4) drmn0: Secure display: Generic Failure.drmn0: SECUREDISPLAY: query securedisplay TA failed. ret 0x0 drmn0: SMU is initialized successfully! [drm] Display Core initialized with v3.2.207! [drm] DMUB hardware initialized: version=0x01010027 lkpi_iic0: on drmn0 $ kldstat | grep drm 232 0x8466700086090 drm.ko $ kldstat | grep amd 221 0x8400 666888 amdgpu.ko 291 0x846fb000 64e0 amdgpu_renoir_sdma_bin.ko 301 0x847020002c2e0 amdgpu_renoir_asd_bin.ko 311 0x8472f000 c4e0 amdgpu_renoir_ta_bin.ko 321 0x8473c0001fbe8 amdgpu_renoir_dmcub_bin.ko 331 0x8475c000 7560 amdgpu_renoir_pfp_bin.ko 341 0x84764000 6560 amdgpu_renoir_me_bin.ko 351 0x83ffa000 4560 amdgpu_renoir_ce_bin.ko 361 0x8476b000 bcd8 amdgpu_renoir_rlc_bin.ko 371 0x8477700043800 amdgpu_renoir_mec_bin.ko 381 0x847bb000645a0 amdgpu_renoir_vcn_bin.ko 391 0x8482 3160 amdtemp.ko 401 0x84824000 2138 amdsmn.ko I hope, this is enough information for you to carry on with a diagnosis. Thx. --eh. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281218] Quectel LTE MODEM not working anymore
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281218 Mark Linimon changed: What|Removed |Added Keywords||regression, vendor -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281211] MV88E6190X switch variant not supported by e6000sw
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281211 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281151] [patch] source upgrade path broken for stable/12 to stable/13 due to bmake
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281151 Mark Linimon changed: What|Removed |Added Resolution|--- |FIXED Assignee|b...@freebsd.org|s...@freebsd.org Status|New |Closed --- Comment #3 from Mark Linimon --- ^Triage: assign to committer who resolved. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985 --- Comment #41 from Olivier Certner --- (In reply to feh from comment #40) If no crash occurs from now on, then no more diagnosis will be absolutely necessary. Otherwise, I don't think the information we have will be sufficient. But even if you don't encounter crashes anymore, I'd really like to check if building by hand drm-515-kmod also solves your problem. > 2. Called make install in .../drm-515-kmod (ok). > > After reboot, I got the following messages via dmesg (X did not start): > (snip) At this step, you're apparently installing the result of an old build, instead of rebuilding drm-515-kmod. You should first issue a `make clean` before launching `make install`. Could you please retry with this procedure? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985 --- Comment #42 from f...@fehcom.de --- (In reply to Olivier Certner from comment #41) Hi Olivier, > At this step, you're apparently installing the result of an old build, > instead of > rebuilding drm-515-kmod. You should first issue a `make clean` before > launching `make > install`. Could you please retry with this procedure? You did not read my detailed set of instructions: I installed the ports via portsnap today from scratch. For the rest, you are speculating. There is no room left for your suggestion. Sorry. --eh. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281257] base llvm csetjmp C++ header file now generates an error
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281257 Bug ID: 281257 Summary: base llvm csetjmp C++ header file now generates an error Product: Base System Version: 14.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: misc Assignee: b...@freebsd.org Reporter: b...@mrp3.com Attachment #253310 text/plain mime type: Created attachment 253310 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=253310&action=edit shar file for graphics/xaos containing patch In 2 cases I have attempted to build ports using the latest llvm compiler that comes with 14.1 RELEASE. graphics/xaos graphics/inkscape In both of these cases, one source file made use of 'csetjmp'.which displays an error message now. Changing the include from ' to '' works around it. #error "If libc++ starts defining , the __has_include check should move to libc++'s " the 2 patches in the respective 'files' directories in the port appear to work around it The real problem seems to be the llvm headers, however, as patching the ports only works for 14.1 RELEASE (probably) uname strug: FreeBSD hack.SFT.local 14.1-RELEASE FreeBSD 14.1-RELEASE GENERIC amd64 NOTE: new xaos patch actually has a second fix in it which I'll submit separately. These are both workarounds, really -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281257] base llvm csetjmp C++ header file now generates an error
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281257 Bob Frazier changed: What|Removed |Added Attachment #253311|application/x-shar |text/plain mime type|| --- Comment #1 from Bob Frazier --- Created attachment 253311 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=253311&action=edit shar file for graphics/inkscape containing a patch (workaround) not intended as a permanent fix (either one actually) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281257] base llvm csetjmp C++ header file now generates an error
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281257 --- Comment #2 from Bob Frazier --- we can add devel/glog to the list of affected ports -- You are receiving this mail because: You are the assignee for the bug.
[Bug 260898] audible skips and video jitter during video playback
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260898 --- Comment #17 from Bob Frazier --- Recently installed 14.1-RELEASE. The bug was observed on 12.2 and I would occasionally see it affect icecast by skipping parts of songs or leaving 'dead air' gaps in he stream. Since upgrading to 14.1-RELEASE I am not seeing this behavior. As such there is at least some indication that multimedia clocks are at least more consistent. Once I have finished upgrading 2 machines I can give this a proper test. Still nice to know that in the newer RELEASE version it may have been fixed. -- You are receiving this mail because: You are the assignee for the bug.
