Se connecter

Recherches récentes

Aucune recherche récente

Options de recherche

Disponible uniquement lorsque vous êtes connecté.
framapiaf.org est l'un des nombreux serveurs Mastodon indépendants que vous pouvez utiliser pour participer au fédiverse.
Un service Mastodon fourni par l'association d’éducation populaire Framasoft.

Administré par :

Statistiques du serveur :

1,4K
comptes actifs

framapiaf.org: À proposÉtatAnnuaire des profilsPolitique de confidentialité

Mastodon: À proposTélécharger l’applicationRaccourcis clavierVoir le code sourcev4.3.7

#debugging

8 messages7 participants0 message aujourd’hui
Suite du fil
Public
michabbb

Building a comprehensive knowledge graph of your code, Potpie's agents understand complex relationships and assist with everything from #debugging to feature development.
Potpie offers a suite of specialized codebase agents:

Public
Miguel Afonso Caetano

"[T]hose claiming we're mere months away from AI agents replacing most programmers should adjust their expectations because models aren't good enough at the debugging part, and debugging occupies most of a developer's time. That's the suggestion of Microsoft Research, which built a new tool called debug-gym to test and improve how AI models can debug software.

Debug-gym (available on GitHub and detailed in a blog post) is an environment that allows AI models to try and debug any existing code repository with access to debugging tools that aren't historically part of the process for these models. Microsoft found that without this approach, models are quite notably bad at debugging tasks. With the approach, they're better but still a far cry from what an experienced human developer can do.
(...)
This approach is much more successful than relying on the models as they're usually used, but when your best case is a 48.4 percent success rate, you're not ready for primetime. The limitations are likely because the models don't fully understand how to best use the tools, and because their current training data is not tailored to this use case."

arstechnica.com/ai/2025/04/res

Real Java Script code developing screen. Programing workflow abstract algorithm concept. Closeup of Java Script and HTML code.
Ars Technica · AI isn’t ready to replace human coders for debugging, researchers sayPar Samuel Axon
#AI#GenerativeAI#Programming
Suite du fil
Public
♡ Eva Winterschön ♡

Panic most recently used by lkpikmalloc ...

Well, that was fast... didn't even get a mouse cursor of a full MATE Desktop menu system load. Was yet to connect kgdb to COM1 (need to swap from minicom to do so)... makes me want a PCIe RS232 card (for "comconsole_pcidev") so that I have a few more COMs to play with on redirects. Gotta love these iGPU tash-bins eh? "It's better than not having a GPU right?" ... not really.''

Closed bug report from the drm-515-kmod, discussing amdgpu memory leak. so, maybe a new one in drm-61-kmod, would not be surprised.
- github.com/freebsd/drm-kmod/is

Short term revision of approach:
----

1. Today via post arrives, an AMD Radeon Pro W7500 (single slot 8GB, Navi-whatever gen)
2. I'll block off the iGPU during loader.conf sequence, using a "pptdev" blackhole (not for VM pt, but maybe an experiment for a 14.1 VM with the known-good amdgpu version).
3. Known as: throw money at the problem?

Some hardware notes:
----

1. This is not a Nvidia GPU situation; there are several generations of cards in the room which have been cycled through the workstation during "hardware isolation" and "process of elimination" sequences. I know those are stable, and which gen cards require which nvidia driver versions for stability purposes.

2. This is not a FreeBSD kernel issue, nor a Xorg "Plain Jane FrameBuffer" situation. The kernel (14.0, 14.1, 14.2) is stable and fine, and the basic vt driver for non-4K display-port functionality works fine. I can work all day in a series of tmux windows with some fifty or so panes, but that's not quite the optimal experience.

3. The AMD iGPU (Raphael) maxes out default to 512MB GART VRAM, and it can handle 240Hz @ 4K all day with no issues as long as that 512M doesn't get used up... that is until the latest amdgpu kmod drm, which crashes whenever it feels like it.

Michael... yes yes, I do have a lot of hardware, but this issue has surpassed the Sunk Cost Fallacy and has become a consumate knowledge-requirement process. I must know where this is failing so horrendously, otherwise the operating rule of "if it doesn't fulfill its hardware destiny, it will get the hammer and flames"... and the hardware is too nice for that - plus I could involve Supermicro support since it's still in warranty, but a replacement motherboard or CPU for the iGPU isn't going to solve a kernel module issue.

In the interim, laptop life and tablet meetings are getting me by, mostly decently.

Debug items of interest:
----
intsmb0: <AMD FCH SMBus Controller> at device 20.0 on pci0
intsmb0: Could not allocate I/O space
device_attach: intsmb0 attach returned 6

drmn0: Fetched VBIOS from VFCT
amdgpu: ATOM BIOS: 102-RAPHAEL-008
drmn0: Trusted Memory Zone (TMZ) feature not supported
drmn0: PCIE atomic ops is not supported
drmn0: VRAM: 512M 0x000000F400000000 - 0x000000F41FFFFFFF (512M used)
[drm ERROR :amdgpu_bo_init] Unable to set WC memtype for the aperture base

Loader items of usage:
----
# Multi-Console Output
# boot output primary: TTY, standard monitor via UEFI
# boot output secondary: COM1 RS232 Redirect (physical)
# boot output tertiary: COM2 RS232 Redirect (BMC SoL)
ipmi_load="YES"
boot_mute="NO"
boot_verbose="YES"
verbose_loading="YES"
boot_multicons="YES"
boot_serial="YES"
console="efi,comconsole,comconsole"
comconsole_port1="0x3F8"
comconsole_speed1="115200"
comconsole_port2="0x2F8"
comconsole_speed2="115200"
hw.uart.console="io:0x3f8,br:115200 io:0x2f8,br:115200"

#amd#gpu#drm616kmod
Public
♡ Eva Winterschön ♡

💾 4am AMD Xorg/Kernel Debugging 💾

Ongoing fun ongoes, so much so. This iteration receives triple output: tty video (Display Port), COM1 redirect via DB9 to laptop running minicom, COM2 to the usual BMC SoL terminal watched from ipmitool on adjacent laptop.

Coming up, rebooting into GENERIC-DEBUG kernel rebuilt with remote GDM (kgdb) access via the COM1 link to laptop.

monitor connected to desktop, showing Xorg session log during tty crash handler exit
monitor connected to desktop, with separate laptop connected to desktop via COM1 and COM2 serial links, as described in the post. color and contrast boosted for low light readability.
#freebsd#epyc#desktop
ExplorerFlux en direct
À propos