Created attachment 111673 [details]
output of dmesg
After booting a system with Fedora 21 the screen does not switch to graphics mode on start of kde and keeps displaying the last lines of the text mode boot log.
Switching to a text console using alt-Fn key combinations does not work.
System is otherwise working, using ssh to log in remotely works.
Last line from noueveau in dmesg shows it failed in nouveau_channel_idle:
[ 54.068008] nouveau E[Xorg.bin] failed to idle channel 0xcccc0001 [Xorg.bin]
Created attachment 111674 [details]
complete output of lspci -vv, you are probably only interested in details of device 02:00.0
Created attachment 111675 [details]
[ 5.563485] nouveau [ DRM] allocated 1280x1024 fb: 0x60000, bo ffff8800364dfc00
[ 5.563734] fbcon: nouveaufb (fb0) is primary device
[ 11.680075] nouveau E[ DRM] GPU lockup - switching to software fbcon
[ 11.682438] Console: switching to colour frame buffer device 160x64
[ 11.686343] nouveau 0000:02:00.0: fb0: nouveaufb frame buffer device
[ 11.686346] nouveau 0000:02:00.0: registered panic notifier
[ 11.689057] [drm] Initialized nouveau 1.2.0 20120801 for 0000:02:00.0 on minor 0
Hmmm... so it hangs right on start.
Did this particular GPU work with older kernels?
Perhaps MSI is messed up for some reason? Can you try booting with nouveau.config=NvMSI=0 (or pci=nomsi)?
Thanks for the fast reply.
Haven't tried this particular machine with older kernels yet as i was attempting to upgrade from Windows Vista to Fedora 21 and am now trying to get something else but Vesa drivers with 1024x768 to work.
The system did work fine with that other OS.
Booting with nouveau.config=NvMSI=0 is a working.
Thanks for the hint, now to find some info what that actually does :-)
As i have a solution for my issue i wonder whether i should change the status to resolved already.
I'd still prefer to find out why the parameter is necessary.
If the logic when it is necessary is known there might be a way to get the Fedora installer to automatically set it.
Suggestions whether to leave this open and provide more information or to close it are welcome :)
(In reply to bofh666 from comment #6)
> As i have a solution for my issue i wonder whether i should change the
> status to resolved already.
> I'd still prefer to find out why the parameter is necessary.
> If the logic when it is necessary is known there might be a way to get the
> Fedora installer to automatically set it.
> Suggestions whether to leave this open and provide more information or to
> close it are welcome :)
Let's leave this open -- disabling msi should just be done as a temporary workaround. Ideally we'd detect that MSI doesn't work (or perhaps it's not being enabled properly).
Is this a PCIe card, or a PCI card? Could I trouble you for the output of 'lspci -vnn -t' ? (Perhaps this information is available in your lspci -vv output, but I don't know how to read it.)
Can you provide 'cat /proc/interrupts' when you don't boot with the MSI disable and ssh in to obtain it? If any of the other devices are marked as PCI-MSI-*, are you having trouble with them?
-+-[0000:80]---01.0 VIA Technologies, Inc. VT8237A/VT8251 HDA Controller [1106:3288]
\-[0000:00]-+-00.0 VIA Technologies, Inc. P4M890 Host Bridge [1106:0327]
+-00.1 VIA Technologies, Inc. P4M890 Host Bridge [1106:1327]
+-00.2 VIA Technologies, Inc. P4M890 Host Bridge [1106:2327]
+-00.3 VIA Technologies, Inc. P4M890 Host Bridge [1106:3327]
+-00.4 VIA Technologies, Inc. P4M890 Host Bridge [1106:4327]
+-00.5 VIA Technologies, Inc. P4M890 I/O APIC Interrupt Controller [1106:5327]
+-00.6 VIA Technologies, Inc. P4M890 Security Device [1106:6327]
+-00.7 VIA Technologies, Inc. P4M890 Host Bridge [1106:7327]
+-02.0-----00.0 NVIDIA Corporation G86 [GeForce 8500 GT] [10de:0421]
+-0f.0 VIA Technologies, Inc. VT8237A SATA 2-Port Controller [1106:0591]
+-0f.1 VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE [1106:0571]
+-10.0 VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038]
+-10.1 VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038]
+-10.2 VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038]
+-10.3 VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038]
+-10.4 VIA Technologies, Inc. USB 2.0 [1106:3104]
+-11.0 VIA Technologies, Inc. VT8237A PCI to ISA Bridge [1106:3337]
+-11.7 VIA Technologies, Inc. VT8237/8251 Ultra VLINK Controller [1106:287e]
+-12.0 VIA Technologies, Inc. VT6102 [Rhine-II] [1106:3065]
\-13.0 VIA Technologies, Inc. VT8237A Host Bridge [1106:337b]
Output from `cat /proc/interrupts` in ssh after reenabling msi:
0: 141 0 IO-APIC-edge timer
1: 12 0 IO-APIC-edge i8042
7: 0 0 IO-APIC-edge parport0
8: 0 0 IO-APIC-edge rtc0
9: 0 0 IO-APIC-fasteoi acpi
14: 174 0 IO-APIC-edge pata_via
15: 0 0 IO-APIC-edge pata_via
20: 0 0 IO-APIC 20-fasteoi uhci_hcd:usb2
21: 6405 0 IO-APIC 21-fasteoi ehci_hcd:usb1, uhci_hcd:usb4, sata_via
22: 39 0 IO-APIC 22-fasteoi uhci_hcd:usb3
23: 286 0 IO-APIC 23-fasteoi uhci_hcd:usb5, enp0s18
29: 0 0 PCI-MSI-edge nouveau
30: 6171 0 PCI-MSI-edge snd_hda_intel
NMI: 22 25 Non-maskable interrupts
LOC: 1223029 976317 Local timer interrupts
SPU: 0 0 Spurious interrupts
PMI: 22 25 Performance monitoring interrupts
IWI: 0 0 IRQ work interrupts
RTR: 0 0 APIC ICR read retries
RES: 13372 12819 Rescheduling interrupts
CAL: 282 432 Function call interrupts
TLB: 42 38 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
MCE: 0 0 Machine check exceptions
MCP: 1 1 Machine check polls
THR: 0 0 Hypervisor callback interrupts
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/162.