Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Wrong screen resolution detected for Sony F11M1E/W, NVIDIA GT 330|
|Product:||[Fedora] Fedora||Reporter:||Michel Ludwig <michel.ludwig>|
|Component:||xorg-x11-drv-nouveau||Assignee:||Ben Skeggs <bskeggs>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||13||CC:||airlied, ajax, bskeggs, xjcook|
|Fixed In Version:||kernel-220.127.116.11-56.fc13||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-09-20 21:30:10 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Michel Ludwig 2010-07-10 08:50:34 EDT
Created attachment 430874 [details] X server log Description of problem: When using the nouveau driver, the detected screen resolution is wrong as it seems to be bigger than the visible area. xrandr reports the following: Screen 0: minimum 320 x 200, current 1280 x 800, maximum 4096 x 4096 LVDS1 connected 1280x800+0+0 (normal left inverted right x axis y axis) 289mm x 21000mm 1280x800 60.1*+ 1024x768 60.0 800x600 60.3 56.2 640x480 59.9 VGA1 disconnected (normal left inverted right x axis y axis) TV1 unknown connection (normal left inverted right x axis y axis) 1024x768 60.0 800x600 60.3 640x480 59.9 The native resolution of the screen is 1920x1080, and attempts to force such a resolution have no effect. Version-Release number of selected component (if applicable): xorg-x11-drv-nouveau-0.0.16-7.20100423git13c1043.fc13.x86_64 I've attached the X server log. Please let me know if you need more information.
Comment 2 Ben Skeggs 2010-07-11 21:46:33 EDT
Gee, Sony make life fun don't they! On initial inspection it appears that you have one of those laptops where we have to fetch the EDID for the panel from ACPI. However, we never hit that codepath because your GPU/VBIOS have been constructed in such a way that an "older" method of detecting the panel mode succeeded, but contains an invalid resolution for your panel. I'll look at providing a fix for this soon.
Comment 3 Ben Skeggs 2010-07-14 23:43:33 EDT
Can you give this kernel build a try: http://koji.fedoraproject.org/koji/taskinfo?taskID=2321029
Comment 4 Michel Ludwig 2010-07-15 16:06:16 EDT
I've now tried out the new kernel, and I've got some good and bad news :-) The good news is that the resolution seems to have been detected correctly. However, there were two kernel oopses as soon as gdm was showing. I will attach the backtraces. I'm unsure whether they are related to the graphics stuff. Many thanks so far!
Comment 5 Michel Ludwig 2010-07-15 16:07:03 EDT
Created attachment 432209 [details] kernel 18.104.22.168-11.fc13.x86_64 oops 1
Comment 6 Michel Ludwig 2010-07-15 16:07:36 EDT
Created attachment 432210 [details] kernel 22.214.171.124-11.fc13.x86_64 oops 2
Comment 7 Ben Skeggs 2010-07-15 19:42:05 EDT
I don't believe they're related to nouveau, however, it is possible if something really bad is going on. Can you install 126.96.36.199-11.fc13 from http://koji.fedoraproject.org/koji/buildinfo?buildID=183346 (same version as the scratch build above, but without the additional fixes) and see if you still get the oops?
Comment 8 Michel Ludwig 2010-07-18 13:45:05 EDT
Things seem to be a little more complicated... With the kernel from comment 7, the oopses from comments 5 and 6 do not occur. With the vesa driver, everything works fine. However, with nouveau I repeatedly get the following oops: kernel: idr_remove called for id=0 which is not allocated. kernel: Pid: 1669, comm: Xorg Not tainted 188.8.131.52-11.fc13.x86_64 #1 kernel: Call Trace: kernel: [<ffffffff8120c884>] idr_remove+0x108/0x17a kernel: [<ffffffff8144b607>] ? mutex_lock+0x29/0x50 kernel: [<ffffffffa03b5054>] drm_mode_object_put+0x38/0x48 [drm] kernel: [<ffffffffa03b5242>] drm_mode_destroy+0x1a/0x26 [drm] kernel: [<ffffffffa042552a>] nouveau_connector_get_modes+0x42/0x2de [nouveau] kernel: [<ffffffffa0426215>] ? nouveau_connector_detect_lvds+0x17d/0x18f [nouveau] kernel: [<ffffffffa03e7c54>] drm_helper_probe_single_connector_modes+0x10d/0x28c [drm_kms_helper] kernel: [<ffffffffa03b706f>] drm_mode_getconnector+0xf5/0x39e [drm] kernel: [<ffffffffa03ac5df>] drm_ioctl+0x259/0x36a [drm] kernel: [<ffffffffa03b6f7a>] ? drm_mode_getconnector+0x0/0x39e [drm] kernel: [<ffffffff8111a703>] vfs_ioctl+0x32/0xa6 kernel: [<ffffffff8111ac76>] do_vfs_ioctl+0x483/0x4c9 kernel: [<ffffffff8110d6c3>] ? fsnotify_access+0x6c/0x74 kernel: [<ffffffff8111ad12>] sys_ioctl+0x56/0x79 kernel: [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b
Comment 9 Fedora Update System 2010-08-07 01:01:01 EDT
kernel-184.108.40.206-34.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/kernel-220.127.116.11-34.fc13
Comment 10 Fedora Update System 2010-08-07 19:28:59 EDT
kernel-18.104.22.168-34.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/kernel-22.214.171.124-34.fc13
Comment 11 Michel Ludwig 2010-08-08 12:30:49 EDT
Unfortunately, kernel 126.96.36.199-34.fc13 doesn't seem to work well at all. With mode setting enabled, the system freezes completely as soon as gdm is showing. Without mode setting, the system boots fine but nouveau doesn't seem to detect the card. In /var/log/messages the following lines appear: kernel: [drm] nouveau 0000:01:00.0: Detected an NV50 generation card (0x0a5480a2) kernel: [drm] Initialized nouveau 0.0.16 20090420 for 0000:01:00.0 on minor 0 kernel: [drm] nouveau 0000:01:00.0: called without init The X server then seems to fall back to the vesa driver. I'm attaching a new xorg log file.
Comment 12 Michel Ludwig 2010-08-08 12:32:42 EDT
Created attachment 437456 [details] X server log file for kernel 188.8.131.52-34
Comment 13 Ben Skeggs 2010-08-08 18:53:38 EDT
Nouveau can not work without KMS anymore, that's why it falls back to vesa. If you can get a kernel log from after the freeze, we can try and find what's happening. The good news is nouveau finds your resolution now, and other reporters with these laptops say it works, so there's likely something else wrong too.
Comment 14 Michel Ludwig 2010-08-09 06:10:08 EDT
Created attachment 437564 [details] Kernel oops after X server startup on kernel 184.108.40.206-34 Thanks for the info. I've managed now to obtain a kernel backtrace after the X server freeze. This results from booting in mode 3 and then launching the X server manually. It freezes as soon it has cleared the screen and the screen then remains blank.
Comment 15 Ben Skeggs 2010-08-09 18:43:07 EDT
Do you have an X log that goes with that at all?
Comment 16 Michel Ludwig 2010-08-10 04:45:42 EDT
Created attachment 437811 [details] startx output No, the X log is empty and the output from 'startx' doesn't show any error messages. Surprisingly, the X server also started up correctly once, but when I closed it, it hang again. There has also been a different oops when executing 'startx': kernel: [drm] nouveau 0000:01:00.0: Allocating FIFO number 2 kernel: [drm] nouveau 0000:01:00.0: nouveau_channel_alloc: initialised FIFO 2 kernel: BUG: unable to handle kernel paging request at 0000001d00008000 kernel: IP: [<0000001d00008000>] 0x1d00008000 kernel: PGD 1198fa067 PUD 0 kernel: Oops: 0010 [#1] SMP kernel: last sysfs file: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/voltage_now kernel: CPU 2 kernel: Modules linked in: rfcomm sco bridge stp llc bnep l2cap sunrpc cpufreq_ondemand acpi_cpufreq freq_table ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 uinput snd_hda_codec_nvhdmi snd_hda_codec_realtek arc4 snd_hda_intel snd_hda_codec nouveau ecb ttm snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer drm_kms_helper uvcvideo iwlagn btusb snd sky2 drm iwlcore videodev i2c_i801 i2c_algo_bit sdhci_pci sdhci mmc_core v4l1_compat mac80211 v4l2_compat_ioctl32 bluetooth soundcore cfg80211 i2c_core iTCO_wdt iTCO_vendor_support sony_laptop snd_page_alloc rfkill serio_raw microcode firewire_ohci firewire_core crc_itu_t video output [last unloaded: scsi_wait_scan] kernel: kernel: Pid: 1854, comm: upowerd Not tainted 220.127.116.11-34.fc13.x86_64 #1 VAIO/VPCF11M1E kernel: RIP: 0010:[<0000001d00008000>] [<0000001d00008000>] 0x1d00008000 kernel: RSP: 0018:ffff88011989fb40 EFLAGS: 00010246 kernel: RAX: ffff880119938000 RBX: 0000000000000000 RCX: 0000000000000020 kernel: RDX: ffff8801199389c0 RSI: 0000000000000000 RDI: ffff8801199389c0 kernel: RBP: ffff88011989ff38 R08: ffff88011989e000 R09: 00000000000153c0 kernel: R10: 0000000000000001 R11: ffff88012772def8 R12: 0000000001e90fd0 kernel: R13: ffff88011989fdf8 R14: 0000000000000000 R15: ffff88011989fe0c kernel: FS: 00007f735641c7a0(0000) GS:ffff880002080000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b kernel: CR2: 0000001d00008000 CR3: 0000000119871000 CR4: 00000000000006e0 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 kernel: Process upowerd (pid: 1854, threadinfo ffff88011989e000, task ffff880122fa0000) kernel: Stack: kernel: ffffffff8111c869 ffff8801199389c0 ffff88011989ff48 ffff880122fa0000 kernel: <0> ffff880
Comment 17 Fedora Update System 2010-08-10 19:54:00 EDT
kernel-18.104.22.168-37.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/kernel-22.214.171.124-37.fc13
Comment 18 Fedora Update System 2010-08-11 03:26:20 EDT
kernel-126.96.36.199-37.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/kernel-188.8.131.52-37.fc13
Comment 19 Michel Ludwig 2010-08-11 04:19:05 EDT
Created attachment 438117 [details] X server log file for kernel 184.108.40.206-37.fc13 With kernel 220.127.116.11-37.fc13 there are no improvements as such. However, I got a more interesting X server log now. After executing 'startx' and the screen becoming blank, I killed the X server and got the attached backtraces.
Comment 20 Michel Ludwig 2010-08-11 04:19:54 EDT
Created attachment 438118 [details] Kernel oops with 18.104.22.168-37.fc13
Comment 21 Fedora Update System 2010-08-27 07:23:43 EDT
kernel-22.214.171.124-47.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/kernel-126.96.36.199-47.fc13
Comment 22 Michel Ludwig 2010-08-28 14:41:14 EDT
Created attachment 441723 [details] Kernel oops after X server startup on kernel-188.8.131.52-47 There is no apparent behavioural change with kernel 184.108.40.206-47. Sometimes, the X server starts up correctly but then the kernel crashes when the X server is closing (without backtrace), or usually, the kernel crashes as soon as the X server is starting up.
Comment 23 Michel Ludwig 2010-08-28 14:43:12 EDT
Created attachment 441724 [details] X server log file for kernel 220.127.116.11-47
Comment 24 Fedora Update System 2010-08-30 14:22:27 EDT
kernel-18.104.22.168-47.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
Comment 25 Michel Ludwig 2010-08-30 14:26:38 EDT
(In reply to comment #24) > kernel-22.214.171.124-47.fc13 has been pushed to the Fedora 13 stable repository. If > problems still persist, please make note of it in this bug report. The problem related to kernel crashes still exists, see comment 23.
Comment 26 Chuck Ebbert 2010-09-06 13:32:01 EDT
Wow, impressive. First we get this error, followed by a second similar EDID error. Notice the text "Nvidia Default": [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 234 [drm:drm_edid_block_valid] *ERROR* Raw EDID: <3>00 ff ff ff ff ff ff 00 36 7f 25 00 00 00 00 00 ........6.%..... <3>2d 0c 01 04 90 24 14 00 ea a8 e0 99 57 4b 92 25 -....$......WK.% <3>1c 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 .PT............. <3>01 01 01 01 01 01 40 38 80 b4 70 38 40 40 3c 3c ......@8..p8@@<< <3>55 00 68 c8 10 00 00 18 40 38 80 80 71 38 aa 40 U.h.....@8..q8.@ <3>80 80 88 00 68 c8 10 00 00 18 00 00 00 fc 00 4e ....h..........N <3>76 69 64 69 61 20 44 65 66 61 75 6c 00 00 00 fc vidia Defaul.... <3>00 74 20 46 6c 61 74 20 0d 00 00 00 bb bb bb bb .t Flat ........ Then we get an oops in the SLUB allocator, with a traceback showing the block subsystem is trying to allocate memory, that has an impossible address in RBX: mov (%rbx,%rax,1),%rax RBX: 6544206169646976 == "eD aidiv" But that's "vidia De" backwards. So somehow that string has corrupted the slab.
Comment 27 Ben Skeggs 2010-09-07 01:53:13 EDT
Assuming it completes, here's a kernel scratch build which may fix the problem, it's the only potential issue I can see. I can't test myself unfortunately, I don't have the hardware. http://koji.fedoraproject.org/koji/taskinfo?taskID=2450482
Comment 28 Ondrej Danko 2010-09-11 09:48:12 EDT
(In reply to comment #27) > Assuming it completes, here's a kernel scratch build which may fix the problem, > it's the only potential issue I can see. I can't test myself unfortunately, I > don't have the hardware. > > http://koji.fedoraproject.org/koji/taskinfo?taskID=2450482 Excellent works! After this fix booting is without kernel oops :) Finally I can use on Sony Vaio F11M1E nouveau, thanks a lot :)
Comment 29 Ondrej Danko 2010-09-12 05:35:45 EDT
Created attachment 446729 [details] dmesg output for kernel 126.96.36.199-44.fc13.x86_64
Comment 30 Ondrej Danko 2010-09-12 05:41:58 EDT
Created attachment 446731 [details] X server log for kernel 188.8.131.52-44.fc13.x86_64 New problem with this kernel is that Nouveau Gallium 3d is not working, only software 3d acceleration. Note: I have mesa-dri-drivers-experimental installed and with kernel 184.108.40.206-85.fc13.x86_64 hardware 3d acceleration is working without problems but with wrong screen resolution.
Comment 31 Ben Skeggs 2010-09-12 18:55:23 EDT
Thanks for letting me know, I'll push a proper update into the kernel today then. Yes, there's a very good reason for you getting no acceleration. On certain chips there's a random, but very well known hang that we haven't been able to resolve yet. Acceleration has been disabled by default for now. You can reenable with "nouveau.noaccel=0" in your boot options. However, it's very likely you'll experience random hangs as a result.
Comment 32 Fedora Update System 2010-09-15 01:30:42 EDT
kernel-220.127.116.11-56.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/kernel-18.104.22.168-56.fc13
Comment 33 Fedora Update System 2010-09-20 21:29:48 EDT
kernel-22.214.171.124-56.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.