Re: amdgpu broken on bookworm?

[rhkramer]

On Wednesday, September 01, 2021 11:48:24 AM Greg Wooledge wrote:
> On Wed, Sep 01, 2021 at 11:30:13AM -0400, rhkra...@gmail.com wrote:
> > On Wednesday, September 01, 2021 10:38:22 AM Andrew M.A. Cater wrote:
> > > The end result was that Debian jumped straight to 1.1 and a new thing -
> > > a codename (Buzz) because the then DPL (Bruce Perens) worked for
> > > Pixar.
> > 
> > Just out of curiosity, I'm missing the significance of the then DPL
> > (Bruce Perens) working for Pixar -- would something different have
> > happened if he worked somewhere else?  Or ?
> > 
> > I tried googling (well DDGing) for a connection between Pixar and
> > Infomagic, but didn't turn up anything that looked relevant / useful.
> 
> Bruce (presumably) chose the Toy Story character code names because
> he worked at Pixar.
> 
> The premature "Debian 1.0" had nothing to do with Pixar.

Ahh, ok, thanks to both you and The Wanderer!

Re: amdgpu broken on bookworm?

[Greg Wooledge]

On Wed, Sep 01, 2021 at 11:30:13AM -0400, rhkra...@gmail.com wrote:
> On Wednesday, September 01, 2021 10:38:22 AM Andrew M.A. Cater wrote:
> > The end result was that Debian jumped straight to 1.1 and a new thing - a
> > codename (Buzz) because the then DPL (Bruce Perens) worked for Pixar.
> 
> Just out of curiosity, I'm missing the significance of the then DPL (Bruce 
> Perens) working for Pixar -- would something different have happened if he 
> worked somewhere else?  Or ?
> 
> I tried googling (well DDGing) for a connection between Pixar and Infomagic, 
> but didn't turn up anything that looked relevant / useful.

Bruce (presumably) chose the Toy Story character code names because
he worked at Pixar.

The premature "Debian 1.0" had nothing to do with Pixar.

Re: amdgpu broken on bookworm?

[The Wanderer]

On 2021-09-01 at 11:30, rhkra...@gmail.com wrote:

> On Wednesday, September 01, 2021 10:38:22 AM Andrew M.A. Cater
> wrote:
> 
>> The end result was that Debian jumped straight to 1.1 and a new
>> thing - a codename (Buzz) because the then DPL (Bruce Perens)
>> worked for Pixar.
> 
> Just out of curiosity, I'm missing the significance of the then DPL
> (Bruce Perens) working for Pixar -- would something different have
> happened if he worked somewhere else?  Or ?

Unless I'm greatly mistaken, the significance is that the Pixar
connection is why "buzz" was the codename that was chosen - and why
every single Debian release codename since then has also been the name
of a character from the Toy Story series.


I think this might have been slightly clearer if the grouping etc.
punctuation had been different. The best I've come up with on short
notice is something more like:

>>> The end result was that Debian jumped straight to 1.1 and a new
>>> thing: a codename (Buzz, because the then DPL - Bruce Perens -
>>> worked for Pixar).

That's probably not enough of an improvement in clarity etc. to justify
the energy and attention *I*'ve spent on it, however, never mind the
same from Andrew.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: amdgpu broken on bookworm?

[rhkramer]

On Wednesday, September 01, 2021 10:38:22 AM Andrew M.A. Cater wrote:
> The end result was that Debian jumped straight to 1.1 and a new thing - a
> codename (Buzz) because the then DPL (Bruce Perens) worked for Pixar.

Just out of curiosity, I'm missing the significance of the then DPL (Bruce 
Perens) working for Pixar -- would something different have happened if he 
worked somewhere else?  Or ?

I tried googling (well DDGing) for a connection between Pixar and Infomagic, 
but didn't turn up anything that looked relevant / useful.

Re: amdgpu broken on bookworm?

[Andrew M.A. Cater]

On Wed, Sep 01, 2021 at 09:06:47AM -0500, David Wright wrote:
> On Sat 28 Aug 2021 at 22:19:05 (-0400), songbird wrote:
> > David Wright wrote:
> > > On Sat 28 Aug 2021 at 08:36:32 (-0400), songbird wrote:
> > ...
> > >>   just to note that using "bookworm" in your subject line can
> > >> give the implication that "bookworm" is actually released which
> > >> it hasn't.  it is much better to use the keyword "testing" in
> > >> the subject line instead.
> > >
> > > I don't know where you got that from.
> > 
> >   because testing has always been just testing to me, when
> > the images are made and sent out as official releases with
> > their signed packages and keys and all the rest that is when
> > i consider them by their code names.  that is when the 
> > release team actually releases it.  just because i am following
> > along while they are putting it together in testing or sid
> > doesn't mean it is done.
> 
> That seems a reasonable viewpoint if you're a perpetual testing user,
> living entirely in the present.
> 
> > > A Release gets a *number*.
> > > (The number that might be given to trixie will depend on how
> > > superstitious the Debian release team is.) It's legitimate to talk
> > > about, say, features that might be retained in bookworm, but dropped
> > > by trixie. That's what the codenames are for.
> > 
> >   sure, but those are all conversations about possibilities
> > they're not done until they're released.
> 
> They have to be planned for in the years before release. It's
> difficult to discuss future distributions without giving them
> static codenames that don't shift under your feet. That's
> standard practice in almost any project management.
> 
> > of course this is 
> > my opinion but i think the Release team also feels something
> > about the meaning of the word "Official" and the whole process
> > including the key signing and verification steps...
> 
> I'm not sure what you're saying here; that bookworm and trixie
> aren't "official" names?
> 

It's also worth reviewing ancient history which is what made Debian
switch to codenames at all (and a bunch of projects then followed our
example eg Ubuntu and Red Hat (though Red Hat's names are barely visible).

Someone at Infomagic wanted to steal a march on everyone else and publish
Debian 1.0 on their quarterly release. I can't remember quite what they
did package - but it wasn't release quality yet and didn't actually boot.
The end result was that Debian jumped straight to 1.1 and a new thing - a
codename (Buzz) because the then DPL (Bruce Perens) worked for Pixar.

bookworm is less than a month old but will follow the release until it's 
oldoldstable - "testing" is a movable feast.

All the very best, as ever,

Andy Cater


> Cheers,
> David.
> 

Re: amdgpu broken on bookworm?

[David Wright]

On Sat 28 Aug 2021 at 22:19:05 (-0400), songbird wrote:
> David Wright wrote:
> > On Sat 28 Aug 2021 at 08:36:32 (-0400), songbird wrote:
> ...
> >>   just to note that using "bookworm" in your subject line can
> >> give the implication that "bookworm" is actually released which
> >> it hasn't.  it is much better to use the keyword "testing" in
> >> the subject line instead.
> >
> > I don't know where you got that from.
> 
>   because testing has always been just testing to me, when
> the images are made and sent out as official releases with
> their signed packages and keys and all the rest that is when
> i consider them by their code names.  that is when the 
> release team actually releases it.  just because i am following
> along while they are putting it together in testing or sid
> doesn't mean it is done.

That seems a reasonable viewpoint if you're a perpetual testing user,
living entirely in the present.

> > A Release gets a *number*.
> > (The number that might be given to trixie will depend on how
> > superstitious the Debian release team is.) It's legitimate to talk
> > about, say, features that might be retained in bookworm, but dropped
> > by trixie. That's what the codenames are for.
> 
>   sure, but those are all conversations about possibilities
> they're not done until they're released.

They have to be planned for in the years before release. It's
difficult to discuss future distributions without giving them
static codenames that don't shift under your feet. That's
standard practice in almost any project management.

> of course this is 
> my opinion but i think the Release team also feels something
> about the meaning of the word "Official" and the whole process
> including the key signing and verification steps...

I'm not sure what you're saying here; that bookworm and trixie
aren't "official" names?

Cheers,
David.

Re: amdgpu broken on bookworm?

[songbird]

David Wright wrote:
> On Sat 28 Aug 2021 at 08:36:32 (-0400), songbird wrote:
...
>>   just to note that using "bookworm" in your subject line can
>> give the implication that "bookworm" is actually released which
>> it hasn't.  it is much better to use the keyword "testing" in
>> the subject line instead.
>
> I don't know where you got that from.

  because testing has always been just testing to me, when
the images are made and sent out as official releases with
their signed packages and keys and all the rest that is when
i consider them by their code names.  that is when the 
release team actually releases it.  just because i am following
along while they are putting it together in testing or sid
doesn't mean it is done.


> A Release gets a *number*.
> (The number that might be given to trixie will depend on how
> superstitious the Debian release team is.) It's legitimate to talk
> about, say, features that might be retained in bookworm, but dropped
> by trixie. That's what the codenames are for.

  sure, but those are all conversations about possibilities
they're not done until they're released.  of course this is 
my opinion but i think the Release team also feels something
about the meaning of the word "Official" and the whole process
including the key signing and verification steps...


  songbird

Re: amdgpu broken on bookworm?

[piorunz]

On 28/08/2021 17:33, Jeffrey Chimene wrote:



Thanks! That was it. I don't know why it never loaded amdgpu; which 
forced me to add nomodeset.


Glad I could help! :) So everything is working now, removing this 
nomodeset option solved it?


--

With kindest regards, piorunz.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: amdgpu broken on bookworm?

[David Wright]

On Sat 28 Aug 2021 at 08:36:32 (-0400), songbird wrote:
> Jeffrey Chimene wrote:
> 
>   just to note that using "bookworm" in your subject line can
> give the implication that "bookworm" is actually released which
> it hasn't.  it is much better to use the keyword "testing" in
> the subject line instead.

I don't know where you got that from. A Release gets a *number*.
(The number that might be given to trixie will depend on how
superstitious the Debian release team is.) It's legitimate to talk
about, say, features that might be retained in bookworm, but dropped
by trixie. That's what the codenames are for.

> > Any debugging tips?
> 
>   it does not take that much space to set up a separate 
> partition for stable on a system to keep a working version
> available and for comparison.  this is what i do.

Ditto, except that typically mine are stable and oldstable.
Since a fortnight ago, they've become oldstable and oldoldstable.
See? Rather ambiguous. (They're buster and stretch.)

To interpret "testing" in an arbitrary post, I have to consult
my file listing the release dates of Debian suites.

0.01 1993-08
0.90 1993-12
0.91 1994-01
0.93R5   1995-03
0.93R6   1995-10-26
1.0  unreleased
buzz 1.1 1996-06-17
rex 1.2  1996-12-12
bo 1.3   1997-07-02/-06-05
hamm 2.0 1998-07-24
slink 2.11999-03-09
potato 2.2   2000-08-15
woody 3.02002-07-19
sarge 3.12005-06-06
etch 4.0 2007-04-08
lenny 5.02009-02-14
squeeze 6.0  2011-02-06
wheezy 7 2013-05-04
jessie 8 2015-04-25
stretch 92017-06-17
buster 102019-07-06
bullseye 11  2021-08-14
bookworm
trixie
sid (when woody started)

Cheers,
David.

Re: amdgpu broken on bookworm?

[Jeffrey Chimene]

On 8/28/21 08:56, piorunz wrote:

picasso*.bin files are part of firmware-amd-graphics package.

$ apt-file search picasso_asd.bin
firmware-amd-graphics: /lib/firmware/amdgpu/picasso_asd.bin

These files are present in your system when you package installed.
Their presence doesn't mean that they will get loaded.

I can see in your inxi:

$ inxi -G
Graphics:  Device-1: Advanced Micro Devices [AMD/ATI] Picasso driver: N/A
   Display: server: X.Org 1.20.11 driver: loaded: ati,vesa
unloaded: fbdev,modesetting,radeon resolution: 1440x876~1Hz
   OpenGL: renderer: N/A v: N/A

You have no driver loaded, because you added nomodeset to boot
parameters. nomodeset instructs Linux kernel to not load video drivers.
You have installed non-free drivers (firmware-amd-graphics) and told
kernel not to load them.

Try without nomodeset and report back.
I may have missed your reply if you already did, please try to reply
with one post, not several consecutive posts, to keep discussion more
organized.

Thanks! That was it. I don't know why it never loaded amdgpu; which 
forced me to add nomodeset.

Re: amdgpu broken on bookworm?

[piorunz]

picasso*.bin files are part of firmware-amd-graphics package.

$ apt-file search picasso_asd.bin
firmware-amd-graphics: /lib/firmware/amdgpu/picasso_asd.bin

These files are present in your system when you package installed.
Their presence doesn't mean that they will get loaded.

I can see in your inxi:

$ inxi -G
Graphics:  Device-1: Advanced Micro Devices [AMD/ATI] Picasso driver: N/A
   Display: server: X.Org 1.20.11 driver: loaded: ati,vesa
unloaded: fbdev,modesetting,radeon resolution: 1440x876~1Hz
   OpenGL: renderer: N/A v: N/A

You have no driver loaded, because you added nomodeset to boot
parameters. nomodeset instructs Linux kernel to not load video drivers.
You have installed non-free drivers (firmware-amd-graphics) and told
kernel not to load them.

Try without nomodeset and report back.
I may have missed your reply if you already did, please try to reply
with one post, not several consecutive posts, to keep discussion more
organized.

I can see that you said "It enables display twitching during boot. When
XDM gains control, it will try to set the display mode."
You have to continue tests without nomodeset option, otherwise you have
no driver and that's it.

Re: amdgpu broken on bookworm?

[Jeffrey Chimene]

On 8/28/21 07:07, Jeffrey Chimene wrote:

On 8/28/21 07:04, Jeffrey Chimene wrote:
No complaints about missing picasso firmware. I'll try removing the 
/lib/firmware to see what happens.


So this doesn't do what I thought it would. It's probably not even 
looking for the picasso firmware. 



It's finding the firmware

$# after removing /usr/lib/firmware
$ lsinitramfs /boot/initrd.img-5.10.0-8-amd64 > /tmp/before
$ grep -i pica /tmp/before
$ # revert /usr/lib/firmware
$ sudo update-initramfs -u
$ lsinitramfs /boot/initrd.img-5.10.0-8-amd64 > /tmp/after
$ grep -i pica /tmp/after
usr/lib/firmware/amdgpu/picasso_asd.bin
usr/lib/firmware/amdgpu/picasso_ce.bin
usr/lib/firmware/amdgpu/picasso_gpu_info.bin
usr/lib/firmware/amdgpu/picasso_me.bin
usr/lib/firmware/amdgpu/picasso_mec.bin
usr/lib/firmware/amdgpu/picasso_mec2.bin
usr/lib/firmware/amdgpu/picasso_pfp.bin
usr/lib/firmware/amdgpu/picasso_rlc.bin
usr/lib/firmware/amdgpu/picasso_rlc_am4.bin
usr/lib/firmware/amdgpu/picasso_sdma.bin
usr/lib/firmware/amdgpu/picasso_ta.bin
usr/lib/firmware/amdgpu/picasso_vcn.bin

Re: amdgpu broken on bookworm?

[Jeffrey Chimene]

On 8/28/21 07:04, Jeffrey Chimene wrote:
No complaints about missing picasso firmware. I'll try removing the 
/lib/firmware to see what happens.


So this doesn't do what I thought it would. It's probably not even 
looking for the picasso firmware.


$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-5.10.0-8-amd64
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125b-2.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8107e-2.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8107e-1.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168fp-3.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168h-2.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168h-1.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168g-3.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168g-2.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8106e-2.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8106e-1.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8411-2.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8411-1.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8402-1.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168f-2.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168f-1.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8105e-1.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-3.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-2.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-1.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-2.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-1.fw for 
module r8169

I: The initramfs will attempt to resume from /dev/dm-1
I: (/dev/mapper/epiktistes--vg-swap_1)
I: Set the RESUME variable to override this.

$ ll /lib/firmware
ls: cannot access '/lib/firmware': No such file or directory

Re: amdgpu broken on bookworm?

[Jeffrey Chimene]

No complaints about missing picasso firmware. I'll try removing the 
/lib/firmware to see what happens.


$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-5.10.0-8-amd64

W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125b-2.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8107e-2.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8107e-1.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168fp-3.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168h-2.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168h-1.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168g-3.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168g-2.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8106e-2.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8106e-1.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8411-2.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8411-1.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8402-1.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168f-2.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168f-1.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8105e-1.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-3.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-2.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-1.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-2.fw for 
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-1.fw for 
module r8169

I: The initramfs will attempt to resume from /dev/dm-1
I: (/dev/mapper/epiktistes--vg-swap_1)
I: Set the RESUME variable to override this.

Re: amdgpu broken on bookworm?

[Jeffrey Chimene]

On 8/28/21 06:04, piorunz wrote:

On 28/08/2021 13:54, Jeffrey Chimene wrote:

Let me ask more questions, so we all can learn more about your situation
and start suggesting remedies.


Hi,

Thanks for the advice. The problem I'm trying to solve is why the AMD
firmware isn't getting incorporated in the kernel.


How you assumed that firmware isn't getting to kernel? Do you have any
errors in the log stating that?


I have to boot with
NOMODESET.


What happens if you don't? Please show error logs when you don't have
nomodeset.


The bookworm updates, while coincidental, are probably not
the cause. "Something else" happened, and I need help debugging. I can't
see amdgpu in lsmod. I can see the firmware in /var/lib/firmware.


Try this:

inxi -G
Graphics:  Device-1: Advanced Micro Devices [AMD/ATI] Navi 21 [Radeon RX
6800/6800 XT / 6900 XT] driver: amdgpu v: kernel
   Display: x11 server: X.Org 1.20.11 driver: loaded:
amdgpu,ati unloaded: fbdev,modesetting,radeon,vesa resolution:
   1: 1920x1200~60Hz 2: 3840x2160
   OpenGL: renderer: AMD SIENNA_CICHLID (DRM 3.40.0
5.10.0-8-amd64 LLVM 12.0.1) v: 4.6 Mesa 21.1.4


$ inxi -G
Graphics:  Device-1: Advanced Micro Devices [AMD/ATI] Picasso driver: N/A
   Display: server: X.Org 1.20.11 driver: loaded: ati,vesa 
unloaded: fbdev,modesetting,radeon resolution: 1440x876~1Hz

   OpenGL: renderer: N/A v: N/A

$ aptitude search "~i firmware"
i firmware-amd-graphics - Binary firmware for AMD/ATI graphics chips
i firmware-iwlwifi - Binary firmware for Intel Wireless cards
i firmware-linux - Binary firmware for various drivers in the Linux 
kernel (metapackage)
i A firmware-linux-free - Binary firmware for various drivers in the 
Linux kernel
i firmware-linux-nonfree - Binary firmware for various drivers in the 
Linux kernel (metapackage)
i A firmware-misc-nonfree - Binary firmware for various drivers in the 
Linux kernel


$ ll /lib/firmware
total 40K
drwxr-xr-x 2 root root  20K Aug 27 05:50 amdgpu
drwxr-xr-x 2 root root 4.0K Aug 27 05:50 r128
drwxr-xr-x 2 root root  16K Aug 27 05:50 radeon

$ find /lib/firmware/ -iname \*pic\*

/lib/firmware/amdgpu/picasso_rlc_am4.bin
/lib/firmware/amdgpu/picasso_gpu_info.bin
/lib/firmware/amdgpu/picasso_ce.bin
/lib/firmware/amdgpu/picasso_ta.bin
/lib/firmware/amdgpu/picasso_me.bin
/lib/firmware/amdgpu/picasso_mec.bin
/lib/firmware/amdgpu/picasso_asd.bin
/lib/firmware/amdgpu/picasso_mec2.bin
/lib/firmware/amdgpu/picasso_sdma.bin
/lib/firmware/amdgpu/picasso_pfp.bin
/lib/firmware/amdgpu/picasso_vcn.bin
/lib/firmware/amdgpu/picasso_rlc.bin

Re: amdgpu broken on bookworm?

[Jeffrey Chimene]

Hi piorunz,

Thanks for your interest! I really appreciate your time. Background: 
I've been using Debian since Potato. This distro Just Works.


On 8/28/21 06:04, piorunz wrote:

On 28/08/2021 13:54, Jeffrey Chimene wrote:

Let me ask more questions, so we all can learn more about your situation
and start suggesting remedies.


Hi,

Thanks for the advice. The problem I'm trying to solve is why the AMD
firmware isn't getting incorporated in the kernel.


How you assumed that firmware isn't getting to kernel? Do you have any
errors in the log stating that?


There are no errors. Only warnings about an unsupported Wifi chip (r8169 
missing RTL8125b-2).


As an aside: I have not mentioned this before, and I think it is a red 
herring: The problems started when I connected the wifi antenna to the 
board. The firmware for this chip isn't supported in this kernel, yet. I 
think I can download the drivers from Intel. I'm not really interested 
in wifi for this machine, as a wired connection works for now. This is 
too coincidental and unrealistic, but I want to get past it so we can 
move to other things. As soon as the antenna connections (dual coax) to 
the board were made, the screen went black. I know. Bullshit. The board 
doesn't really need an external antenna to detect wifi, so the antenna 
connection only boosted the signal. If the OS wanted to load a 
non-existent driver (which it's already trying to do as that failing 
attempt appears in boot.log), it would've tried before then, external 
antenna or no. Then somehow botch already loaded amdgpu firmeare? I 
don't think so. It's as coincidental as the bookworm updates earlier 
that day. When I rebooted to clear the issue (Linux isn't windows! One 
doesn't reboot to fix issues), no display...


Anyway, on to your other questions...




I have to boot with
NOMODESET.


What happens if you don't? Please show error logs when you don't have
nomodeset.


There are no logs. nomodeset doesn't log anything. It enables display 
twitching during boot. When XDM gains control, it will try to set the 
display mode.






The bookworm updates, while coincidental, are probably not
the cause. "Something else" happened, and I need help debugging. I can't
see amdgpu in lsmod. I can see the firmware in /var/lib/firmware.


Try this:

inxi -G
Graphics:  Device-1: Advanced Micro Devices [AMD/ATI] Navi 21 [Radeon RX
6800/6800 XT / 6900 XT] driver: amdgpu v: kernel
   Display: x11 server: X.Org 1.20.11 driver: loaded:
amdgpu,ati unloaded: fbdev,modesetting,radeon,vesa resolution:
   1: 1920x1200~60Hz 2: 3840x2160
   OpenGL: renderer: AMD SIENNA_CICHLID (DRM 3.40.0
5.10.0-8-amd64 LLVM 12.0.1) v: 4.6 Mesa 21.1.4


I don't have inxi installed. I will install it and post the results.






I've run update-initramfs -c after replacing /var/lib/firmware. Still
not getting positive results from lsmod | grep -i amdgpu


$ lsmod | grep -i amdgpu
amdgpu   6606848  90
gpu_sched  40960  1 amdgpu
i2c_algo_bit   16384  1 amdgpu
ttm   114688  1 amdgpu
drm_kms_helper    274432  1 amdgpu
drm   618496  39 gpu_sched,drm_kms_helper,amdgpu,ttm

For me it works.


For me, nada. One of my earliest tests. I swear, I did see positive 
results earlier!







Booting with

ro loglevel=7 nomodeset

isn't giving any useable clues in boot.log


What is your GPU (integrated or not) model? Please say exact model from
inxi for example.
I'm sure it's integrated. It's a Asus board model B550M-A By now, it has 
"reasonable" kernel support. About 18 months ago, it did not have such 
support. As I said earlier, I think wifi isn't well supported, but I 
don't care right now.




It feels like it's a kernel setting that got written and isn't reset
after down/up grades. This is testing. It's supposed to be "broken".


I don't know what you are trying to say here. What supposed to be broken
and why you think so?


It's based on intuition. If I had the resources to follow up that hunch, 
I would. I don't know where to start with such suppositions; which are 
based on instructions like "cat BLAH > /FOO/BLECH" to change OS behavior.


Cheers,
jec

Re: amdgpu broken on bookworm?

[Jeffrey Chimene]

On 8/28/21 05:36, songbird wrote:

Jeffrey Chimene wrote:


   just to note that using "bookworm" in your subject line can
give the implication that "bookworm" is actually released which
it hasn't.  it is much better to use the keyword "testing" in
the subject line instead.


Agreed. However, a net search on testing would yield results that are 
too old to be useful. My goal is to watch for bookworm topics via search 
engine's "news alert" features.







Something happened to my amd firmware for a ryzen3 3200g. A few weeks
ago, this machine made an uneventful transition to bookworm. I'd
originally installed bullseye and the non-free firmware package to get
the firmware for this setup. Everything was fine until yesterday, after
some bookworm updates and a reboot. No more video driver for X.

I've tried downgrading to stable from testing. No joy.

I've wiped /lib/firmware and reinstalled firmware-amd-graphics. No joy.
I've checked

I just booted ubuntu live and graphics are high resolution.

It feels like there's some setting in /proc or /sys that got changed
accidentally.

Any debugging tips?


   it does not take that much space to set up a separate
partition for stable on a system to keep a working version
available and for comparison.  this is what i do.


Damn, that is such a good idea! I will add that to future 
re-partitioning. Right now, to get this box on the air, I did the two 
partition (/ and swap) setup and added lvm2 for backups and such. I 
think the resolution to this issue is to reinstall. I'll wait a few 
weeks for testing to ripen to 12, move /home to its own partition (and 
probably /var), create a /stable partition and reinstall.


As I understand it, this /stable is not bootable?

Re: amdgpu broken on bookworm?

[piorunz]

On 28/08/2021 13:54, Jeffrey Chimene wrote:

Let me ask more questions, so we all can learn more about your situation
and start suggesting remedies.


Hi,

Thanks for the advice. The problem I'm trying to solve is why the AMD
firmware isn't getting incorporated in the kernel.


How you assumed that firmware isn't getting to kernel? Do you have any
errors in the log stating that?


I have to boot with
NOMODESET.


What happens if you don't? Please show error logs when you don't have
nomodeset.


The bookworm updates, while coincidental, are probably not
the cause. "Something else" happened, and I need help debugging. I can't
see amdgpu in lsmod. I can see the firmware in /var/lib/firmware.


Try this:

inxi -G
Graphics:  Device-1: Advanced Micro Devices [AMD/ATI] Navi 21 [Radeon RX
6800/6800 XT / 6900 XT] driver: amdgpu v: kernel
   Display: x11 server: X.Org 1.20.11 driver: loaded:
amdgpu,ati unloaded: fbdev,modesetting,radeon,vesa resolution:
   1: 1920x1200~60Hz 2: 3840x2160
   OpenGL: renderer: AMD SIENNA_CICHLID (DRM 3.40.0
5.10.0-8-amd64 LLVM 12.0.1) v: 4.6 Mesa 21.1.4



I've run update-initramfs -c after replacing /var/lib/firmware. Still
not getting positive results from lsmod | grep -i amdgpu


$ lsmod | grep -i amdgpu
amdgpu   6606848  90
gpu_sched  40960  1 amdgpu
i2c_algo_bit   16384  1 amdgpu
ttm   114688  1 amdgpu
drm_kms_helper274432  1 amdgpu
drm   618496  39 gpu_sched,drm_kms_helper,amdgpu,ttm

For me it works.



Booting with

ro loglevel=7 nomodeset

isn't giving any useable clues in boot.log


What is your GPU (integrated or not) model? Please say exact model from
inxi for example.



It feels like it's a kernel setting that got written and isn't reset
after down/up grades. This is testing. It's supposed to be "broken".


I don't know what you are trying to say here. What supposed to be broken
and why you think so?

--

With kindest regards, piorunz.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: amdgpu broken on bookworm?

[Jeffrey Chimene]

On 8/28/21 05:36, songbird wrote:

Jeffrey Chimene wrote:


   just to note that using "bookworm" in your subject line can
give the implication that "bookworm" is actually released which
it hasn't.  it is much better to use the keyword "testing" in
the subject line instead.


Agreed. However, a net search on testing would yield results that are 
too old to be useful. My goal is to watch for bookworm topics via search 
engine's "news alert" features.







Something happened to my amd firmware for a ryzen3 3200g. A few weeks
ago, this machine made an uneventful transition to bookworm. I'd
originally installed bullseye and the non-free firmware package to get
the firmware for this setup. Everything was fine until yesterday, after
some bookworm updates and a reboot. No more video driver for X.

I've tried downgrading to stable from testing. No joy.

I've wiped /lib/firmware and reinstalled firmware-amd-graphics. No joy.
I've checked

I just booted ubuntu live and graphics are high resolution.

It feels like there's some setting in /proc or /sys that got changed
accidentally.

Any debugging tips?


   it does not take that much space to set up a separate
partition for stable on a system to keep a working version
available and for comparison.  this is what i do.


Damn, that is such a good idea! I will add that to future 
re-partitioning. Right now, to get this box on the air, I did the two 
partition (/ and swap) setup and added lvm2 for backups and such. I 
think the resolution to this issue is to reinstall. I'll wait a few 
weeks for testing to ripen to 12, move /home to its own partition (and 
probably /var), create a /stable partition and reinstall.


As I understand it, this /stable is not bootable?

Re: amdgpu broken on bookworm?

[Jeffrey Chimene]

On 8/28/21 04:28, piorunz wrote:

On 27/08/2021 19:20, Jeffrey Chimene wrote:

Something happened to my amd firmware for a ryzen3 3200g. A few weeks
ago, this machine made an uneventful transition to bookworm.


Great.


I'd
originally installed bullseye and the non-free firmware package to get
the firmware for this setup. Everything was fine until yesterday


Not bookworm upgrade fault then. You had upgraded the system and it was
working fine.


Everything was fine until yesterday, after
some bookworm updates and a reboot. No more video driver for X.


SOME bookworm updates? Please be more specific. That's the cause of your
problem. Please attach relevant logs from this "bookworm updates" event
so we can see what happened.



Hi,

Thanks for the advice. The problem I'm trying to solve is why the AMD 
firmware isn't getting incorporated in the kernel. I have to boot with 
NOMODESET. The bookworm updates, while coincidental, are probably not 
the cause. "Something else" happened, and I need help debugging. I can't 
see amdgpu in lsmod. I can see the firmware in /var/lib/firmware.


I've run update-initramfs -c after replacing /var/lib/firmware. Still 
not getting positive results from lsmod | grep -i amdgpu


Booting with

ro loglevel=7 nomodeset

isn't giving any useable clues in boot.log

It feels like it's a kernel setting that got written and isn't reset 
after down/up grades. This is testing. It's supposed to be "broken". 
When bullseye was broken after the downgrade, I knew something broke in 
my local configuration. I'm trying to fix it. I'd like help debugging. 
It's probably only reproducible if one follows a set of steps that 
aren't easily retraced.


It's been too many years since I used Debian from the console. I do not 
remember enough X to debug building the init image towards that goal.


I'm also chuffed that Ubuntu manages to pull off video in the live CD.

At this point, I think I'll reinstall from bookworm netinst in a few 
weeks or after the transition to 12 finishes. Running the box headless 
will be good enough for now.




--

With kindest regards, piorunz.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: amdgpu broken on bookworm?

[songbird]

Jeffrey Chimene wrote:


  just to note that using "bookworm" in your subject line can
give the implication that "bookworm" is actually released which
it hasn't.  it is much better to use the keyword "testing" in
the subject line instead.


> Something happened to my amd firmware for a ryzen3 3200g. A few weeks 
> ago, this machine made an uneventful transition to bookworm. I'd 
> originally installed bullseye and the non-free firmware package to get 
> the firmware for this setup. Everything was fine until yesterday, after 
> some bookworm updates and a reboot. No more video driver for X.
>
> I've tried downgrading to stable from testing. No joy.
>
> I've wiped /lib/firmware and reinstalled firmware-amd-graphics. No joy. 
> I've checked
>
> I just booted ubuntu live and graphics are high resolution.
>
> It feels like there's some setting in /proc or /sys that got changed 
> accidentally.
>
> Any debugging tips?


  it does not take that much space to set up a separate 
partition for stable on a system to keep a working version
available and for comparison.  this is what i do.


  songbird

Re: amdgpu broken on bookworm?

[piorunz]

On 27/08/2021 19:20, Jeffrey Chimene wrote:

Something happened to my amd firmware for a ryzen3 3200g. A few weeks
ago, this machine made an uneventful transition to bookworm.


Great.


I'd
originally installed bullseye and the non-free firmware package to get
the firmware for this setup. Everything was fine until yesterday


Not bookworm upgrade fault then. You had upgraded the system and it was
working fine.


Everything was fine until yesterday, after
some bookworm updates and a reboot. No more video driver for X.


SOME bookworm updates? Please be more specific. That's the cause of your
problem. Please attach relevant logs from this "bookworm updates" event
so we can see what happened.

--

With kindest regards, piorunz.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄