04:57 illwieckz: is it a driver bug or the card is faulty? https://gitlab.freedesktop.org/drm/amd/-/issues/2972
05:28 airlied: illwieckz: possibly a driver bug, but no idea how you'd find someone to work it out
06:01 illwieckz: airlied, thanks for the answer, is there something I can do to check if it's a driver bug?
07:07 babyfaceold: Western people are very abusive , it's not a joke, i was at a cyber war with them and nearly lost everything including my life, so i have to work on securing the interconnect, in those terms Putin is not even crazy, western people just abused 14thousound people to death in crimea before the war launched. I know those problematic result fixing people are not russians nor chinese, it's possible to make agreements with them, so you come out
07:07 babyfaceold: of doctors session not as disabled handycap. ipv4 and ipv6 header attacks are by western people done predominantly, that is clear to me.
07:17 babyfaceold: the agenda there got totally misguided, the stronger personality you are or possible talent you get screwed entirely, which is different policy entirely for eastern side, they like to produce more stronger people in comparison with western powers. It's not like i blacklisted western abusers before i really got abused that large, that it is not possible to deal with them anymore.
07:21 airlied: illwieckz: not really unless you can find the same gpu or test it with Wnidows
07:22 babyfaceold: so my case is definitely such, that i either do not go to internet at all anymore, and avoid dealing with western people, or i try to secure the interconnect that is vulnerable, then i could work with computers, i first try to elect or choose the last.
07:26 illwieckz: I may have an Ubuntu 14 with fglrx somewhere on an USB key, maybe that counts as something different enough
07:30 babyfaceold: but it seems really that some nxp microcontrollers have that in hardware the nic processors serial mac processing ethernet adapters have hold signals like on isa buses, yes i am investigating such things.
08:03 airlied: illwieckz: not sure fglrx ever tried to handle video processors
08:09 illwieckz: there are logs about UVD but my main problem is that the computer crashes when I plug a screen once booted
08:12 airlied: it might be those were harvested chips we never handled preoperlyu
08:13 airlied: illwieckz: do you have another gpu in it?
08:15 illwieckz: yes
08:15 illwieckz: there is a vega in the cpu
08:15 illwieckz: that's why I can boot the OS
08:16 illwieckz: I also tried with another computer having another terascale (but not barts), I can boot on the first GPU
08:17 illwieckz: once booted with the first GPU I can list the second
08:17 illwieckz: but once booted when I plug a screen on that HD 6870 the PC instantanely crashes
08:35 illwieckz: I haven't found my Ubuntu14+fglrx key, I'm installing windows on an old drive right now
08:56 babyfaceold: yeah well, the ehold and mdio_hold are timing regs, but the problem side is interrupt pin which is disabled by default on ethernet, likely never disabled on wlan but it also is possible to be attacked, collision detection pin is the most relevant its available only in serial mode ethernets, when this goes down it most signal something
09:29 illwieckz: So, on windows with default drivers after update, the screen is not dectected when plugged in, after installing Crimson driver windows doesn't reboot properly and says it faced THREAD_STUCK_IN_DEVICE_DRIVER error, and with older Catalyst drivers Windows just get stuck at startup (like Linux when I plug a screen) but without needing from to to actually plug a screen.
09:29 illwieckz: without needing from me to*
09:30 illwieckz: airlied, ↑
09:31 MrCooper: sounds like it might be a HW issue then
09:31 illwieckz: yes
17:05 babyfaceold: It can not operate without interrupts, but 10base ethernet cards can be secured, serial ones without doing any code. if you know the buses than disabled means sure disabled nooot, it means the default is disabled cause pci uses level triggered interrupts.
17:06 babyfaceold: wlan cards need code i am sure.
19:42 babyfaceold: frustrated anyways somewhere in gitlab was texas university framework of everything related to wireless , opencores of wifi baseband and such, lora , zigbee in vhdl, but the link was one of the rare losses in my old broken computer. It could be all now in members zone, i remember they had gitlab repo not github which infact had everything. I do not remember much of low level details unfortunately. all my hw hasn't got a simplest escape,
19:42 babyfaceold: need to dive into root complex device io_remap code anyways, but i am sure that all wifi phys are vulnerable inherently.