Bug 613284
Created attachment 430876 [details]
dmesg output
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. Can you give this kernel build a try: http://koji.fedoraproject.org/koji/taskinfo?taskID=2321029 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! Created attachment 432209 [details]
kernel 2.6.34.1-11.fc13.x86_64 oops 1
Created attachment 432210 [details]
kernel 2.6.34.1-11.fc13.x86_64 oops 2
I don't believe they're related to nouveau, however, it is possible if something really bad is going on. Can you install 2.6.34.1-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? 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 2.6.34.1-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 kernel-2.6.34.2-34.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/kernel-2.6.34.2-34.fc13 kernel-2.6.34.2-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-2.6.34.2-34.fc13 Unfortunately, kernel 2.6.34.2-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. Created attachment 437456 [details]
X server log file for kernel 2.6.34.2-34
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. Created attachment 437564 [details]
Kernel oops after X server startup on kernel 2.6.34.2-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.
Do you have an X log that goes with that at all? 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 2.6.34.2-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
kernel-2.6.34.3-37.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/kernel-2.6.34.3-37.fc13 kernel-2.6.34.3-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-2.6.34.3-37.fc13 Created attachment 438117 [details]
X server log file for kernel 2.6.34.3-37.fc13
With kernel 2.6.34.3-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.
Created attachment 438118 [details]
Kernel oops with 2.6.34.3-37.fc13
kernel-2.6.34.6-47.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/kernel-2.6.34.6-47.fc13 Created attachment 441723 [details]
Kernel oops after X server startup on kernel-2.6.34.6-47
There is no apparent behavioural change with kernel 2.6.34.6-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.
Created attachment 441724 [details]
X server log file for kernel 2.6.34.6-47
kernel-2.6.34.6-47.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. (In reply to comment #24) > kernel-2.6.34.6-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. 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. 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 (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 :) Created attachment 446729 [details]
dmesg output for kernel 2.6.34.5-44.fc13.x86_64
Created attachment 446731 [details]
X server log for kernel 2.6.34.5-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 2.6.33.3-85.fc13.x86_64 hardware 3d acceleration is working without problems but with wrong screen resolution.
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. kernel-2.6.34.7-56.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/kernel-2.6.34.7-56.fc13 kernel-2.6.34.7-56.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. |
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.