Created attachment 93957 [details] Xorg.0.log I have an ancient computer with a FX 5200 card which is played to an old TV via composite output. It has been working for ages, until I upgraded the system (debian) and now when I start X, the tv image goes off. This setup is using KMS, and IIRC newer kernels had the same problem on module load. I downgraded the kernel to 3.11.2 and now the framebuffer is working fine again (with at least 3.11.6 and newer kernels it's a no-go). But when starting X, the image is gone and the log tells: [ 164.729] (==) NOUVEAU(0): Swap limit set to 2 [Max allowed 2] [ 164.783] (II) NOUVEAU(0): Output VGA-1 has no monitor section [ 164.843] (II) NOUVEAU(0): Output DVI-I-1 has no monitor section [ 164.896] (II) NOUVEAU(0): Output TV-1 has no monitor section [ 164.950] (II) NOUVEAU(0): EDID for output VGA-1 [ 165.003] (II) NOUVEAU(0): EDID for output DVI-I-1 [ 165.056] (II) NOUVEAU(0): EDID for output TV-1 [ 165.056] (II) NOUVEAU(0): Output VGA-1 disconnected [ 165.056] (II) NOUVEAU(0): Output DVI-I-1 disconnected [ 165.056] (II) NOUVEAU(0): Output TV-1 disconnected [ 165.056] (WW) NOUVEAU(0): No outputs definitely connected, trying again... [ 165.056] (II) NOUVEAU(0): Output VGA-1 disconnected [ 165.056] (II) NOUVEAU(0): Output DVI-I-1 disconnected [ 165.056] (II) NOUVEAU(0): Output TV-1 disconnected [ 165.057] (WW) NOUVEAU(0): Unable to find connected outputs - setting 1024x768 initial framebuffer
Created attachment 93958 [details] Full dmesg
What happens if you're in X (with the image off) and then try to switch back to the console? Does it come on, or is it off forever? I don't see any relevant changes between 3.11.2 and 3.11.6... would be very interesitng to know what causes the additional regression -- it should be a pretty fast bisect, if you're up for it. What kernel were you using before the upgrade? I'm guessing "ancient" (like pre-3.7)? It would also be interesting to see a dmesg from semi-working boot (i.e. 3.11.2) and X loading, with "nouveau.debug=debug drm.debug=0xe" options added to the kernel cmdline.
(In reply to comment #2) > What happens if you're in X (with the image off) and then try to switch back > to the console? Does it come on, or is it off forever? It's off forever. But I can't even reproduce this anymore, please keep reading. > > I don't see any relevant changes between 3.11.2 and 3.11.6... would be very > interesitng to know what causes the additional regression -- it should be a > pretty fast bisect, if you're up for it. In fact, it's worse: It seems intermitent. I can only get there about 1 in 3 attempts if I cold boot (w kernel 3.11.2, I suspect newer kernels could be the same thing) (i.e. turn the power off and on again), but never if I just reboot after getting the "blue screen" from tv. But here is the strange thing: I tested on another tv and it's ok. Since this problematic tv only hits this bug on KMS (intermitent)/xserver w/ nouveau(always happens as far as I've observed), but not on console or vesa fb, I suspect it could be related to load detection. I tried booting with param video=TV1:e as (poorly) documented way to force tv on. dmesg log and X log now plays nice as if the tv was indeed connected, however, I can't see anything past kms trigger. Is there a way to truly override load detection? As I said, the other tv is just fine, the dmesg shows tv connected.
(In reply to comment #3) > I tried booting with param video=TV1:e as (poorly) documented way to force I think you want TV-1:e. > tv on. dmesg log and X log now plays nice as if the tv was indeed connected, > however, I can't see anything past kms trigger. > > Is there a way to truly override load detection? As I said, the other tv is > just fine, the dmesg shows tv connected. There's a nouveau.tv_disable which is listed as "Disable TV-out detection". I kind of assume it just ignores the outputs entirely, but who knows. You may want to peruse drivers/gpu/drm/nouveau/dispnv04/tvnv17.c:nv17_tv_detect It has special exceptions for a couple of cards with quirks. There's a way to return a "status unknown" -- try that? But it's a little odd that it worked fine before -- what was the "before" kernel? FTR, S-video worked fine on my NV44 last I checked (~kernel 3.11 or so).
(In reply to comment #4) > (In reply to comment #3) > > I tried booting with param video=TV1:e as (poorly) documented way to force > > I think you want TV-1:e. > Sorry for the typo, I was using that. As I said, it makes drm/x sees the display as existant, but with no video output. Perhaps there could be some hooking between this higher layer and lower ones (eg. nv17_tv_detect) in order to maintain coherence. I say that because even tought this option didn't help, after your suggestion, I was able to hack into nv17_tv_detect making it return connector_status_connected whenever it would return disconnected/unknown, and it's working (for me™). > There's a nouveau.tv_disable which is listed as "Disable TV-out detection". > I kind of assume it just ignores the outputs entirely, but who knows. You > may want to peruse drivers/gpu/drm/nouveau/dispnv04/tvnv17.c:nv17_tv_detect > > It has special exceptions for a couple of cards with quirks. There's a way > to return a "status unknown" -- try that? > Returning connector_status_unknown wasn't enough, but connected did the trick. > But it's a little odd that it worked fine before -- what was the "before" > kernel? I'm not sure anymore, but it wasn't so ancient. 3.8.x perhaps. I'll leave the (dirty, bad mannered) patch attached just in case someone else as lazy as me happens to find this report. The patch doens't fix the issue, only works around it.
Created attachment 94012 [details] [review] dirty work-around that forces the tv output as enabled this was against vanilla kernel 3.13.2
(In reply to comment #5) > (In reply to comment #4) > > But it's a little odd that it worked fine before -- what was the "before" > > kernel? > > I'm not sure anymore, but it wasn't so ancient. 3.8.x perhaps. I'll leave > the (dirty, bad mannered) patch attached just in case someone else as lazy > as me happens to find this report. Would you be willing to (a) Verify whether 3.8.x was indeed good? There aren't a whole lot of changes to the nv17 tv file since 3.8... (b) Do a bisect between the good version and 3.13 (restricted to drivers/gpu/drm/nouveau, so shouldn't be _too_ bad, but maybe like 10 steps). Happy to provide help with the bisect if you're not sure how to do it.
I'm taking this bug report away since I don't even have access to that system anymore.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.