01:56mindmelon193: I am willing to put details into public, as a human beings you are not functional releases, you can not even decompile a program properly next to total lack of creativity and understanding, who do you fool that i've been causing issues, cause that isn't what scientists know , piles of shit can not be turned into more issues what they allready are! even if we forget that most of the real thinking has been done by me!
02:01mindmelon193: And your violative attitude is something that i have studied, it's a bunch of real world paranoia that does not let me to live my life neither you to perform sanely, you understand that somewhere in the wild there exists a bigger brain and stronger hand, but claim the reverse what has been typical thing that scammers always do!
02:05mindmelon193: it is typical illness without me even interacting with any of this, if there was an instance where i did, only my existence turned people so nuts and off the weeds, that they could not anymore function, the cause is me there but it is based of the delusions of people, i am not guilty by any means that i was born who i was born.
02:06mindmelon193: my way of thinking is i follow the order and rules, i can not count with people who do not.
02:10mindmelon193: if ones are so weak to daily annoy another one, only cause they can not tolerate another ones existance -- where the last one understands about who suffers cause of my go and lives low profile life and don't provocate neither interact with those who suffer under delusions like this
02:12mindmelon193: i can not help to get into conflicts, cause I do not allow to interact with mine in such way to finding consitently how to knock me down cause i am not worth to live according to their twisted views, and even my existance turns most mad.
02:49mindmelon193: and to be honest, therapy might be needed to get you through living your own life without interacting with other ones, it's not because I stuff my nose into others private things, as far as i am concerned the stalkers who framed me with their own initiative are still dickheads i do not want to deal with them any more than theid cure themselves and let also others to live.
02:55mindmelon193: when someone calls you 3years in a row to frame you in anything possible and carry all the negativism with hiw own initiative to your life, it does not require alot of intelligence to understand that there is some issue that my existance causes no matter how big those groups are that have something against me, it still does not require much intelligence that actually i was innocent all the way cause the fight was not
02:55mindmelon193: inited by me and problems were not invented by me with hard work.
02:59mindmelon193: it is because i knew long since this is going to happen, and i knew that as well, that single appearance of mine could screw up someones mindset, it is not what i wanted though, all i could do was minimize my appareances and compromise a little while preserving my owns life for later.
03:00mindmelon193: I can not really compromise anymore than that, because a bunch cockblockers can not live with me breathing in my own apartement being alone.
03:05mindmelon193: And as i am still saying, all the initiations are towards me, a one way traffic to interact with things that do not belong to them, humiliate me frame me interact with me, due to their illness for not standing or tolerating my kind of personality to also breathe oxygen.
03:08mindmelon193: cause the issue was taking place over my private and personal things why they authored the conflict to knock me down illegaly, many persons played their part many many , the shortcut was in fact to charge me, instead of filling the hostpital with severaly mentally ill
03:08mindmelon193: large groups of people.
03:19mindmelon193: and i know your ignorance only lasts until one lady comes to talk with me having interest in me, while all of the sudden all your illness shows up and you are actively trashing me again
03:20mindmelon193: cockblockers and scammers status is given for you for a reason.
03:23mindmelon193: cockblocker/scammer !== science/programming period , i have been trying to help you to open more doors and get more occupied not do that all the time, science would greet you with so many opportunities
03:27mindmelon193: I am not at all picking about where someone made a minor mistake about me, it is just consistent mistakes over my personal internals refer pretty much to conspiration to me.
03:31mindmelon193: enter into real science please!!!!!!!!!!!! and you will see that there are other type of ways than knocking me down illegally.
03:32mindmelon193: this is why i help you, cause you are troublesome fellows who probably can not make it on your own.
03:35mindmelon193: those who are not yet tired and exhausted cause of seing delusions i do not allow to influence them in negative way, possibly juri_ who might be in a route of happiness around science, when you exhausted your chanches then let others to think without terrorising them.
03:45mindmelon193: loosing a vision due to overstressing the eyes is a tragedy perhaps, i know this can be hard, karolherbst have you lost your vision or what is the trouble you have not understood how things work, or the Lyude red hat tranny
03:46mindmelon193: Do you think that every sane company should have a fag or tranny present like red hat? Otherwise it is not a real company right
03:49mindmelon193: no one disallows you to do what is correct, i can not see thick occulars that hamper your vision or block, you have a chanche to show your are more then just tranny
05:06endrift: glad I missed that
06:47juri_: this is getting bad. or mad. maybe sad? [mbs]ad.
07:04Hooloovo0: just a tad
07:59mupuf: I just introduced in Bugzilla a "not set" value for the priority and severity. Would anyone mind if I made it the default for new bugs?
08:01pmoreau: AFAIK no one (besides users) ever uses them
08:05pmoreau: I’m not against changing the default value, but neither am I spending time on Nouveau at the moment. :-/
08:34mupuf: pmoreau: yeah, devs usually ignore them. Intel uses it though, but the default value is the same for all projects so I am asking every project
08:34karolherbst: juri_: all of that
11:40cosurgi: skeggsb, pmoreau, imirkin: I just had this crash: https://paste.ubuntu.com/p/rkY7SHkyjP/
11:40cosurgi: nouveau_exa_upload_to_screen:380 - falling back to memcpy ignores tiling
11:40cosurgi: (EE) Backtrace:
11:40cosurgi: (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x5613cbcb92c9]
11:41cosurgi: Second time withing two days. In both cases it happened when I had `xset dpms force off` running. Screens were off.
11:42cosurgi: any *-dbgsym package which I should install to improve backtrace info?
14:28cosurgi: skeggsb, pmoreau, imirkin: ok, it's not because of `xset dpms force off`. Noveau was running pretty stable last month or two. The crashes suddenly started two days ago, and become rather frequent. Here's another crash log: https://paste.ubuntu.com/p/mp99PqNjNS/
14:30cosurgi: skeggsb, pmoreau, imirkin: the only thing that changed on my PC two days ago is that I started running some serious calculations on all 32 CPU cores. Meaning that nouveau apparently relies somewhere on a realtime response to something. The calculations have lowest nice priority to not disturb me too much. But still they clog a bit the cpu cores. This must be the real reason for these crashes.
14:37gst568923: In the description of nouveau-firmware package "This package is temporary; the nouveau drivers will soon be able togenerate this data on the fly." means that MmioTrace command is optional to extract the firmware?
15:12karolherbst: gst568923: what nouveau-firmware package?
15:13gst568923: karolherbst is a ubuntu package that contains blob firmware for a hardware video decoding
15:26karolherbst: mhh, this might be the video firmware extracted from the binary driver
15:39gst568923: karolherbst what I need is the VP5 engine, but I wanted to know if it will be extracted automatically I think this is the meaning of this phrase "This package is temporary; the nouveau drivers will soon be able togenerate this data on the fly."
15:57karolherbst: this phrase is just wrong
16:22juri_: cosurgi: not to be a devil's advocate, but could it be a weak power supply?
16:45cosurgi: juri_: I don't think so. I had serious PSU problems when running these calculations. The PSU was 800W, and PC turned itself off randomly after two or three days of these calculations. This was over 8 months ago, when I replaced the PSU with a new on 1500W. Not a problem anymore: the PSU is new one, and nearly twice as strong.
16:54juri_: again, allow me to devil's advocate: bigger power supply != better power delivery to the motherboard. I'd check the specs, and make sure the 24 + 4 + 4 or whatever connects to the board actually delivers more.
16:54juri_: but.. i think i'm done devil's advocating. :D
17:03cosurgi: I think that PSU supply results in unstable hardware, not unstable software. The crashes are definitely in nouveau driver ;)
17:03cosurgi: I would see other problems with my PC if motherboard had not enough power. Not just with xserver.
17:04karolherbst: the crash is weird though
17:04karolherbst: especially those -2 lines
17:05karolherbst: cosurgi: do you have your dmesg?
17:05cosurgi: those -2 lines is immirkin's special log message. He told me many times he is going to fix this message, and that it's harmless.
17:05cosurgi: sure, hold on.
17:07cosurgi: The xserver of user porzadek died. This is when I start a new session for him: elogind-daemon: New session 1458 of user porzadek.
17:07karolherbst: your gpu gets quite hot as well
17:07cosurgi: it's barely used.
17:07karolherbst: well, "nouveau 0000:04:00.0: therm: temperature (90 C) hit the 'fanboost' threshold"
17:08cosurgi: that's interesting.
17:08karolherbst: I mean.. could be expected
17:08cosurgi: I think imirkin mentioned some issues with setting the fan speed, could be the reason
17:08karolherbst: depending on the clocks
17:08karolherbst: yeah, might be
17:09karolherbst: I think I've got it
17:09karolherbst: the X stack is super useless though
17:10cosurgi: what you've got?
17:11karolherbst: cosurgi: mind building the xf86-video-nouveau yourself and debug it a little?
17:11karolherbst: I think it crashes somewhere there
17:11karolherbst: maybe you can even run Xorg through gdb..
17:11karolherbst: no idea how easy it would be to reproduce it
17:11karolherbst: might be better to use 2 machines even
17:12karolherbst: one to ssh in, and starting gdb Xorg with screen
17:12karolherbst: if we know which line the actual crash is, that would help a lot
17:12cosurgi: uh-huh. Considering I have 6480x3840 resolution no wonder memcpy has problems.
17:12karolherbst: yeah.. could be something stupid
17:12karolherbst: but if you are able to pinpoint the line inside the ddx, that would be of great help
17:13cosurgi: actually I think that xf86-video-nouveau which I run right now I have custom built two months ago
17:13karolherbst: well, you can also throw in printks or something
17:13karolherbst: but gdb would probably be easier
17:14karolherbst: if it's plain X, you can get an xterm window, su into your user
17:14karolherbst: and start your session
17:14karolherbst: like plasmashell for plasma
17:14karolherbst: no idea how the session managers are called for other desktops
17:15cosurgi: no worries about starting X. I always do `startx -- -nolisten tcp -dpi 100` from text terminal to start my session. Then I use custom built sawfish+rox desktop
17:15cosurgi: didn't use KDE, gnome or whatever since 1998
17:15karolherbst: ahh, okay
17:15karolherbst: then it should be easy :
17:16karolherbst: but I think you still need a second machine
17:16karolherbst: you can't switch to a tty if you use gdb with X
17:16cosurgi: sure, I can ssh in.
17:16cosurgi: however - this bug triggers only when I am running calculations.
17:16cosurgi: That will be very hard to trigger: slow gdb + calculations at the same time?
17:17cosurgi: And it triggers once every two days
17:18cosurgi: maybe printk is the better (and slower) route?
17:18karolherbst: gdb won't slow your X down
17:19cosurgi: ah. I didn't expect that
17:19karolherbst: cosurgi: the problem with printk is, that because it's taking 2 days, it would take painfully long to pin down the actual reason for the crash
17:19karolherbst: it could be somewhere else as well
17:20cosurgi: so the only restriction imposed by gdb will be that I cannot switch VTs while it is running?
17:20cosurgi:ponders if he can survive with single X session for two days....
17:21cosurgi: the thing is that I have 5 xsessions running in parallel. One for different type of job.
17:21cosurgi: research,work,games, etc...
17:22cosurgi: fast VT switching is one of the best things nouveau has when compared to nvidia :)
17:22cosurgi: but ok. We can try that.
17:22cosurgi: So first thing is to build xf86-video-nouveau with full debug info
18:44karolherbst: cosurgi: well, you can't switch VTs when it hit a breakpoint or stopped
18:45karolherbst: because X hast to do stuff in order to switch to the tty
18:45karolherbst: which it can't do if you debug it :p
18:48cosurgi: ah, so I only can't switch tty when it crashed? Not a big deal.
18:48cosurgi: If I can switch while it's running inside gdb, then all is good.
18:53cosurgi: but in fact I still only want to see tha backtrace, right?
19:03cosurgi: so and the only thing I would do in the terminal running gdb would be type command 'backtrace'. So how is this different from seeing the actual crash backtrace after it happens?
19:04ajax: different backtracing implementations.
19:04ajax: the one in glibc is quite limited, it doesn't know about debugging information so it gets function names wrong a lot
19:34imirkin: karolherbst: fyi, the nouveau-firmware package that gst* was talking about contained ctx fw for nv4x and nv5x, which indeed was a temporary package
19:35imirkin: and that firwmare is indeed now generated automatically by nouveau
19:55imirkin: cosurgi: just skimming the logs ... anything in dmesg around when this happened? bus error indicates we tried to access some memory that we thought was mapped but wasn't.
19:58imirkin: hm. i see you included dmesg, with nothing particularly damning appearing at the relevant time
19:59imirkin: oh, and here's a pro-tip for running X under gdb -- do NOT attach to a running X server with gdb in an xterm running as a client against that X server...
20:01imirkin: mupuf: should call the new default priority/severity like "no touch" :)
20:01imirkin: or "not for you"
20:15karolherbst: imirkin: ahh, forgot about that
20:15karolherbst: imirkin: that's why the hint about ssh and a second machine :p
20:16imirkin: second machine, or different GPU with a different X server -- highly preferable :)
20:22cosurgi: karolherbst, imirkin : yeah I guessed so. I would rather do this from inside screen ;)
20:22cosurgi:is addicted to screen.
20:23imirkin: cosurgi: can you reproduce this fairly easily?
20:23cosurgi: This helped me recently with more frequent xserver crashes ;)
20:23imirkin: yeah, screen is nice.
20:23imirkin: apparently tmux is the cool new thing
20:23cosurgi: imirkin: that's a roughly two days wait until this occurs. Provided that I am running thsese calculations. Which I plan to do.
20:24imirkin: i'll double-check the code to see if there's anything obvious we're doing wrong
20:24imirkin: like trying to obviously access stuff outside the map area
20:24imirkin: that was actually my very first contribution to xf86-video-nouveau -- fixing an issue like that
20:24cosurgi: bear in mind that heavy CPU load is the trigger. Something realtime is happening there and the CPU does not respond fast enough.
20:25imirkin: sometimes when i dragged an mplayer window from workspace to workspace, it'd fail. sometimes it worked fine. good times.
20:26cosurgi: whoa! great patch :)
20:26karolherbst: imirkin: the memcpy fallback is weird, and his desktop size is quite big
20:26cosurgi: clean work.
20:26karolherbst: maybe some NULL pointer somewhere
20:27karolherbst: imirkin: there is this message coming up in the x log from this path: https://github.com/freedesktop/nouveau-xf86-video-nouveau/blob/master/src/nouveau_exa.c#L376
20:27karolherbst: shortly before the crash
20:27cosurgi: And the funniest thing is that two times it happened during `xset dpms force off`, the third time the screens were on.
20:27imirkin: yeah, so if those calculations are off somehow
20:27imirkin: then it could definitely crash
20:27karolherbst: resolution: 6480x3840
20:27imirkin: wait, it's the fucking same issue
20:28imirkin: as the one i fixed in that bug
20:28imirkin: i think.
20:28imirkin: i'll have to read through and think
20:28karolherbst: when was it?
20:28cosurgi: 2013 I see ;)
20:28karolherbst: ahh, that one
20:28karolherbst: maybe it happens again with more insane resolution
20:28karolherbst: 6480x3840 is quite huge...
20:28imirkin: basically this becomes a lot more likely when your pitch is multiples of page size
20:29imirkin: i'm going to read the code though. it could well be fine.
20:29imirkin: but it feel like it could be related, like we're writing off the end of the image due to cleverness.
20:29karolherbst: and I wouldn't be surprised if cosurgi is the only one with such a resolution under nouveau :p
20:29imirkin: AND hitting that fallback
20:29karolherbst: could be
20:29karolherbst: but hopefully gdb tells us more
20:29imirkin: which can only happen when nouveau_exa_scratch fails
20:30imirkin: should check when that happens
20:30cosurgi: me neither. The only reason is that I started using linux in 1990, and amd (or whatever) drivers didn't exist. I stuck with nvidia since then, until I bought these monitors, which nvidia drivers can't handle
20:30karolherbst: imirkin: you've seen the X log, right?
20:30karolherbst: cosurgi: uff. "nvidia driver" as in, super old legacy one
20:31imirkin: the nv driver doesn't handle pascal :)
20:31cosurgi: no. a year ago I used the latest and greatest nvidia drivers here.
20:31imirkin: iirc it had hacked-on G80 support, but not much past that
20:31karolherbst: I am actually surprised that nvidia doens't allow a nearly 8k res :p
20:31imirkin: coz G80 really doesn't fit the userspace modesetting model very well
20:31cosurgi: by "nvidia can't handle" I mean a total PC freeze every 6 months due to the longstanding nvidia bug which causes freeze during VT switch.
20:32imirkin: cosurgi: how's the nouveau experience? i doubt we get that kind of stability
20:32cosurgi: If I wasn't sucked by nvidia 25 years ago I would be using amd now ;)
20:33karolherbst: imirkin: btw.. I started to write the libdrm replacement... wrapping around libdrm with a new API didn't worked out
20:33cosurgi: imirkin: much better - only xserver crashes every 6 weeks. (or every 2 days when I am running calculations). Provided that I run 5 xservers simulateneulsy, the crash does not destroy all my work. Only one "topic" of my work. Which is manageable.
20:33imirkin: cosurgi: 25y ago ... that's a long time. 1996? that's pre-TNT...
20:34cosurgi: imirkin: yeah, I remember downloading and compiling the first nvidia drivers out there.
20:34imirkin: karolherbst: no. libdrm is terminally broken.
20:34imirkin: cosurgi: NV1 + saturn? :)
20:34karolherbst: imirkin: I mean, my attempt was to write a serializing wrapper around libdrm, to have the wrapper be thread safe
20:34cosurgi: something like that... can't remember now ;)
20:34karolherbst: but that really didn't work
20:34imirkin: or the (slightly later) Riva 128?
20:34karolherbst: way less than my second attempt
20:35cosurgi: oh yeah, riva rings the bell
20:35imirkin: iirc i knew someone who wrote a voodoo wrapper for those ... or something
20:35karolherbst: cosurgi: what prevented you from switching over to AMD?
20:35imirkin: what was that api called
20:35cosurgi: nvidia wasn't bad until I bought these monitors :)
20:35imirkin: (the tdfx one...)
20:35karolherbst: cosurgi: ahh :D
20:35cosurgi: and I already had bough the GPU for these monitors, before I bought them.
20:35karolherbst: mhh, maybe they fixed the driver by now :p
20:36karolherbst: but yeah
20:36cosurgi: So sort of couldn't switch GPU, as I was already out of funds ;)
20:36karolherbst: we want to get it working with nouveau anyway
20:36cosurgi: I am not switching now. Even if they fixed it. I jusr *love* fast VT switching. With nvidia it's 2 seconds to switch a VT.
20:37cosurgi: so we better fix this :-))
20:37imirkin: anyways, that memcpy stuff looks a little suspect. i'm going to have a closer look at it.
20:37imirkin: hopefully i remember to actually do that.
20:37imirkin: cosurgi: i suspect nvidia with drm support should be just as fast
20:37imirkin: er, s/drm/kms/
20:38cosurgi: hmm.. ehh. Not worth switching, right now at least. I would need some greater reason to reboot my PC :) Too many working, not crashed xserver sessions :)
20:39imirkin: you have an interesting workflow.
20:39cosurgi: thanks :)
20:39imirkin: nothing wrong with it (from my perspective), but definitely unusual
20:40cosurgi: also I sue UPS and hibernation in order to presever the 200 opened windows :) One day I had to recompile xserver to just increase the limit of opened windows from 256 to 512. Also that's one of the reasons that I've split my work into "topics" in dofferent xservers.
20:40imirkin: i won't even dare i ask how many tabs you have open in chrome :p
20:40cosurgi: it's harder to hit the hard limit of 256 opened windows, when I have several xservers.
20:41cosurgi: hahahah! You are right :) Recently It got much better that chrome sessions are split per topic. But previously I had like 50 windows with over 50 tabs each :)
20:42cosurgi: like I don't know what bookmars are for :)
20:42cosurgi: and yeah. I almost don't use bookmarks :)
20:44cosurgi: imirkin: and each xserver is run by a different user. Each user has his own /home/directory, and all of them share the same .dotfiles though git.
20:44cosurgi: There is no username 'cosurgi'. It is a group. And all these "topic" users belong to that group.
20:44imirkin: i think psychiatrists call this "multiple personality disorder"...
20:44cosurgi: And /home/cosurgi is a git directory with my documents.
20:44cosurgi: Yeah. It's very useful.
20:46cosurgi: Actually I even hacked zsh prompt a little to display `git status` of three gits: (1) cosurgi git (2) dotfiles and (3) local git directory, see this here: https://gitlab.com/cosurgi/zsh-git-cal-status-cpp
20:47cosurgi: The "j✓│d+2│" is the git status of the first two gits
20:51imirkin: i'm going to trace what exaMoveOutPixmap does at some point
20:51imirkin: i'm not 100% sure that upload_to_screen thing is the issue
20:52imirkin: i think it's just coincidence -- libdrm doesn't want to create a fresh bo for some reason, so that triggers
20:52imirkin: it happens somewhere else, and we crash
20:52cosurgi: If you need to tu run something extra here. I'm happy to. I didn't start the gdb stuff yet, but can do that too. I just want to finish some part of my work.
20:52cosurgi: *If you need me to run something extra here. I'm happy to.
20:52imirkin: if you capture it in gdb, with debug symbols, that'd obviously be useful
20:53imirkin: just do like a "bt full" when that happens
20:54cosurgi: ok, I will have to compile xf86-video-nouveau locally, not as *.deb package. Then start it locally from users directory. Would there be any permission problems?
20:54cosurgi: I don't want to overwrite the system-wide install of xf86-video-nouveau, as we have prior experience that this causes all other xservers to crash.
20:56imirkin: no problem... just have to add it to the ModulePath in the xorg.conf
20:57cosurgi: OK, I will let you know when I get to this point.
20:57cosurgi: Might be tomorrow or the next day. When I finish this computation algorithm, I will be calculating a lot, and this is gonna happen soon. So then fixing this crash will be high priority.
20:58imirkin: yeah ... feel free to hit me up on email too, i'm not irc as much as before
20:58imirkin: i do tend to scan the logs though
20:59cosurgi: alum.mit edu, right?
20:59cosurgi: OK :)
21:24cosurgi:runs git clone https://github.com/freedesktop/nouveau-xf86-video-nouveau.git
21:25cosurgi: Run 'make' to build xf86-video-nouveau :)
21:25cosurgi: ah, I see -g flag is already here. Nice.
21:25cosurgi: CFLAGS: -g -O2 -Wall -minline-all-stringops -fvisibility=hidden -I/usr/include/xorg -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/X11/dri
21:26cosurgi: make took only 3 seconds?
21:27imirkin: it's not a lot of code.
21:28cosurgi: CCLD nouveau_drv.la ← is this what I need for ModulePath ?
21:29imirkin: word of warning... you have to include ALL the modulepaths, not just that one
21:29imirkin: if you run "make install", that's the thing that gets installed
21:30imirkin: automake puts things in weird places though
21:30imirkin: (i mean in the build tree)
21:30cosurgi: but I don't need to run "make install", because I want to run it from users directory?
21:30imirkin: you don't HAVE to
21:31imirkin: just saying, if you did, that's the file that would get installed
21:31imirkin: normally i just copy that file into a test dir
21:31imirkin: which i have in my ModulePath list
21:31imirkin: in a special xorg config i use for testing such things
21:31cosurgi: ok. So I will copy it.
21:32cosurgi: mkdir ~/test-nouveau ; cp src/.libs/nouveau_drv.so ~/test-nouveau
21:32cosurgi: now let's prepare xorg.conf
21:32imirkin: i use "test", but i think test-nouveau will be fine too
21:33cosurgi: we start with this one: https://paste.ubuntu.com/p/xtD9SXGMwS/
21:33cosurgi: Where do I add this ModulePath, and what to put there? :)
21:34cosurgi: I can rename it to ~/test, then it will be similar to yours :)
21:35cosurgi: /home/deb/test/nouveau_drv.so it is now.
21:36cosurgi:tries to determine what ModulePath is used right now.
21:36imirkin: different section
21:36imirkin: and you have to load in the current path
21:36imirkin: it should be in your xorg log
21:37imirkin: it's in Section "Files"
21:37cosurgi: [2097562.220] (==) ModulePath set to "/usr/lib/xorg/modules"
21:37imirkin: yeah, so do like
21:37imirkin: ModulePath "/path/to/my/thing"
21:37imirkin: ModulePath "/usr/lib/xorg/modules"
21:38cosurgi: like this: https://paste.ubuntu.com/p/QrqFm2J6jD/ ?
21:39imirkin: Yes, but the other way
21:39cosurgi: make sense actually :)
21:39cosurgi: makes sense actually :)
21:39imirkin: and in the xorg log, you should see the full path of the nouveau_drv that's loaded
21:40cosurgi: ok, let's try that
21:40imirkin: which should ideally be that one :)
21:43cosurgi: the new Xorg log: https://paste.ubuntu.com/p/5FmHGwd2MM/
21:43cosurgi: [2267810.116] (II) Loading /home/deb/test/nouveau_drv.so
21:43cosurgi: looks good.
21:44cosurgi: So what next: attach gdb now?
21:44cosurgi: Then start my calculations, switch to that xserver and wait?
21:45imirkin: you won't be able to switch away when it crashes...
21:45cosurgi: That's not a problem. I will attach from inside screen, then ssh in and reattach screen.
21:47cosurgi: I will check the PID now. That would be the PID of Xorg ?
21:47cosurgi: 13271 /usr/lib/xorg/Xorg :7 -config xorg.conf-TEST -nolisten tcp -dpi 100 vt11 -keeptty -auth /tmp/serve……… this one?
21:47imirkin: presumably, yes
21:48imirkin: wow, keeptty... fancy
21:48cosurgi: It has one child with the same process name and PID 13276
21:48cosurgi: I didn't add keeptty in invocation. I suppose startx added it
21:48imirkin: erm, ok. i dunno anything about that.
21:50cosurgi: should I attach as root? I mean, run gdb as root?
21:51cosurgi: Xorg is run by root, so I suppose I have to.
21:53cosurgi: yep: ptrace: Operation not permitted.
21:54cosurgi: gdb -p 13271
21:55cosurgi: Attaching to process 13271
21:55cosurgi: [New LWP 13276]
21:55cosurgi: [Thread debugging using libthread_db enabled]
21:55cosurgi: Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
21:55cosurgi: 0x00007f82a238a7ef in epoll_wait (epfd=3, events=events@entry=0x7ffe06387be0, maxevents=maxevents@entry=256, timeout=170487) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
21:55cosurgi: 30 ../sysdeps/unix/sysv/linux/epoll_wait.c: No such file or directory.
21:55cosurgi: Do I need this epoll_wait.c ?
21:55cosurgi: that was easier than I expected.
21:55cosurgi: Provided this will work :)
21:56cosurgi: let's see what happens if I try to attach to child now, will it produce some error?
21:57imirkin: just make sure you hit "c", otherwise the X server will stay stuck
21:57cosurgi: Attaching to process 13276
21:57cosurgi: warning: process 13276 is already traced by process 16415
21:57cosurgi: ptrace: Operation not permitted.
21:57cosurgi: yep. Cannot debug the child process. It's already taken.
21:57cosurgi: (gdb) c
21:57cosurgi: I didn't use gdb for a loooong time.
21:58imirkin: it's gotten a lot better
21:58cosurgi: My preferred way of debugging is LOG_INFO("stuff" << stuff << "wtf?");
21:58imirkin: compared to a looooong time ago :)
21:58imirkin: yeah, i do that a lot too
21:58imirkin: in general i prefer printf-debugging
21:58imirkin: but usually i start with gdb to get a sense of what might be happening
21:59imirkin: and if it's not obvious, i'll add prints all over
21:59imirkin: like if it's a more dynamic issue
21:59imirkin: gdb is nice for when you have no clue what to look for, and have lots of complex structures
22:00cosurgi: so the next command shall be `bt full`, right? :)
22:01cosurgi: Maybe I will finish my algorith before I hit the bed, then run calculations on all CPUs before I hit the bed :)
22:01cosurgi: And leave that xserver running
22:01cosurgi: whoa. I must be already sleepy. I typed hit the bed twice ;)
22:07cosurgi: interesting, when I switched to that xserver I got this:
22:07cosurgi: Thread 1 "Xorg" received signal SIGUSR1, User defined signal 1. |
22:07cosurgi: 0x00007f82a238a7ef in epoll_wait (epfd=3, events=events@entry=0x7ffe06387be0, maxevents=maxevents@entry=256, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30 |
22:07cosurgi: 30 in ../sysdeps/unix/sysv/linux/epoll_wait.c |
22:07cosurgi: (gdb) c |
22:07cosurgi: Continuing. |
22:07cosurgi: I already had to ssh in, to type 'c' because it froze :)
22:08cosurgi: command `setxkbmap -option ctrl:nocaps` ran from terminal produces a message in gdb window:
22:08cosurgi: [Detaching after fork from child process 17834] |
22:09cosurgi: But it keeps producing it everytime I issue this command with a different PID. So I suppose it's not really detaching from Xorg, just something else is detaching.
22:09imirkin: oh that's annoying =/
22:10imirkin: something sends a USR1 signal
22:10imirkin: which obviously interrupts gdb, since it listens to signals
22:10cosurgi: It got sent when I switchied VT.
22:10imirkin: there's some way to create a signal mask
22:10imirkin: i don't remember how
22:10cosurgi: Maybe it's always sent on switching VT ?
22:10imirkin: to basically ignore certain signals
22:10imirkin: yeah, probably is
22:10imirkin: try running
22:11imirkin: handle USR1 nostop
22:11imirkin: (in gdb, after this happens)
22:11cosurgi: ok. Let's switch VT again
22:11cosurgi: Unrecognized or ambiguous flag word: "USR1".
22:12imirkin: try handle SIGUSR1 nostop :)
22:12cosurgi: (had to type 'c' again) OK :)
22:12imirkin: c to continue after that
22:12cosurgi: I think it worked:
22:12cosurgi: Signal Stop Print Pass to program Description
22:12cosurgi: SIGUSR1 No Yes Yes User defined signal 1
22:15cosurgi: okay. So I think we are all set for the crash :)
22:15cosurgi: Now cross fingers that this xserver crashes first :)
22:16cosurgi: I will move my work here.
22:16cosurgi: gvim session save FTW
22:16imirkin: yeah, i learned to do that with emacs a while back... kinda good and kinda bad
22:16imirkin: now it takes like 1 full minute to start :)
22:16cosurgi: uhh :)
22:16imirkin: soooo many files to open
22:17cosurgi: but you have only one emacs instance ?
22:17imirkin: it opens, tokenizes, etc them
22:17cosurgi: I tend to have vim session in each working git directory. And since I have plenty of local git dirs, that's manageable
22:18cosurgi: and I have 10 to 20 running gvim sessions :)
22:18cosurgi: in eaxh xserver ;)
22:18cosurgi: in each xserver ;)
22:18cosurgi: so loading such "small" gvim session is rather fast. Max 2 seconds.
22:18imirkin: i do this fairly rarely
22:18imirkin: so it's ok
22:39airlied: imirkin: seen anything like https://bugzilla.redhat.com/show_bug.cgi?id=1736814?
22:40imirkin: hope that helps :)
22:41imirkin: they even link to the bug in nouveau bugtracker where i've made a number of comments: https://bugs.freedesktop.org/show_bug.cgi?id=111213
22:41imirkin: the quick solution is "stop using compute"
22:41imirkin: which was turned on by amd because it's better for amd
22:42imirkin: unfortunately they're also doing _something_ slightly illegal, not sure what yet, which causes the stuff to not work
22:42imirkin: and unrelated to those illegal things, there's also additional bugs in nouveau
22:50cosurgi: heh. ccache has to refill ~/.ccache
22:50cosurgi: Couple of slow recompilations await.
23:32airlied: imirkin: okay so for 19.1 backport a don't use compute hack would work?