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[1119]] failed to idle channel 0xcccc0001 [Xorg.bin[1119]]
Created attachment 111674 [details] lspci -vv complete output of lspci -vv, you are probably only interested in details of device 02:00.0
Created attachment 111675 [details] Xorg.0.log
[ 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?
>lspci -vnn-t -+-[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] +-01.0-[01]-- +-02.0-[02]----00.0 NVIDIA Corporation G86 [GeForce 8500 GT] [10de:0421] +-03.0-[03]-- +-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] l
Output from `cat /proc/interrupts` in ssh after reenabling msi: CPU0 CPU1 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 ERR: 0 MIS: 0
-- 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.
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.