Kernel Bug Tracker – Bug 28012
[drm:i915_driver_load] *ERROR* failed to init modeset, EINVAL
Last modified: 2011-02-12 22:43:11 UTC
Created attachment 45792 [details]
dmesg after modprobe i915 modeset=1 (with no modules loaded beforehand)
Under 2.6.37, modprobe i915 modeset=1 switched to 128x48 all right. Under 2.6.38-rc3, it garbles the screen: there's an irregularly blinking narrow rectangle spanning the full height of the screen in the column of the cursor. The machine otherwise works. The wastly overheight cursor advances on each keypress but no single letter is visible on the screen, apart from some faint broken lines flying away during heavy scrolling. Full dmesg attached, but it ends with:
[ 13.585039] i915 0000:00:02.1: BAR 6: can't assign [??? 0x00000000 flags 0x0] (bogus alignment)
[ 13.585168] [drm] failed to find VBIOS tables
[ 13.597709] [drm] initialized overlay support
[ 13.597779] vga_switcheroo: disabled
[ 13.597898] [drm:i915_driver_load] *ERROR* failed to init modeset
[ 13.598562] i915: probe of 0000:00:02.1 failed with error -22
Maybe it's only prudent to add that the machine is a ThinkPad R50e with an Intel 855GM chipset.
drm.debug=0xf if you please.
My suspicion is that drm_irq_install() is the one returning EINVAL, probably due to drm_dev_to_irq() returning an error.
Is the IRQ for the igfx disabled on your machine? [lspci?]
I'll shortly reboot into 2.6.38-rc3 with drm.debug=0xf, but until then the lspci output taken under 2.6.37:
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) (prog-if 00 [VGA controller])
Subsystem: IBM ThinkPad R50e
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+
Interrupt: pin A routed to IRQ 11
Region 0: Memory at e0000000 (32-bit, prefetchable) [size=128M]
Region 1: Memory at d0000000 (32-bit, non-prefetchable) [size=512K]
Region 2: I/O ports at 1800 [size=8]
Expansion ROM at <unassigned> [disabled]
Capabilities: [d0] Power Management version 1
Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: i915
IRQ 11 doesn't seem disabled now:
$ fgrep 11 /proc/interrupts
11: 57470 XT-PIC-XT-PIC ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb4, i915, Intel 82801DB-ICH4 Modem, yenta, ipw2200, Intel 82801DB-ICH4, utp
Is there a way to get some readable screen back after the module loading failure? That would help me tremendously (this is a standalone machine), the only output is the LVDS and a handful of LEDs...
Created attachment 45822 [details]
dmesg with drm.debug=0xf under 2.6.38-rc3
I spent approx 70 seconds at the initramfs prompt before loading i915.
Then I let the boot proceed with garbled screen, eventually trying to start X.
Ctrl-Alt-F1 gave me back the blinking vertical strip, where I logged in and saved the dmesg and the lspci outputs, then rebooted the machine.
Created attachment 45832 [details]
lspci under 2.6.38-rc3
This is identical to the one found in the working system under 2.6.37.
Created attachment 45842 [details]
Where does it go wrong?
Ok, that didn't really tell me anything more. (Except for the part where we fail to unload the module after an error, and explains more than anything else why everything is screwed up afterwards. Which I'm going to ignore for now...)
The attached should hopefully pinpoint the reason why it fails. Hopefully.
Created attachment 45852 [details]
dmesg with drm.debug=0xf under 2.6.38-rc3 with the WARN patch applied
This is with the patch in attachment 45842 [details] applied.
It indeed provoked a
WARNING: at drivers/gpu/drm/drm_irq.c:328 drm_irq_install+0x56/0x219 [drm]()
Can you attach the complete lspci?
The trouble begins when we start initializing the 2.1 device... !!!
Created attachment 45882 [details]
full lspci output
My bad, sorry, 00:02.1 is indeed relevant, it's a Display controller...
Created attachment 45892 [details]
Only bind to function 0
This looks to be the right idea, but I've yet to test it...
It survived booting on 945GME which also has the useless 2.1 function.
It also works for me!
Good (and quick) job, thanks a lot!
As far as I'm concerned, this bug is resolved now.
Patch : https://bugzilla.kernel.org/attachment.cgi?id=45892
Handled-By : Chris Wilson <firstname.lastname@example.org>
Fixed by commit 5fe49d86f9d01044abf687a8cd21edef636d58aa .