From nobody Tue Sep 3 12:53:45 2024 X-Original-To: bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WyltL5kk9z5PS18 for ; Tue, 03 Sep 2024 12:53:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WyltL3wLbz4XKw for ; Tue, 3 Sep 2024 12:53:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725368026; a=rsa-sha256; cv=none; b=HG3P8PacG7CKNWwLpeMw2tkBu/ON+S/cxSnSp6Ym5Kow/5MCi7scfVqfRfK9QjXluJRbR2 1oYl2Jv/lq+sbIt3ONeydxMv+VJjU/2eSXMORevKkBxvp+H/n6gtY0eP7f1NQZ+2KKnjUp SN5wiA7TgwGVDXqitiERl/xbJVRSCxcT8qli9kaV5kj7fhlLaZb/0aH/LzkwQRy8K0za+u 4lYhS74ambaKtErKywlHkeolguQ5HX98/RL+Ul7KZf8qZTehZ6+SLvmesGGk3a1XYD5MrR CKaX9/+zW7Z8x6KWwF8zp96j5lP8i066vNhIx0Ljzi+IW9vhoGXWjz58/S259A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725368026; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qsi8cef69S4YoLe6xIM961cXebXL81sQR0XwU3kcDx4=; b=Kr85juJR0OF/REA0tQbtVhio3EYhAaJpzgSJn/ELuHpL3EYKNVYlyM+C0p6e4D4YyMooEO 1rkqjjjhZB9KgkGWBnppRu+dZKHf8F2/wn5ThcfLKis4D1MOV5wLP7lhlK3SNoCtR8R5Fp 942iow7kbewWRwv3d1Ty0mXjfsY+Po8Kar+Wl4qHz9u4nuPwzVQpEzkEtEiZLSrO2q3SQr 1aaBQpoTlbrYrtUIddKJ5SkJyBuuOo4cOd32shXK4jpKaSVAMiS6YDRNslR177AgpVOHXy abDpG65YPU09EKKS0wQBoA+FGmcavDHiB4YoE+KaIBydtoc00g70xc1jQFAgXQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4WyltL3X02zhXW for ; Tue, 3 Sep 2024 12:53:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 483CrkS1049189 for ; Tue, 3 Sep 2024 12:53:46 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 483CrkRC049187 for bugs@FreeBSD.org; Tue, 3 Sep 2024 12:53:46 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 276985] crash in LinuxKPI/drm Date: Tue, 03 Sep 2024 12:53:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 14.1-RELEASE X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: olce@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: mfc-stable14? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276985 --- 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 comme= nt #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 p= eople. 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 grap= hics 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 leas= t, 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 pla= ce.=20 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 hap= pens 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 scenar= ios, 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 1= 4 release what is not possible on 13 (some documentation on this would be n= ice). 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-g= eneralizing your own case", etc). "not willing to test" was my feeling, although when I first wrote that I us= ed "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 describin= g 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 DR= M 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, a= nd it is exactly in this direction that I'm trying to steer you. [As a side note, concerning the second part of your sentence, given how long you've been around, I don't think you can possibly believe what you wrote.= =20 There has certainly been a lot of abusive language in the project, especial= ly in the old years. I do not endorse such a language, and perhaps contrary to what you seem to believe, I've not engaged in that here.] > But I get the point. (...) Great. > I am just a bit scared to do this on a production machine you can imagine= that. Surely. But what will you do if your production machine happens to break?= =20 Don't you have another very similar or identical setup more or less ready to replace it, especially if downtime is a concern? Such a setup would additionally be useful to test stuff without disturbing your main machine. > My last question - if you are the drm module maintainer / developer - wou= ld it be possible to mark following ports with incremental numbers like 510= , 515, 610, not 61 for a newest release please (61 < 515)? I'm not (at least for now). I understand that, e.g., a name like 'drm-601-kmod' would have been more satisfying, but does this have any relevance in practice? Are you scripting things to automatically update yo= ur DRM modules depending on the inferred version (in which case, there are probably other means)? And, as said above, I think the plan is that these ports are going to disappear. So I doubt there will be any change in this area. Before trying to setup a new machine, could you please answer my very simple question of comment #29: Where did the packages you used to install DRM mod= ules came from? Did you build them yourself, or were they official packages, or ...? If you didn't build them yourself, the first thing to try would be to= do exactly that and see if problems persist. --=20 You are receiving this mail because: You are the assignee for the bug.=