Re: loading drm crashes system
Me: > Try September 26 as a reference date. s/September 26/September 6/ ; src = r365372 Respectfully, Robert "Gotcha, ya little bugger!" Huff ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: loading drm crashes system
On Mon, 25 Jan 2021 22:21:16 -0500 Robert Huff wrote: > Niclas Zeising asks: > > > Which version of drm-current-kmod? > > 5.4.62.g20210118 > > > Can you try to remove it and build it directly from an updated ports > > tree, without using PORTS_MODULES=, and see if that helps? > > It does not. > > > > The GPU is a Radeon HD 3300, and at one point this used to > > work. > > > > When did it stop working? > > September ... I _think_. > After the switch from sc to vt+drm, things worked for a while > ... then they didn't for several months ... then - September??? - they > worked for about two weeks ... then they didn't again. September 10 is when drm-current-kmod was updated from 4.16 to 5.4: https://svnweb.freebsd.org/ports/head/graphics/drm-current-kmod/Makefile There haven't been that many updates since then so you could test ports r548210 with base system from the same date. If that works try r548601, r551266 and r554720. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: loading drm crashes system
On Tue, 26 Jan 2021 13:42:45 +0100 Emmanuel Vadot wrote: > On Tue, 26 Jan 2021 07:02:11 + > Alexey Dokuchaev wrote: >> On Mon, Jan 25, 2021 at 10:21:16PM -0500, Robert Huff wrote: >>> Niclas Zeising asks: When did it stop working? >>> >>> September ... I _think_. >> >> Yeah, that sounds about right. >> >> There are known issues with Radeon cards, they were quite well supported >> a year ago, then something got broken. I've promised to bisect this and >> find the cause, but there were several syscall-related changes in -CURRENT >> though the course of the last year, so bisecting just the kernel is not >> enough (machine won't get to login prompt if the userland does not match), >> which cripples the process. >> >> I still intend to take this quest, just not sure when. :( > > So back in November I applied a few commits from tijl@ related to > radeon and i386 (added to cc) : > https://github.com/freebsd/drm-kmod/commits/5.4-lts?author=t...@coosemans.org > > For me this fixed radeon so that gives some timeline if someone with > non working hardware wants to bisect. > I know that bisecting drm-kmod is somewhat hard as you always need > matching kernel code when we update it to use some new functionality in > base linuxkpi but there is nothing that I can do about it. > It might work and be quicker to only bisect the kernel with a > stable/12 userland (no need to recompile) so I would start by testing a > kernel from early november and same date for drm-kmod. > > Tijl since you also reported a build failure a few days/weeks ago for > radeon can you report if your radeon card works ? (And which one it is). My card works (14.0-CURRENT from last Sunday) but it is an old radeon 9700 from 2004 so it doesn't have any fancy modern features and uses only a small part of the radeon driver. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: loading drm crashes system
Hello: > > Niclas Zeising asks: > > > When did it stop working? > > > > September ... I _think_. > > Yeah, that sounds about right. > > There are known issues with Radeon cards, they were quite well > supported a year ago, then something got broken. I've promised to > bisect this and find the cause, but there were several syscall-related > changes in -CURRENT though the course of the last year, so bisecting > just the kernel is not enough (machine won't get to login prompt if > the userland does not match), which cripples the process. > > I still intend to take this quest, just not sure when. :( Expanding on "September ... I think": Try September 26 as a reference date. Sometime close to then I a) updated world+kernel to the latest version of current, so also b) updated to the latest drm-current-kmod and gpu-firmware. Question: is there a way for the less sophisticated user to tell whether the cause is in the drm knod or the firmware kmod? Hope this helps, Robert Huff -- Hello ... my name is SARS-CoV-2. You are not wearing a mask? Prepare to die! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: loading drm crashes system
On Tue, 26 Jan 2021 07:02:11 + Alexey Dokuchaev wrote: > On Mon, Jan 25, 2021 at 10:21:16PM -0500, Robert Huff wrote: > > Niclas Zeising asks: > > > When did it stop working? > > > > September ... I _think_. > > Yeah, that sounds about right. > > There are known issues with Radeon cards, they were quite well supported > a year ago, then something got broken. I've promised to bisect this and > find the cause, but there were several syscall-related changes in -CURRENT > though the course of the last year, so bisecting just the kernel is not > enough (machine won't get to login prompt if the userland does not match), > which cripples the process. > > I still intend to take this quest, just not sure when. :( > > ./danfe So back in November I applied a few commits from tijl@ related to radeon and i386 (added to cc) : https://github.com/freebsd/drm-kmod/commits/5.4-lts?author=t...@coosemans.org For me this fixed radeon so that gives some timeline if someone with non working hardware wants to bisect. I know that bisecting drm-kmod is somewhat hard as you always need matching kernel code when we update it to use some new functionality in base linuxkpi but there is nothing that I can do about it. It might work and be quicker to only bisect the kernel with a stable/12 userland (no need to recompile) so I would start by testing a kernel from early november and same date for drm-kmod. Tijl since you also reported a build failure a few days/weeks ago for radeon can you report if your radeon card works ? (And which one it is). Cheers, -- Emmanuel Vadot ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: loading drm crashes system
W dniu 26.01.2021 o 08:02, Alexey Dokuchaev pisze: On Mon, Jan 25, 2021 at 10:21:16PM -0500, Robert Huff wrote: Niclas Zeising asks: When did it stop working? September ... I _think_. Yeah, that sounds about right. There are known issues with Radeon cards, they were quite well supported a year ago, then something got broken. I've promised to bisect this and find the cause, but there were several syscall-related changes in -CURRENT though the course of the last year, so bisecting just the kernel is not enough (machine won't get to login prompt if the userland does not match), which cripples the process. I still intend to take this quest, just not sure when. :( ./danfe ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" TBH I have backed up deprecated port graphics/drm-legacy-kmod and use it on 13-ALPHA. The port graphics/drm-current-kmod was unusable (console resolution, flaky gdm start etc.), tough no panics were observed. One should be still able to build graphics/drm-legacy-kmod on 14-CURRENT for some time till the issue gets resolved. -- Marek Zarychta ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: loading drm crashes system
On Mon, Jan 25, 2021 at 10:21:16PM -0500, Robert Huff wrote: > Niclas Zeising asks: > > When did it stop working? > > September ... I _think_. Yeah, that sounds about right. There are known issues with Radeon cards, they were quite well supported a year ago, then something got broken. I've promised to bisect this and find the cause, but there were several syscall-related changes in -CURRENT though the course of the last year, so bisecting just the kernel is not enough (machine won't get to login prompt if the userland does not match), which cripples the process. I still intend to take this quest, just not sure when. :( ./danfe ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: loading drm crashes system
Niclas Zeising asks: > Which version of drm-current-kmod? 5.4.62.g20210118 > Can you try to remove it and build it directly from an updated ports > tree, without using PORTS_MODULES=, and see if that helps? It does not. > > The GPU is a Radeon HD 3300, and at one point this used to work. > > When did it stop working? September ... I _think_. After the switch from sc to vt+drm, things worked for a while ... then they didn't for several months ... then - September??? - they worked for about two weeks ... then they didn't again. Respectfully, Robert Huff ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: loading drm crashes system
On 2021-01-25 00:19, Robert Huff wrote: Hello: On a system now running: 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-d6327ae8c1: Sun Jan 24 14:16:54 EST 2021 amd64 (src+ports updated at midnight US EST) with PORTS_MODULES="drm-current-kmod gpu-firmware-kmod", starting the system _without_ loading drm results in a usable system. Loading drm - whether via kldlist in rc.conf or by kldload at the console immediately after start-up - instantly crashes the system; the screen goes blank and the lights on the monitor report no signal from the system. [snip error log] [insert image of open jaw and glassy-eyed stare] The GPU is a Radeon HD 3300, and at one point this used to work. Help, please? When did it stop working? Which version of drm-current-kmod? Can you try to remove it and build it directly from an updated ports tree, without using PORTS_MODULES=, and see if that helps? Regards -- Niclas ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
loading drm crashes system
Hello: On a system now running: 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-d6327ae8c1: Sun Jan 24 14:16:54 EST 2021 amd64 (src+ports updated at midnight US EST) with PORTS_MODULES="drm-current-kmod gpu-firmware-kmod", starting the system _without_ loading drm results in a usable system. Loading drm - whether via kldlist in rc.conf or by kldload at the console immediately after start-up - instantly crashes the system; the screen goes blank and the lights on the monitor report no signal from the system. There is nothing in dmesg.boot. In messages I find (75 lines follow): Jan 24 17:35:22 jerusalem kernel: [drm:drm_core_init] Initialized Jan 24 17:35:22 jerusalem kernel: [drm] radeon kernel modesetting enabled. Jan 24 17:35:22 jerusalem kernel: drmn0: on vgapci0 Jan 24 17:35:22 jerusalem kernel: vgapci0: child drmn0 requested pci_enable_io Jan 24 17:35:22 jerusalem kernel: [drm:drm_minor_register] Jan 24 17:35:22 jerusalem kernel: [drm:drm_minor_register] new minor registered 128 Jan 24 17:35:22 jerusalem kernel: [drm:drm_minor_register] Jan 24 17:35:22 jerusalem kernel: [drm:drm_minor_register] new minor registered 0 Jan 24 17:35:22 jerusalem kernel: [drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1849:0x9614 0x00). Jan 24 17:35:22 jerusalem kernel: [drm:radeon_get_bios] ATOMBIOS detected Jan 24 17:35:22 jerusalem kernel: [drm ERROR :radeon_atombios_init] Unable to find PCI I/O BAR; using MMIO for ATOM IIO Jan 24 17:35:22 jerusalem kernel: [drm:atom_allocate_fb_scratch] atom firmware requested 17ffb000 20kb Jan 24 17:35:22 jerusalem kernel: drmn0: VRAM: 384M 0xC000 - 0xD7FF (384M used) Jan 24 17:35:22 jerusalem kernel: drmn0: GTT: 512M 0xA000 - 0xBFFF Jan 24 17:35:22 jerusalem kernel: [drm] Detected VRAM RAM=384M, BAR=256M Jan 24 17:35:22 jerusalem kernel: [drm] RAM width 32bits DDR Jan 24 17:35:22 jerusalem kernel: [drm] radeon: 384M of VRAM memory ready Jan 24 17:35:22 jerusalem kernel: [drm] radeon: 512M of GTT memory ready. Jan 24 17:35:22 jerusalem kernel: [drm:r600_init_microcode] Jan 24 17:35:22 jerusalem kernel: [drm] Loading RS780 Microcode Jan 24 17:35:23 jerusalem kernel: drmn0: fail (0) to get firmware image with name: radeon/RS780_pfp.bin Jan 24 17:35:23 jerusalem kernel: drmn0: successfully loaded firmware image with mapped name: radeon_RS780_pfp_bin Jan 24 17:35:23 jerusalem kernel: drmn0: fail (0) to get firmware image with name: radeon/RS780_me.bin Jan 24 17:35:23 jerusalem kernel: drmn0: successfully loaded firmware image with mapped name: radeon_RS780_me_bin Jan 24 17:35:24 jerusalem kernel: drmn0: fail (0) to get firmware image with name: radeon/R600_rlc.bin Jan 24 17:35:24 jerusalem kernel: drmn0: successfully loaded firmware image with mapped name: radeon_R600_rlc_bin Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states] 3 Power State(s) Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states] State 0: Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states] Default[drm:radeon_pm_print_states] 1 Clock Mode(s) Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states] 0 e: 80 Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states] State 1: Performance Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states] 1 Clock Mode(s) Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states] 0 e: 50 Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states] State 2: Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states] 1 Clock Mode(s) Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states] 0 e: 50 Jan 24 17:35:24 jerusalem kernel: [drm] radeon: power management initialized Jan 24 17:35:24 jerusalem kernel: drmn0: fail (0) to get firmware image with name: radeon/RS780_uvd.bin Jan 24 17:35:24 jerusalem kernel: drmn0: successfully loaded firmware image with mapped name: radeon_RS780_uvd_bin Jan 24 17:35:24 jerusalem kernel: [drm] GART: num cpu pages 131072, num gpu pages 131072 Jan 24 17:35:34 jerusalem kernel: [drm] PCIE GART of 512M enabled (table at 0xC0146000). Jan 24 17:35:34 jerusalem kernel: drmn0: WB enabled Jan 24 17:35:34 jerusalem kernel: drmn0: fence driver on ring 0 use gpu addr 0xac00 and cpu addr 0x0xf801cb29cc00 Jan 24 17:35:34 jerusalem kernel: drmn0: fence driver on ring 5 use gpu addr 0xc0056038 and cpu addr 0x0xf800d0056038 Jan 24 17:35:34 jerusalem kernel: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). Jan 24 17:35:34 jerusalem kernel: [drm] Driver supports precise vblank timestamp query. Jan 24 17:35:34 jerusalem kernel: drmn0: radeon: MSI limited to 32-bit Jan 24 17:35:34 jerusalem kernel: [drm:drm_irq_install] irq=18 Jan 24 17:35:34 jerusalem kernel: [drm] radeon: irq initialized. Jan 24 17:35:34 jerusalem kernel: [drm:r600_irq_process] r600_irq_process start: rptr 0, wptr 32 Jan
