| Summary: | garbled text after loading nouveau module on EFI boot; X driver thinks there are no connected outputs | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Brian Tarricone <brian> |
| Component: | Driver/nouveau | Assignee: | Nouveau Project <nouveau> |
| Status: | RESOLVED INVALID | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | normal | ||
| Priority: | medium | CC: | homyur |
| Version: | git | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Bug Depends on: | |||
| Bug Blocks: | 34429 | ||
| Attachments: | |||
Created attachment 40330 [details]
dmesg output as X starts
Created attachment 40331 [details]
Xorg.0.log
(Sorry about the mime-type fix spam...)
Not loading the vbios/int10 dumps in grub2 doesn't change anything... somehow nouveau still finds a BIOS via PRAMIN? nvidia proprietary driver still doesn't work as well.
I also tried nv, but no luck ("Ignoring unsupported device 0x10de08a2 (GeForce 320M)"). Only thing I can get working is fbdev.
the bug which manifests as "illegal object class: 0x8597" was fixed by Ben Skeggs almost 2 months ago (xf86-video-nouveau, commit f1ac413d1d3dec2ccf63d4a8c79b9bd9ea578dcf), however it's unrelated to modesetting bug (In reply to comment #4) > the bug which manifests as "illegal object class: 0x8597" was fixed by Ben > Skeggs almost 2 months ago (xf86-video-nouveau, commit > f1ac413d1d3dec2ccf63d4a8c79b9bd9ea578dcf), however it's unrelated to > modesetting bug Hmm then there must be a regression somewhere, as I'm running 1143e7a97dce1b741376e178b73b8b766e03849a from Oct 26th. Hmm so based on the raw DCB: [drm] nouveau 0000:02:00.0: Raw DCB entry 0: 040001b6 0f220010 [drm] nouveau 0000:02:00.0: Raw DCB entry 1: 020112a6 0f220010 [drm] nouveau 0000:02:00.0: Raw DCB entry 2: 02011262 00020010 [drm] nouveau 0000:02:00.0: Raw DCB entry 3: 0000000e 0000000 It looks like the card is reporting 2 DP type outputs, and 1 TMDS output. From the parsing of the connector table: [drm] nouveau 0000:02:00.0: 0: 0x00002047: type 0x47 idx 0 tag 0x08 [drm] nouveau 0000:02:00.0: 1: 0x00101146: type 0x46 idx 1 tag 0x07 It looks like the TMDS output is out of there... perhaps Apple just isn't using it. The two left are an eDP connector and DP connector. It seems Apple is now using eDP for internal display connections? Interesting. Then later: [drm] nouveau 0000:02:00.0: expected bit 16 == 0, got 0x01114000 No connectors reported connected with modes Uh oh. This appears to be from nouveau_dp_auxch(). Unfortunately I'm not sure I can puzzle out what all this is doing. Presumably it's trying to query stuff on the eDP port/connector, but that's failing...? (In reply to comment #6) > Hmm so based on the raw DCB: > > [drm] nouveau 0000:02:00.0: Raw DCB entry 0: 040001b6 0f220010 > [drm] nouveau 0000:02:00.0: Raw DCB entry 1: 020112a6 0f220010 > [drm] nouveau 0000:02:00.0: Raw DCB entry 2: 02011262 00020010 > [drm] nouveau 0000:02:00.0: Raw DCB entry 3: 0000000e 0000000 > > It looks like the card is reporting 2 DP type outputs, and 1 TMDS output. From > the parsing of the connector table: > > [drm] nouveau 0000:02:00.0: 0: 0x00002047: type 0x47 idx 0 tag 0x08 > [drm] nouveau 0000:02:00.0: 1: 0x00101146: type 0x46 idx 1 tag 0x07 > > It looks like the TMDS output is out of there... perhaps Apple just isn't using > it. They are using it, the TMDS encoder is linked to the type 0x46 connector and is used when using a DP->DVI adaptor. > The two left are an eDP connector and DP connector. It seems Apple is now > using eDP for internal display connections? Interesting. Yes, that's correct, as are most vendors now. > > Then later: > > [drm] nouveau 0000:02:00.0: expected bit 16 == 0, got 0x01114000 > No connectors reported connected with modes > > Uh oh. This appears to be from nouveau_dp_auxch(). Unfortunately I'm not sure > I can puzzle out what all this is doing. Presumably it's trying to query stuff > on the eDP port/connector, but that's failing...? It's failing for some reason yes, I'd need to look in more detail to figure out why however. (In reply to comment #7) > > [drm] nouveau 0000:02:00.0: expected bit 16 == 0, got 0x01114000 > > No connectors reported connected with modes > > > > Uh oh. This appears to be from nouveau_dp_auxch(). Unfortunately I'm not sure > > I can puzzle out what all this is doing. Presumably it's trying to query stuff > > on the eDP port/connector, but that's failing...? > > It's failing for some reason yes, I'd need to look in more detail to figure out > why however. Any progress on that? FYI, Nouveau also fails to work when booting the MacBookAir3,1 (there's a few variants, and I tried it on a 1,6ghz C2D processor, 4gb RAM, 128gb SSD) in BIOS emulation mode. One gets a garbled output, both during the text boot sequence and when xorg starts (with considerable color distortion). Consequently, one has to add the "nomodeset" kernel option in order to boot. The proprietary NVIDIA driver does work, however. Shall I open a separate bug report for the 320M card failing to work on the MBA 31 in bios emulation mode? Which debug logs shall I provide, if any? I confirm this two bugs, the one in EFI and the one in BIOS emulation. I'm available for testing/investigating for EFI mode. Let me try your patch ^^ Best regards. Created attachment 41174 [details]
dmesg kernel 2.6.37-rc6 video output corrupted in BIOS emulation
This is dmesg I made from last available kernel, this is a vanilla kernel (no patch added) running on MacBookAir 3,1 in BIOS emulation. The screen is not blank, I will try to decribe it :
- on the left the screen is good over about 200 mm from left to right, then there is garbage till 2/3 of screen, then blank. The garbage are readable characters, but ugly.
It's lock like that hsync is wrong.
I didn't start X at all, I waiting for working console.
do mmiotrace is needed ?
Best regards.
Created attachment 41176 [details]
dmesg kernel 2.6.37-rc6 video output corrupted in EFI
In EFI the screen is mainly empty.
The kernel was patch with physical addr EFI. efifb work fine.
Best regards
Is there any more info or testing I can provide on this? Getting pretty bummed to be using fbdev for the past couple months :( I can confirm this bug, and especially comment #10 - I have exactly the same distortion in BIOS mode (not worrying about EFI here at the moment. As expected, the binary blob NVIDIA drivers work just fine. None of 2.6.35-gentoo-r5, or more importantly vanilla 2.6.37 or 2.6.36-rc7 work with nouveau. `dmesg |grep -e "drm" -e "nouveau" -e "nvidia"` on 2.6.38-rc7 looks like this: ##### [drm] Initialized drm 1.1.0 20060810 nouveau 0000:02:00.0: PCI INT A -> Link[LGPU] -> GSI 22 (level, low) -> IRQ 22 nouveau 0000:02:00.0: setting latency timer to 64 [drm] nouveau 0000:02:00.0: Detected an NV50 generation card (0x0af100a2) [drm] nouveau 0000:02:00.0: Attempting to load BIOS image from PRAMIN [drm] nouveau 0000:02:00.0: ... appears to be valid [drm] nouveau 0000:02:00.0: BIT BIOS found [drm] nouveau 0000:02:00.0: Bios version 70.89.13.00 [drm] nouveau 0000:02:00.0: Pointer to BIT loadval table invalid [drm] nouveau 0000:02:00.0: TMDS table version 2.0 [drm] nouveau 0000:02:00.0: Found Display Configuration Block version 4.0 [drm] nouveau 0000:02:00.0: Raw DCB entry 0: 040001b6 0f220010 [drm] nouveau 0000:02:00.0: Raw DCB entry 1: 020112a6 0f220010 [drm] nouveau 0000:02:00.0: Raw DCB entry 2: 02011262 00020010 [drm] nouveau 0000:02:00.0: Raw DCB entry 3: 0000000e 00000000 [drm] nouveau 0000:02:00.0: DCB connector table: VHER 0x40 5 16 4 [drm] nouveau 0000:02:00.0: 0: 0x00002047: type 0x47 idx 0 tag 0x08 [drm] nouveau 0000:02:00.0: 1: 0x00101146: type 0x46 idx 1 tag 0x07 [drm] nouveau 0000:02:00.0: Parsing VBIOS init table 0 at offset 0x6A0C [drm] nouveau 0000:02:00.0: 0x6CC8: Condition still not met after 20ms, skipping following opcodes [drm] nouveau 0000:02:00.0: Parsing VBIOS init table 1 at offset 0x6E7D [drm] nouveau 0000:02:00.0: Parsing VBIOS init table 2 at offset 0x6E7F [drm] nouveau 0000:02:00.0: Parsing VBIOS init table 3 at offset 0x6EB4 [drm] nouveau 0000:02:00.0: Parsing VBIOS init table 4 at offset 0x6F78 [drm] nouveau 0000:02:00.0: Parsing VBIOS init table at offset 0x6FDD [drm] nouveau 0000:02:00.0: 0x6FDD: Condition still not met after 20ms, skipping following opcodes [drm] nouveau 0000:02:00.0: 4 available performance level(s) [drm] nouveau 0000:02:00.0: 0: memory 405MHz core 405MHz shader 405MHz voltage 900mV [drm] nouveau 0000:02:00.0: 1: memory 450MHz core 450MHz shader 810MHz voltage 900mV [drm] nouveau 0000:02:00.0: 2: memory 450MHz core 450MHz shader 810MHz voltage 900mV [drm] nouveau 0000:02:00.0: 3: memory 450MHz core 450MHz shader 950MHz voltage 900mV [drm] nouveau 0000:02:00.0: c: memory 0MHz core 550MHz shader 1400MHz [drm] nouveau 0000:02:00.0: Detected 256MiB VRAM [drm] nouveau 0000:02:00.0: Stolen system memory at: 0x00af000000 [drm] nouveau 0000:02:00.0: 512 MiB GART (aperture) [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [drm] No driver support for vblank timestamp query. [drm] nouveau 0000:02:00.0: allocated 1366x768 fb: 0x60000000, bo ffff88013a93fc00 fb0: nouveaufb frame buffer device drm: registered panic notifier [drm] Initialized nouveau 0.0.16 20090420 for 0000:02:00.0 on minor 0 ehci_hcd 0000:00:04.1: disable lpm/ppcd for nvidia mcp89 ehci_hcd 0000:00:06.1: disable lpm/ppcd for nvidia mcp89 mbp_nvidia_bl: MacBookAir 3,1 detected Modules linked in: sco bnep rfcomm l2cap snd_hda_codec_hdmi snd_hda_codec_cirrus snd_hda_intel snd_hda_codec snd_hwdep snd_pcm uvcvideo snd_timer applesmc input_polldev mbp_nvidia_bl btusb snd snd_page_alloc mac_hid rtc_cmos xfs exportfs jfs reiserfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq raid1 raid0 dm_snapshot dm_mirror dm_region_hash dm_log scsi_wait_scan usbhid usb_storage hid_apple hid bcm5974 ##### Happy to test any patches or suggestions. Created attachment 44747 [details]
dmesg of last kernel with debug
I made a dmesg log with debug output.
The kernel used is a clone of git branch of nouveau patched with an updated EFI physical mode (merge done by myself).
now the screen is garbage, probably due to the false output resolution (1024x768).
The memory frequency reported mismatch nvidia-settings report : nouveau report 405MHz or 450MHz, nvidia report : 532Mhz for the same card. then the boot frequencies reported by nouveau drivers are totally break. Hello, I made some other tests. The conclusion is that, in bios mode nouveau have only timing issue, the video outputs are detected properly but lines are not draw properly. The issue is on line length which is unstable. I compared modeline provided by nvidia and nouveau they seems to be equals, I do not check V/Hsync and flags. In EFI mode nouveau doesn't detect properly video outputs. it fail in detection process. Best regards Hello, I made more investigation with EFI boot, in particular I tryed boot kernel with video=eDP-1:1024x768e to force to enable eDP-1. the result is that the screen turn off (without "e" the screen show garbage and stay on). The other interresting things is that I get a list of Modeline in dmesg. All of them are rejected with error 15 (that seems to be MODE_VIDEO_HIGH define in kernel sources) enstead of one with -3. Another interresting thing is that the rejected Modeline with -3 is reported as 1368x768 but not the usual 1366x768. I tryed to overide all sanity check to make all modes as MODE_OK. But the screen still turn off at boot. I Hope this help. If yes I can remake logs and put them here. Created attachment 47868 [details]
dmesg efi + nouveau drm + video=eDP-1:1366x768e + debug
It appears that this bug report has laid dormant for quite a while. Sorry we haven't gotten to it. Since we fix bugs all the time, chances are pretty good that your issue has been fixed with the latest software. Please give it a shot. (Linux kernel 3.10.7, xf86-video-nouveau 1.0.9, mesa 9.1.6, or their git versions.) If upgrading to the latest isn't an option for you, your distro's bugzilla is probably the right destination for your bug report. In an effort to clean up our bug list, we're pre-emptively closing all bugs that haven't seen updates since 2011. If the original issue remains, please make sure to provide fresh info, see http://nouveau.freedesktop.org/wiki/Bugs/ for what we need to see, and re-open this one. Thanks, The Nouveau Team |
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.
Created attachment 40329 [details] dmesg output as I modprobe nouveau Hopefully this isn't too similar or the same as #29171. I have one of he new 11" MacBook Air machines (MacBookAir3,1) with the 320M chipset (PCI id 0x08a2, NVAF I believe). I'm booting in EFI mode using grub2, as this machine appears to have issues setting up the SATA controller in BIOS emulation mode. I've booted in BIOS mode and done a dump of the video BIOS and int10 vector, which I'm loading via grub2's "loadbios" command. I'm running 2.6.37-rc2 with a bunch of hw-specific patches applied (as well as a patch to boot in EFI physical rather than virtual mode, which unbreaks PCI), the 16 Nov nouveau-drm snapshot from pq's webdir on people.fd.o, and xf86-video-nouveau git rev 1143e7a. First I modprobe nouveau. Screen flashes, and it looks kinda garbled and messed up. I can vaguely see the cursor flashing, and I can ssh in. I'll attach dmesg output. From that it looks like it's not finding connected outputs, and it's using a fallback 1024x768 res (the LCD panel's native res is 1366x768). From there I try to start X, and it looks like it has the same problem, unable to find a connected output, and then the server segfaults. Also possibly of note: I'm unable to get the nvidia proprietary driver to work either (it just claims it can't initialize the card at all and bails). Please let me know if there's any more information I can provide.