Re: 2.6.39-rc1 nouveau regression (bisected)
Hi. On 15/04/11 16:11, Dominik Brodowski wrote: > On Thu, Apr 14, 2011 at 09:02:01PM +0200, Marcin Slusarz wrote: >> On Thu, Apr 14, 2011 at 07:05:59PM +0200, Dominik Brodowski wrote: >>> Thought about CCing Linus to show him that 2.6.39-rcX isn't as "calm" >>> to everyone, but then chose to CC Maciej instead: Would you be so kind and >>> add this to your regression list? Thanks! >>> >>> Since commit 38f1cff >>> >>> From: Dave Airlie >>> Date: Wed, 16 Mar 2011 11:34:41 +1000 >>> Subject: [PATCH] Merge commit >>> '5359533801e3dd3abca5b7d3d985b0b33fd9fe8b' into dr >>> >>> This commit changed an internal radeon structure, that meant a new >>> driver >>> in -next had to be fixed up, merge in the commit and fix up the driver. >>> >>> Also fixes a trivial nouveau merge. >>> >>> Conflicts: >>> drivers/gpu/drm/nouveau/nouveau_mem.c >>> >>> booting my atom/NM10/ION2 system crashes hard during boot, right after >>> blanking the screen, and before the initramfs gets loaded. I just >>> re-checked: both parent commits ( 5359533 and 4819d2e ) do indeed work >>> just fine, but the merge commit ( 38f1cff ) fails, same as tip ( 85f2e68 ). >> Can you activate netconsole and check whether kernel spits anything >> interesting? >> You might try to load nouveau module after boot - maybe something will be >> saved >> to /var/log or you could even ssh into the box and check dmesg... > Compiling it as a module seems to work fine. When I do so, no regression is > obvious from what gets reported in "dmesg". However, somehow I now do get > some output: The last message I see is > > [drm] nouveau :01:00.0: allocated 1680x1050, fb 0x40 b0 value> > > Then, nothing more. However, it really is quite strange why this error only > appears in the CONFIG_NOUVEAU=y case, not in the =m case... Try disabling CONFIG_BOOT_LOGO. I reported on freedesktop.org that it is causing me an oops at boot, but my bug has been ignored there so far - perhaps I should have posted it here instead. Regards, Nigel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36318] r600g segfaults
https://bugs.freedesktop.org/show_bug.cgi?id=36318 --- Comment #2 from Yannick Dirou 2011-04-17 02:28:10 PDT --- I had similar problem (with r300g) , In fact glxgears did not load the right mesa lib despite a good ldconfig -v (added new mesa path 000_mesa.conf) do: ldd /usr/bin/glxgears it should show the path of the lib used by the app if it is wrong and you use natty or another ubuntu a temporary fix is: sudo rm /etc/ld.so.conf.d/GL.conf (symbolic link to original mesa) sudo ldconfig don't know the right fix though -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
2.6.39-rc3-git7: Reported regressions from 2.6.38
This message contains a list of some regressions from 2.6.38, for which there are no fixes in the mainline known to the tracking team. If any of them have been fixed already, please let us know. If you know of any other unresolved regressions from 2.6.38, please let us know either and we'll add them to the list. Also, please let us know if any of the entries below are invalid. Each entry from the list will be sent additionally in an automatic reply to this message with CCs to the people involved in reporting and handling the issue. Listed regressions statistics: Date Total Pending Unresolved 2011-04-17 17 11 10 Unresolved regressions -- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=33342 Subject : [2.6.39-rc2][bisected] Constant DISK_MEDIA_CHANGE_EVENTS from CDROM drive. Submitter : Shaun Ruffell Date: 2011-04-08 20:15 (10 days old) Message-ID : <20110408201513.ga3...@digium.com> References : http://marc.info/?l=linux-kernel&m=130229371907209&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=33272 Subject : drm related hard-hang Submitter : Peter Teoh Date: 2011-04-14 01:29 (4 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=33242 Subject : Lockdep splat in autofs with 2.6.39-rc2 Submitter : Nick Bowler Date: 2011-04-07 19:44 (11 days old) Message-ID : <20110407194403.ga29...@elliptictech.com> References : http://marc.info/?l=linux-kernel&m=130220545614682&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=33142 Subject : 2.6.39-rc2 regression: X201s fails to resume b77dcf8460ae57d4eb9fd3633eb4f97b8fb20716 Submitter : Keith Packard Date: 2011-04-06 7:44 (12 days old) Message-ID : References : http://marc.info/?l=linux-kernel&m=130207593728273&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=33102 Subject : File's copied from client->linux server only copy 1st 64K data;rest is lost Submitter : Linda Walsh Date: 2011-04-11 22:12 (7 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=33092 Subject : [regression] 2.6.39-rc1 - Beagleboard usbnet broken Submitter : Mark Jackson Date: 2011-04-04 9:22 (14 days old) First-Bad-Commit: http://git.kernel.org/linus/087809fce28f50098d9c3ef1a6865c722f23afd2 Message-ID : <4d998dc9.3040...@mimc.co.uk> References : http://marc.info/?l=linux-kernel&m=130191386508831&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=32982 Subject : Kernel locks up a few minutes after boot Submitter : Bart Van Assche Date: 2011-04-10 19:55 (8 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=32902 Subject : 2.6.39-rc1 doesn't boot on thinkpad t61p x86_64 Submitter : Alex Romosan Date: 2011-04-03 19:41 (15 days old) Message-ID : <87k4fbnmw8@sycorax.lbl.gov> References : http://marc.info/?l=linux-kernel&m=130186054431678&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=32892 Subject : 2.6.39-rc1 data corruption with rtorrent Submitter : Jindrich Makovicka Date: 2011-04-02 20:21 (16 days old) Message-ID : <2011040118.3b5c2fa8@holly> References : http://marc.info/?l=linux-kernel&m=130177570309226&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=32262 Subject : 2.6.38-git15+ IDE hangs boot Submitter : Pete Clements Date: 2011-03-25 15:38 (24 days old) Message-ID : <201103251538.p2pfc11i001...@clem.clem-digital.net> References : http://marc.info/?l=linux-kernel&m=130106749313695&w=2 Regressions with patches Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=33252 Subject : [regression 2.6.39-rc2][bisected] "perf, x86: P4 PMU - Read proper MSR register to catch" and NMIs Submitter : Shaun Ruffell Date: 2011-04-06 22:30 (12 days old) First-Bad-Commit: http://git.kernel.org/linus/242214f9c1eeaae40eca11e3b4d37bfce960a7cd Message-ID : <20110406223036.ga15...@digium.com> References : http://marc.info/?l=linux-kernel&m=130212907032580&w=2 Handled-By : Don Zickus Patch : http://cache.gmane.org//gmane/linux/kernel/1125621-001.bin For details, please visit the bug entries and follow the links given in references. As you can see, there is a Bugzilla entry for each of the listed regressions. There also is a Bugzilla entry used for tracking the regressions from 2.6.38, unresolved as well as resolved, at: http://bugzilla.kernel.org/show_bug.cgi?id=32012 Please let the tracking team know if there are any Bugzilla entries that should be added to the list in there. Thanks!
2.6.36-rc3-git7: Reported regressions 2.6.37 -> 2.6.38
This message contains a list of some post-2.6.37 regressions introduced before 2.6.38, for which there are no fixes in the mainline known to the tracking team. If any of them have been fixed already, please let us know. If you know of any other unresolved post-2.6.37 regressions, please let us know either and we'll add them to the list. Also, please let us know if any of the entries below are invalid. Each entry from the list will be sent additionally in an automatic reply to this message with CCs to the people involved in reporting and handling the issue. Listed regressions statistics: Date Total Pending Unresolved 2011-04-17 98 28 28 2011-03-27 88 26 26 2011-03-06 70 27 26 2011-02-21 51 18 17 2011-02-12 39 20 18 2011-02-03 19 11 7 Unresolved regressions -- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=32862 Subject : acer_wmi partially crashes ACPI/EC (Aspire 8930G) Submitter : Hector Martin Date: 2011-04-07 17:44 (11 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=32762 Subject : Booting with external monitor attached results in red flickering screen on the external monitor Submitter : Anton Date: 2011-04-06 04:50 (12 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=32202 Subject : 2.6.38 hangs on boot until key is pressed Submitter : Tvrtko Ursulin Date: 2011-03-27 19:18 (22 days old) Message-ID : <1301253485.2500.2.camel@deuteros> References : http://marc.info/?l=linux-kernel&m=13012546558&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=32112 Subject : Writes to USB flash drives are extremely slow in 2.6.38 Submitter : Delan Azabani Date: 2011-03-29 08:10 (20 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=32072 Subject : 2.6.38 Regression: Nvidia GeForce8400 + i915 = Crash on Boot Submitter : si...@mungewell.org Date: 2011-03-24 15:20 (25 days old) Message-ID : References : http://marc.info/?l=linux-kernel&m=130100955926434&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=31982 Subject : XFS memory allocation deadlock in 2.6.38 Submitter : Sean Noonan Date: 2011-03-21 16:19 (28 days old) Message-ID : <081dde43f61f3d43929a181b477dca95639b5...@msxaoa6.twosigma.com> References : http://marc.info/?l=linux-kernel&m=130072585111310&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=31922 Subject : ath5k: Decreased throughput in IBSS or 802.11n mode Submitter : Jeff Cook Date: 2011-03-26 20:06 (23 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=31872 Subject : boot panic unless acpi=off, Thread overran stack, or stack corrupted - Toshiba Satellite/mobile P4 Submitter : Pascal Dormeau Date: 2011-03-25 20:17 (24 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=31782 Subject : nouveau: lockdep spew Submitter : Johannes Berg Date: 2011-03-24 09:51 (25 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=31702 Subject : ath5k phy2: failed to wakeup the MAC Chip Submitter : Justin P. Mattock Date: 2011-03-22 19:15 (27 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=31572 Subject : BUG in vb_alloc() - firewire crash at boot Submitter : Pavel Kysilka Date: 2011-03-21 12:40 (28 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=31532 Subject : 2.6.38: Quota over NFS4 Submitter : Adam Lackorzynski Date: 2011-03-17 13:32 (32 days old) Message-ID : <20110317133247.gb6...@os.inf.tu-dresden.de> References : http://marc.info/?l=linux-kernel&m=130036878203485&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=31452 Subject : ath9k: throughput issue in 802.11n and also IBSS mode Submitter : Richard Schütz Date: 2011-03-19 19:06 (30 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=31402 Subject : Diminished brightness at startup Submitter : Guilherme Salazar Date: 2011-03-18 16:29 (31 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=31322 Subject : 2.6.38-rc echo 3 > /proc/sys/vm/drop_caches repairs mplayer distortions Submitter : Hans de Bruin Date: 2011-03-14 21:34 (35 days old) Message-ID : <4d7e89e7.3080...@xmsnet.nl> References : http://marc.info/?l=linux-kernel&m=130014181919827&w=2 Bug-Entry : http://bugzilla.kernel.org/
Re: Linux 2.6.39-rc3
On Sat, Apr 16, 2011 at 02:54:04PM -0400, Jerome Glisse wrote: > If you want to go the printk way you can add printk before each test > ring_test, ib_test in r600.c this 2 functions are the own that might > trigger the first GPU gart activities. Okay, I found the place in source that triggers this. It happens in the function r600_ib_test. The interesting thing is that not the ib-command itself is responsible but the fence that is emitted afterwards (proved by removing the fence command, where the problem went away). I don't know enough about the command semantics to make a guess what goes wrong there. But maybe you GPU folks have an idea? Joerg ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31782] nouveau: lockdep spew
https://bugzilla.kernel.org/show_bug.cgi?id=31782 --- Comment #6 from Lucas Stach 2011-04-17 14:15:07 --- Created an attachment (id=54522) --> (https://bugzilla.kernel.org/attachment.cgi?id=54522) fix in nouveau tree Could you please try the attached patch? It is already in nouveau tree and should hopefully fix the issue. Just want to make sure if we can close this bug. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36327] New: fujitsu siemens amilo li1718: ati radeon x200m does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=36327 Summary: fujitsu siemens amilo li1718: ati radeon x200m does not resume from suspend Product: DRI Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: lengyel.kar...@gmail.com Created an attachment (id=45728) --> (https://bugs.freedesktop.org/attachment.cgi?id=45728) lspci -v When trying to resume from suspend, the computer freezes totally, after a second or so. Nothing can be found in the logs, because loging doesn't even start until then. Resuming from hibernation works fine. I've realised, that if i delete the i2c-algo-bit.ko file (therefore preventing it from being loaded) the resume/suspend will work fine, but there is no compositing, sadly. Using "nomodeset", and trying resume from suspend failed. It is an RC415ME chip (it is written on it). This bug was also submitted a long time ago here: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/577340/ -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36327] fujitsu siemens amilo li1718: ati radeon x200m does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=36327 --- Comment #1 from Karesz L. 2011-04-17 07:26:09 PDT --- Created an attachment (id=45729) --> (https://bugs.freedesktop.org/attachment.cgi?id=45729) Xorg.0.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 2.6.39-rc1 nouveau regression (bisected)
On Sun, Apr 17, 2011 at 11:12:04AM -0400, Kyle Spaans wrote: > On Sat, Apr 16, 2011 at 07:50:28PM -0400, Kyle Spaans wrote: > > On Sun, Apr 17, 2011 at 08:12:35AM +1000, Nigel Cunningham wrote: > > > On 15/04/11 16:11, Dominik Brodowski wrote: > > > > On Thu, Apr 14, 2011 at 09:02:01PM +0200, Marcin Slusarz wrote: > > > >> On Thu, Apr 14, 2011 at 07:05:59PM +0200, Dominik Brodowski wrote: > > > >>> Thought about CCing Linus to show him that 2.6.39-rcX isn't as "calm" > > > >>> to everyone, but then chose to CC Maciej instead: Would you be so > > > >>> kind and > > > >>> add this to your regression list? Thanks! > > > >>> > > > >>> Since commit 38f1cff > > > >>> > > > >>> From: Dave Airlie > > > >>> Date: Wed, 16 Mar 2011 11:34:41 +1000 > > > >>> Subject: [PATCH] Merge commit > > > >>> '5359533801e3dd3abca5b7d3d985b0b33fd9fe8b' into dr > > > >>> > > > >>> This commit changed an internal radeon structure, that meant a > > > >>> new driver > > > >>> in -next had to be fixed up, merge in the commit and fix up the > > > >>> driver. > > > >>> > > > >>> Also fixes a trivial nouveau merge. > > > >>> > > > >>> Conflicts: > > > >>> drivers/gpu/drm/nouveau/nouveau_mem.c > > > >>> > > > >>> booting my atom/NM10/ION2 system crashes hard during boot, right after > > > >>> blanking the screen, and before the initramfs gets loaded. I just > > > >>> re-checked: both parent commits ( 5359533 and 4819d2e ) do indeed work > > > >>> just fine, but the merge commit ( 38f1cff ) fails, same as tip ( > > > >>> 85f2e68 ). > > > >> Can you activate netconsole and check whether kernel spits anything > > > >> interesting? > > > >> You might try to load nouveau module after boot - maybe something will > > > >> be saved > > > >> to /var/log or you could even ssh into the box and check dmesg... > > > > Compiling it as a module seems to work fine. When I do so, no > > > > regression is > > > > obvious from what gets reported in "dmesg". However, somehow I now do > > > > get > > > > some output: The last message I see is > > > > > > > > [drm] nouveau :01:00.0: allocated 1680x1050, fb 0x40 b0 > > > pointer value> > > > > > > > > Then, nothing more. However, it really is quite strange why this error > > > > only > > > > appears in the CONFIG_NOUVEAU=y case, not in the =m case... > > > Try disabling CONFIG_BOOT_LOGO. I reported on freedesktop.org that it is > > > causing me an oops at boot, but my bug has been ignored there so far - > > > perhaps I should have posted it here instead. > > > > I'm getting the exact same symptoms on my Atom + ION hardware. Crashes > > before it > > can write any logs if it's compiled in and the logo is selected, but boots > > fine > > if compiled as a module or the logo is removed. > > > > In my case I bisected and found 8969960 by Nick Piggin (change to > > mm/vmalloc.c) > > to be the first bad one in 2.6.38+. This makes me think that it's not a bug > > in > > nouveau, but maybe a bug in the order that things are initialized? > > FWIW, reverting commit 89699605fe7cfd8611900346f61cb6cbf179b10a on 2.6.39-rc3+ > makes my system boot just fine with the nouveau drivers compiled into the > kernel. I've seen some similar looking bugs on LKML that this regression may > or > may not be related to? It works fine on 2.6.38. > > https://bugzilla.kernel.org/show_bug.cgi?id=33272 > http://lkml.org/lkml/2011/4/15/194 > > I'm still trying to figure out exactly where the kernel is crashing after > printing > [drm] nouveau :03:00.0: allocated 1280x1024 fb: 0x4000, b0 f4cf7600 > > Any thoughts on what else I should look for? I reproduced this bug today, and reverting 89699605fe7cfd8611900346f61cb6cbf179b10a does not fix it for me. Here's the backtrace: Entering kdb (current=0x8801becb, pid 1) on processor 6 Oops: (null) due to oops @ 0x81255081 CPU 6 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.39-rc2-nv+ #640 System manufacturer System Product Name/P6T SE RIP: 0010:[] [] iowrite32+0x12/0x34 RSP: :8801becab4b0 EFLAGS: 00010296 RAX: RBX: 8801bd334800 RCX: 16fc RDX: RSI: c900100bbf4c RDI: c900100bbf4c RBP: 8801becab4b0 R08: 0002 R09: 0001 R10: 00bb R11: 8801becab540 R12: 8801bd336000 R13: 8801bd334818 R14: 8801bd60 R15: 0020 FS: () GS:8801bfd8() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: c900100bbf4c CR3: 01a2b000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process swapper (pid: 1, threadinfo 8801becaa000, task 8801becb) <0>Stack: 8801becab4c0 812f5bd5 8801becab4f0 8130f1f8 8801bd336000 c90012a0 8801becab620 8801becab590
[REGRESSION] [2.6.39-rc3] Wrong resolution in framebuffer and X Window
Hi Last known good: 2.6.38 Failing kernel: 2.6.39-rc3 Subsystem: Intel graphics driver. Description: PC should work with 1440x900 resolution. But console (and after) X Window start work with 1024x768. I attach dmesg and Xorg.0.log with drm.debug=14 log_buf_len=16M options: http://unixy.pl/maciek/download/kernel/2.6.39-rc1/zlom/kms/ seems that driver cannot detect resolution higher than 1024x768. Also I boot kernel replace "i915.modeset=1" with "nomodeset" option: http://unixy.pl/maciek/download/kernel/2.6.39-rc1/zlom/nomodeset/ But then X Window fails to start and got message: "(EE) No devices detected." Config for 2.6.39-rc3: http://unixy.pl/maciek/download/kernel/2.6.39-rc1/zlom/config-2.6.39-rc3 Best regards -- Maciej Rutecki http://www.maciek.unixy.pl ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [REGRESSION] [2.6.39-rc3] Wrong resolution in framebuffer and X Window
On niedziela, 17 kwietnia 2011 o 18:04:04 Maciej Rutecki wrote: > Hi > > Last known good: 2.6.38 > Failing kernel: 2.6.39-rc3 > Subsystem: Intel graphics driver. > > Description: > PC should work with 1440x900 resolution. But console (and after) X Window > start work with 1024x768. > > I attach dmesg and Xorg.0.log with drm.debug=14 log_buf_len=16M options: > http://unixy.pl/maciek/download/kernel/2.6.39-rc1/zlom/kms/ > > seems that driver cannot detect resolution higher than 1024x768. > > Also I boot kernel replace "i915.modeset=1" with "nomodeset" option: > http://unixy.pl/maciek/download/kernel/2.6.39-rc1/zlom/nomodeset/ > > But then X Window fails to start and got message: "(EE) No devices > detected." > > Config for 2.6.39-rc3: > http://unixy.pl/maciek/download/kernel/2.6.39-rc1/zlom/config-2.6.39-rc3 > > Best regards Forgot: 00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 02) Regards -- Maciej Rutecki http://www.maciek.unixy.pl ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36318] r600g segfaults
https://bugs.freedesktop.org/show_bug.cgi?id=36318 --- Comment #3 from Alexandre Demers 2011-04-17 09:22:02 PDT --- If ldd confirms you are using the good library, have a look at the following bug: https://bugs.freedesktop.org/show_bug.cgi?id=36282 It may explain the problem. Otherwise, watchout for Natty, things are a real mess because drivers are now installed under the multiarch folder, but the dev files are installed in a different folder. So if you just compiled and installed like you were doing in previous Ubuntu version, you will end up in a dead end. I had to work a bit to figure everything out. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 2.6.39-rc1 nouveau regression (bisected)
[Repost with different Nick Piggin's address.] On Sun, Apr 17, 2011 at 11:12:04AM -0400, Kyle Spaans wrote: > On Sat, Apr 16, 2011 at 07:50:28PM -0400, Kyle Spaans wrote: > > On Sun, Apr 17, 2011 at 08:12:35AM +1000, Nigel Cunningham wrote: > > > On 15/04/11 16:11, Dominik Brodowski wrote: > > > > On Thu, Apr 14, 2011 at 09:02:01PM +0200, Marcin Slusarz wrote: > > > >> On Thu, Apr 14, 2011 at 07:05:59PM +0200, Dominik Brodowski wrote: > > > >>> Thought about CCing Linus to show him that 2.6.39-rcX isn't as "calm" > > > >>> to everyone, but then chose to CC Maciej instead: Would you be so > > > >>> kind and > > > >>> add this to your regression list? Thanks! > > > >>> > > > >>> Since commit 38f1cff > > > >>> > > > >>> From: Dave Airlie > > > >>> Date: Wed, 16 Mar 2011 11:34:41 +1000 > > > >>> Subject: [PATCH] Merge commit > > > >>> '5359533801e3dd3abca5b7d3d985b0b33fd9fe8b' into dr > > > >>> > > > >>> This commit changed an internal radeon structure, that meant a > > > >>> new driver > > > >>> in -next had to be fixed up, merge in the commit and fix up the > > > >>> driver. > > > >>> > > > >>> Also fixes a trivial nouveau merge. > > > >>> > > > >>> Conflicts: > > > >>> drivers/gpu/drm/nouveau/nouveau_mem.c > > > >>> > > > >>> booting my atom/NM10/ION2 system crashes hard during boot, right after > > > >>> blanking the screen, and before the initramfs gets loaded. I just > > > >>> re-checked: both parent commits ( 5359533 and 4819d2e ) do indeed work > > > >>> just fine, but the merge commit ( 38f1cff ) fails, same as tip ( > > > >>> 85f2e68 ). > > > >> Can you activate netconsole and check whether kernel spits anything > > > >> interesting? > > > >> You might try to load nouveau module after boot - maybe something will > > > >> be saved > > > >> to /var/log or you could even ssh into the box and check dmesg... > > > > Compiling it as a module seems to work fine. When I do so, no > > > > regression is > > > > obvious from what gets reported in "dmesg". However, somehow I now do > > > > get > > > > some output: The last message I see is > > > > > > > > [drm] nouveau :01:00.0: allocated 1680x1050, fb 0x40 b0 > > > pointer value> > > > > > > > > Then, nothing more. However, it really is quite strange why this error > > > > only > > > > appears in the CONFIG_NOUVEAU=y case, not in the =m case... > > > Try disabling CONFIG_BOOT_LOGO. I reported on freedesktop.org that it is > > > causing me an oops at boot, but my bug has been ignored there so far - > > > perhaps I should have posted it here instead. > > > > I'm getting the exact same symptoms on my Atom + ION hardware. Crashes > > before it > > can write any logs if it's compiled in and the logo is selected, but boots > > fine > > if compiled as a module or the logo is removed. > > > > In my case I bisected and found 8969960 by Nick Piggin (change to > > mm/vmalloc.c) > > to be the first bad one in 2.6.38+. This makes me think that it's not a bug > > in > > nouveau, but maybe a bug in the order that things are initialized? > > FWIW, reverting commit 89699605fe7cfd8611900346f61cb6cbf179b10a on 2.6.39-rc3+ > makes my system boot just fine with the nouveau drivers compiled into the > kernel. I've seen some similar looking bugs on LKML that this regression may > or > may not be related to? It works fine on 2.6.38. > > https://bugzilla.kernel.org/show_bug.cgi?id=33272 > http://lkml.org/lkml/2011/4/15/194 > > I'm still trying to figure out exactly where the kernel is crashing after > printing > [drm] nouveau :03:00.0: allocated 1280x1024 fb: 0x4000, b0 f4cf7600 > > Any thoughts on what else I should look for? I reproduced this bug today, and reverting 89699605fe7cfd8611900346f61cb6cbf179b10a does not fix it for me. Here's the backtrace: Entering kdb (current=0x8801becb, pid 1) on processor 6 Oops: (null) due to oops @ 0x81255081 CPU 6 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.39-rc2-nv+ #640 System manufacturer System Product Name/P6T SE RIP: 0010:[] [] iowrite32+0x12/0x34 RSP: :8801becab4b0 EFLAGS: 00010296 RAX: RBX: 8801bd334800 RCX: 16fc RDX: RSI: c900100bbf4c RDI: c900100bbf4c RBP: 8801becab4b0 R08: 0002 R09: 0001 R10: 00bb R11: 8801becab540 R12: 8801bd336000 R13: 8801bd334818 R14: 8801bd60 R15: 0020 FS: () GS:8801bfd8() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: c900100bbf4c CR3: 01a2b000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process swapper (pid: 1, threadinfo 8801b
Re: [PATCH] drm: Recover DPMS properly after XRandr re-enablement
On Wed, 22 Dec 2010 12:53:07 + Chris Wilson wrote: > On Wed, 22 Dec 2010 12:42:32 +, Chris Wilson > wrote: > > From: Takashi Iwai > > > This patch adds a new helper function to manage the drm_connector > > DPMS so that it can be called commonly in both places. > > > > Signed-off-by: Takashi Iwai > > FWIW, > > Reviewed-by: Chris Wilson > > -Chris > Is this patch still necessary for 2.6.39? It was needed to fix a regression from 2.6.36 (at least in February). ( https://bugzilla.kernel.org/show_bug.cgi?id=24982 ) Regards, Flo ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33392] suspend/resume stopped working
https://bugzilla.kernel.org/show_bug.cgi?id=33392 Maciej Rutecki changed: What|Removed |Added Blocks||32012, 7216 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33392] New: suspend/resume stopped working
https://bugzilla.kernel.org/show_bug.cgi?id=33392 Summary: suspend/resume stopped working Product: Drivers Version: 2.5 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: maciej.rute...@gmail.com CC: r...@sisk.pl, maciej.rute...@gmail.com, sergey.senozhat...@gmail.com Regression: Yes Subject: suspend/resume stopped working Submitter : Sergey Senozhatsky Date : 2011-04-11 21:02 Message-ID : 20110411210228.GB4227@swordfish References : http://marc.info/?l=linux-kernel&m=130255574912234&w=2 This entry is being used for tracking a regression from 2.6.38. Please don't close it until the problem is fixed in the mainline. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 2.6.39-rc1 nouveau regression (bisected)
On Sun, Apr 17, 2011 at 12:24:27PM -0400, Kyle Spaans wrote: > On Sun, Apr 17, 2011 at 05:45:57PM +0200, Marcin Slusarz wrote: > > On Sun, Apr 17, 2011 at 11:12:04AM -0400, Kyle Spaans wrote: > > > On Sat, Apr 16, 2011 at 07:50:28PM -0400, Kyle Spaans wrote: > > > > On Sun, Apr 17, 2011 at 08:12:35AM +1000, Nigel Cunningham wrote: > > > > > On 15/04/11 16:11, Dominik Brodowski wrote: > > > > > > On Thu, Apr 14, 2011 at 09:02:01PM +0200, Marcin Slusarz wrote: > > > > > >> On Thu, Apr 14, 2011 at 07:05:59PM +0200, Dominik Brodowski wrote: > > > > > >>> Thought about CCing Linus to show him that 2.6.39-rcX isn't as > > > > > >>> "calm" > > > > > >>> to everyone, but then chose to CC Maciej instead: Would you be so > > > > > >>> kind and > > > > > >>> add this to your regression list? Thanks! > > > > > >>> > > > > > >>> Since commit 38f1cff > > > > > >>> > > > > > >>> From: Dave Airlie > > > > > >>> Date: Wed, 16 Mar 2011 11:34:41 +1000 > > > > > >>> Subject: [PATCH] Merge commit > > > > > >>> '5359533801e3dd3abca5b7d3d985b0b33fd9fe8b' into dr > > > > > >>> > > > > > >>> This commit changed an internal radeon structure, that meant > > > > > >>> a new driver > > > > > >>> in -next had to be fixed up, merge in the commit and fix up > > > > > >>> the driver. > > > > > >>> > > > > > >>> Also fixes a trivial nouveau merge. > > > > > >>> > > > > > >>> Conflicts: > > > > > >>> drivers/gpu/drm/nouveau/nouveau_mem.c > > > > > >>> > > > > > >>> booting my atom/NM10/ION2 system crashes hard during boot, right > > > > > >>> after > > > > > >>> blanking the screen, and before the initramfs gets loaded. I just > > > > > >>> re-checked: both parent commits ( 5359533 and 4819d2e ) do indeed > > > > > >>> work > > > > > >>> just fine, but the merge commit ( 38f1cff ) fails, same as tip ( > > > > > >>> 85f2e68 ). > > > > > >> Can you activate netconsole and check whether kernel spits > > > > > >> anything interesting? > > > > > >> You might try to load nouveau module after boot - maybe something > > > > > >> will be saved > > > > > >> to /var/log or you could even ssh into the box and check dmesg... > > > > > > Compiling it as a module seems to work fine. When I do so, no > > > > > > regression is > > > > > > obvious from what gets reported in "dmesg". However, somehow I now > > > > > > do get > > > > > > some output: The last message I see is > > > > > > > > > > > > [drm] nouveau :01:00.0: allocated 1680x1050, fb 0x40 b0 > > > > > > > > > > > > > > > > > > Then, nothing more. However, it really is quite strange why this > > > > > > error only > > > > > > appears in the CONFIG_NOUVEAU=y case, not in the =m case... > > > > > Try disabling CONFIG_BOOT_LOGO. I reported on freedesktop.org that it > > > > > is > > > > > causing me an oops at boot, but my bug has been ignored there so far - > > > > > perhaps I should have posted it here instead. > > > > > > > > I'm getting the exact same symptoms on my Atom + ION hardware. Crashes > > > > before it > > > > can write any logs if it's compiled in and the logo is selected, but > > > > boots fine > > > > if compiled as a module or the logo is removed. > > > > > > > > In my case I bisected and found 8969960 by Nick Piggin (change to > > > > mm/vmalloc.c) > > > > to be the first bad one in 2.6.38+. This makes me think that it's not a > > > > bug in > > > > nouveau, but maybe a bug in the order that things are initialized? > > > > > > FWIW, reverting commit 89699605fe7cfd8611900346f61cb6cbf179b10a on > > > 2.6.39-rc3+ > > > makes my system boot just fine with the nouveau drivers compiled into the > > > kernel. I've seen some similar looking bugs on LKML that this regression > > > may or > > > may not be related to? It works fine on 2.6.38. > > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=33272 > > > http://lkml.org/lkml/2011/4/15/194 > > > > > > I'm still trying to figure out exactly where the kernel is crashing after > > > printing > > > [drm] nouveau :03:00.0: allocated 1280x1024 fb: 0x4000, b0 > > > f4cf7600 > > > > > > Any thoughts on what else I should look for? > > > > I reproduced this bug today, and reverting > > 89699605fe7cfd8611900346f61cb6cbf179b10a > > does not fix it for me. Here's the backtrace: > > > > Entering kdb (current=0x8801becb, pid 1) on processor 6 Oops: (null) > > due to oops @ 0x81255081 > > CPU 6 Modules linked in: > > > > Pid: 1, comm: swapper Not tainted 2.6.39-rc2-nv+ #640 System > > manufacturer System Product Name/P6T SE > > RIP: 0010:[] [] iowrite32+0x12/0x34 > > RSP: :8801becab4b0 EFLAGS: 00010296 > > RAX: RBX: 8801bd334800 RCX: 16fc > > RDX: RSI: c900100bbf4c RDI: c900100bbf4c > > RBP: 8801becab4b0 R08: 0002 R09: 0001 > > R10: 00bb R11: 8801becab540 R12: 8801bd336000 > > R13: 8801bd334818 R14: 8801bd60 R15: 00
[Bug 36327] fujitsu siemens amilo li1718: ati radeon x200m does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=36327 Alex Deucher changed: What|Removed |Added Attachment #45729|text/x-log |text/plain mime type|| Attachment #45729|0 |1 is patch|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36327] fujitsu siemens amilo li1718: ati radeon x200m does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=36327 --- Comment #2 from Alex Deucher 2011-04-17 10:11:28 PDT --- Removing i2c-algo-bit.ko prevents radeon from loading since it depends on it; that's why 3D/compositing fail. Please attach your xorg log and dmesg output both with and without i2c-algo-bit.ko present. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33392] suspend/resume stopped working
https://bugzilla.kernel.org/show_bug.cgi?id=33392 Alex Deucher changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher 2011-04-17 17:13:33 --- Is this a regression? If so, what was the last version that worked and can you bisect? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33422] New: oops in radeon_ddc_get_modes on first boot of rc3
https://bugzilla.kernel.org/show_bug.cgi?id=33422 Summary: oops in radeon_ddc_get_modes on first boot of rc3 Product: Drivers Version: 2.5 Kernel Version: 2.6.39-rc3 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: maciej.rute...@gmail.com CC: r...@sisk.pl, maciej.rute...@gmail.com Regression: Yes Subject: oops in radeon_ddc_get_modes on first boot of rc3 Submitter : Steve French Date : 2011-04-12 17:54 Message-ID : banlktiktvuv9eh4gilds0dewgjxo_3d...@mail.gmail.com References : http://marc.info/?l=linux-kernel&m=130263086322702&w=2 This entry is being used for tracking a regression from 2.6.38. Please don't close it until the problem is fixed in the mainline. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33422] oops in radeon_ddc_get_modes on first boot of rc3
https://bugzilla.kernel.org/show_bug.cgi?id=33422 Maciej Rutecki changed: What|Removed |Added Blocks||32012 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 2.6.39-rc1 nouveau regression (bisected)
Hey, On Sun, Apr 17, 2011 at 08:12:35AM +1000, Nigel Cunningham wrote: > On 15/04/11 16:11, Dominik Brodowski wrote: > > On Thu, Apr 14, 2011 at 09:02:01PM +0200, Marcin Slusarz wrote: > >> On Thu, Apr 14, 2011 at 07:05:59PM +0200, Dominik Brodowski wrote: > >>> Thought about CCing Linus to show him that 2.6.39-rcX isn't as "calm" > >>> to everyone, but then chose to CC Maciej instead: Would you be so kind and > >>> add this to your regression list? Thanks! > >>> > >>> Since commit 38f1cff > >>> > >>> From: Dave Airlie > >>> Date: Wed, 16 Mar 2011 11:34:41 +1000 > >>> Subject: [PATCH] Merge commit > >>> '5359533801e3dd3abca5b7d3d985b0b33fd9fe8b' into dr > >>> > >>> This commit changed an internal radeon structure, that meant a new > >>> driver > >>> in -next had to be fixed up, merge in the commit and fix up the > >>> driver. > >>> > >>> Also fixes a trivial nouveau merge. > >>> > >>> Conflicts: > >>> drivers/gpu/drm/nouveau/nouveau_mem.c > >>> > >>> booting my atom/NM10/ION2 system crashes hard during boot, right after > >>> blanking the screen, and before the initramfs gets loaded. I just > >>> re-checked: both parent commits ( 5359533 and 4819d2e ) do indeed work > >>> just fine, but the merge commit ( 38f1cff ) fails, same as tip ( 85f2e68 > >>> ). > >> Can you activate netconsole and check whether kernel spits anything > >> interesting? > >> You might try to load nouveau module after boot - maybe something will be > >> saved > >> to /var/log or you could even ssh into the box and check dmesg... > > Compiling it as a module seems to work fine. When I do so, no regression is > > obvious from what gets reported in "dmesg". However, somehow I now do get > > some output: The last message I see is > > > > [drm] nouveau :01:00.0: allocated 1680x1050, fb 0x40 b0 > pointer value> > > > > Then, nothing more. However, it really is quite strange why this error only > > appears in the CONFIG_NOUVEAU=y case, not in the =m case... > Try disabling CONFIG_BOOT_LOGO. I reported on freedesktop.org that it is > causing me an oops at boot, but my bug has been ignored there so far - > perhaps I should have posted it here instead. indeed, setting CONFIG_LOGO=n makes it boot. Same as compiling nouveau as a module. With all the different bisect results and reverts which make it work, it seems to me to be a timing / interference issue... Best, Dominik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33392] suspend/resume stopped working
https://bugzilla.kernel.org/show_bug.cgi?id=33392 --- Comment #2 from Sergey Senozhatsky 2011-04-17 17:35:22 --- > --- Comment #1 from Alex Deucher 2011-04-17 17:13:33 > --- > Is this a regression? If so, what was the last version that worked and can > you > bisect? > Hello, I'll try to bisect. It'll take some time. Sergey -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36327] fujitsu siemens amilo li1718: ati radeon x200m does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=36327 --- Comment #3 from Karesz L. 2011-04-17 10:37:35 PDT --- Created an attachment (id=45733) --> (https://bugs.freedesktop.org/attachment.cgi?id=45733) Dmesg - i2c_algo_bit loaded -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36327] fujitsu siemens amilo li1718: ati radeon x200m does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=36327 --- Comment #4 from Karesz L. 2011-04-17 10:39:02 PDT --- Created an attachment (id=45734) --> (https://bugs.freedesktop.org/attachment.cgi?id=45734) Dmesg - i2c_algo_bit NOT loaded, before suspending -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36327] fujitsu siemens amilo li1718: ati radeon x200m does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=36327 --- Comment #5 from Karesz L. 2011-04-17 10:39:52 PDT --- Created an attachment (id=45735) --> (https://bugs.freedesktop.org/attachment.cgi?id=45735) Dmesg - i2c_algo_bit NOT loaded, after a succesful resume -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36327] fujitsu siemens amilo li1718: ati radeon x200m does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=36327 --- Comment #6 from Karesz L. 2011-04-17 10:42:19 PDT --- Created an attachment (id=45736) --> (https://bugs.freedesktop.org/attachment.cgi?id=45736) Xorg.0.log - i2c_algo_bit NOT loaded -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36327] fujitsu siemens amilo li1718: ati radeon x200m does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=36327 --- Comment #7 from Karesz L. 2011-04-17 10:46:19 PDT --- Created an attachment (id=45737) --> (https://bugs.freedesktop.org/attachment.cgi?id=45737) Lsmod - i2c present -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36327] fujitsu siemens amilo li1718: ati radeon x200m does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=36327 --- Comment #8 from Karesz L. 2011-04-17 10:47:06 PDT --- Created an attachment (id=45738) --> (https://bugs.freedesktop.org/attachment.cgi?id=45738) lsmod - i2c NOT present -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33392] suspend/resume stopped working
https://bugzilla.kernel.org/show_bug.cgi?id=33392 Rafael J. Wysocki changed: What|Removed |Added Kernel Version||2.6.39-rc --- Comment #3 from Rafael J. Wysocki 2011-04-17 18:08:49 --- Also please try the current Linus' tree in case the underlying bug has been fixed already. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32982] Kernel locks up a few minutes after boot
https://bugzilla.kernel.org/show_bug.cgi?id=32982 --- Comment #9 from Rafael J. Wysocki 2011-04-17 18:20:39 --- On Sunday, April 17, 2011, Linus Torvalds wrote: > Is this machine running a RAID5 setup or something like that? > > There is a known interaction with the new block layer plugging code > and MD. The "hung task" report in that bugzilla looks very much like > that issue. And you do have "root=/dev/md0", so clearly there's some > md thing going on. > > And bisecting might not work all that well for it, because I suspect > it ends up being very much a matter of IO patterns how it triggers. > > Neil supposedly has a patch for it, but I haven't seen it yet. Neil, Jens? > >Linus -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Problems caused by commit 6803ed69994a14824081adbf1b58fd21a9966215 to 2.6.38-rc5
Good day, night, or whatever, The above mentioned commit which changed the flags passed to nouveau_gem_new to domain creates a problem in nouveau_notifier_init_channel (in nouveau_notifier.c) when it calls nouveau_bo_pin with the domain flags. That function seems to want TTM_PL_FLAGs. If this problem is not fixed, notifier allocation during channel allocation goes awry the kernel thinks that the gpu is locked up and switches to software fbcon, and X is gone. The solution is obvious. However, I am not clear on what the original purpose of the patch was nor why the TTM placement flags and the NOUVEAU placement flags are reversed for GART and VRAM. I'm not saying there isn't a good reason, I just don't know what it is. The choices are: 1. Revert the patch 2. Add code to nouveau_notifier_init_channel to pass the TTM_PL_FLAGS to nouveau_bo_pin. 3. Change nouveau_bo_pin so that it accepts the nouveau domain flags, and fix every place that nouveau_bo_pin is called (not all that many) to give it the flags it will then expect. 4. None of the above Maybe this is only a problem with earlier cards. I have a 6800 Ultra. It's hard to believe that no one else noticed it for a month as it's pretty difficult to ignore. Best Wishes, Bob Gleitsmann ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33512] New: radeon: lots of time spent in atombios_crtc_disable
https://bugzilla.kernel.org/show_bug.cgi?id=33512 Summary: radeon: lots of time spent in atombios_crtc_disable Product: Drivers Version: 2.5 Kernel Version: 2.6.39-rc3 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: edwinto...@gmail.com Regression: No Created an attachment (id=54532) --> (https://bugzilla.kernel.org/attachment.cgi?id=54532) dmesg On a mostly idle system this is what I see with perf top (after exiting a game): --- PerfTop: 386 irqs/sec kernel:72.8% exact: 0.0% [1000Hz cycles], (all, 6 CPUs) --- samples pcnt function DSO ___ _ __ 171.00 18.0% atombios_crtc_disable /lib/modules/2.6.39-rc3-phenom-00117-ge38f5b7/kernel/drivers/gpu/drm/radeon/radeon.ko 47.00 4.9% find_next_bit [kernel.kallsyms] 31.00 3.3% format_decode [kernel.kallsyms] When playing a game that function is still on top, albeit with a lower percentage (7.5%). If the function does what its name says then it should be called at most once, when switching modes, entering standby, etc. I don't see why it is being called during normal operation, and why is it called so many times that it makes it the top function using the CPU... The graphics in games is quite laggy too, maybe because of this... My dmesg is attached. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33512] radeon: lots of time spent in atombios_crtc_disable
https://bugzilla.kernel.org/show_bug.cgi?id=33512 --- Comment #1 from Török Edwin 2011-04-17 20:45:53 --- Created an attachment (id=54542) --> (https://bugzilla.kernel.org/attachment.cgi?id=54542) Xorg.0.log Xorg log attached too -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fix mesa tarball creation again
Pushed, thanks. Marek On Sat, Apr 16, 2011 at 10:11 AM, Thierry Vignaud wrote: > Hi > > The following patch fixes mesa tarball creation again > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Problems caused by commit 6803ed69994a14824081adbf1b58fd21a9966215 to 2.6.38-rc5
On Sun, 2011-04-17 at 15:40 -0400, Bob Gleitsmann wrote: > Good day, night, or whatever, Hey, I've pushed a fix for this (solution 2 that you mentioned) to nouveau's git tree. I'll get it to Dave with the next batch of fixes for .39-rc. Ben. > > The above mentioned commit which changed the flags passed to nouveau_gem_new > to > domain creates a problem in nouveau_notifier_init_channel (in > nouveau_notifier.c) when it calls nouveau_bo_pin with the domain flags. That > function seems to want TTM_PL_FLAGs. If this problem is not fixed, notifier > allocation during channel allocation goes awry the kernel thinks that the gpu > is locked up and switches to software fbcon, and X is gone. The solution is > obvious. However, I am not clear on what the original purpose of the patch > was > nor why the TTM placement flags and the NOUVEAU placement flags are reversed > for > GART and VRAM. I'm not saying there isn't a good reason, I just don't know > what it is. The choices are: > 1. Revert the patch > 2. Add code to nouveau_notifier_init_channel to pass the TTM_PL_FLAGS to > nouveau_bo_pin. > 3. Change nouveau_bo_pin so that it accepts the nouveau domain flags, and fix > every place that nouveau_bo_pin is called (not all that many) to give it the > flags it will then expect. > 4. None of the above > > Maybe this is only a problem with earlier cards. I have a 6800 Ultra. It's > hard to believe that no one else noticed it for a month as it's pretty > difficult > to ignore. > > Best Wishes, > > Bob Gleitsmann > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33542] New: radeon: Don't read BIOS in VRAM on SPARC64
https://bugzilla.kernel.org/show_bug.cgi?id=33542
Summary: radeon: Don't read BIOS in VRAM on SPARC64
Product: Drivers
Version: 2.5
Kernel Version: 2.6.39-rc3
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Video(DRI - non Intel)
AssignedTo: drivers_video-...@kernel-bugs.osdl.org
ReportedBy: detri...@gmail.com
Regression: No
Created an attachment (id=54572)
--> (https://bugzilla.kernel.org/attachment.cgi?id=54572)
DRM and Radeon dmesg block containing kernel panic.
Hi!
Hurray! Radeon KMS works again on SPARC64! Almost.
Test platform is a Sun Ultra 45. Test board is a Sun XVR-300 (RV380
0x1002:0x5B64) on a PCI-e bus.
There's a kernel panic when calling igp_read_bios_from_vram() from
radeon_get_bios(). See attached dmesg capture.
Patching around it with
--- a/drivers/gpu/drm/radeon/radeon_bios.c 2011-04-17 19:31:04.0
-0500
+++ b/drivers/gpu/drm/radeon/radeon_bios.c 2010-09-28 20:01:22.0
-0500
@@ -432,8 +432,10 @@
uint16_t tmp;
r = radeon_atrm_get_bios(rdev);
+#if !defined(__sparc__)
if (r == false)
r = igp_read_bios_from_vram(rdev);
+#endif /* !__sparc__ */
if (r == false)
r = radeon_read_bios(rdev);
if (r == false) {
gives me a framebuffer console again. After which, the usual desktop stack
works as well (X11, mesa, textured video).
I'm not sure this is the correct way to code the fix, stylistically speaking.
Although I don't know of any sparc64 machines sporting a Radeon IGP, I'm sure
it could happen someday. It also seems other architectures might run into this
as well.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
--
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36332] New: Missing rendering in Unity dash
https://bugs.freedesktop.org/show_bug.cgi?id=36332 Summary: Missing rendering in Unity dash Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: chalserog...@gmail.com Forwarded from https://bugs.launchpad.net/ubuntu/+source/unity/+bug/726033 When rendering the Unity dash icons are frequently missing from the rendering. This video is a good demonstration of the problem: https://launchpadlibrarian.net/68813544/unity-bug.ogv This works on r600g, nouveau, i915 and i965, so it looks like it's a bug somewhere in r300g. The dash rendering uses FBOs and ARB shaders, with glscissor for clipping. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36332] Missing rendering in Unity dash
https://bugs.freedesktop.org/show_bug.cgi?id=36332 --- Comment #1 from Jay Taoko 2011-04-17 18:10:21 PDT --- Created an attachment (id=45747) --> (https://bugs.freedesktop.org/attachment.cgi?id=45747) Xorg.0.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36332] Missing rendering in Unity dash
https://bugs.freedesktop.org/show_bug.cgi?id=36332 --- Comment #2 from Jay Taoko 2011-04-17 18:11:05 PDT --- Created an attachment (id=45748) --> (https://bugs.freedesktop.org/attachment.cgi?id=45748) dmesg.txt -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36332] Missing rendering in Unity dash
https://bugs.freedesktop.org/show_bug.cgi?id=36332 --- Comment #3 from Jay Taoko 2011-04-17 18:11:41 PDT --- Created an attachment (id=45749) --> (https://bugs.freedesktop.org/attachment.cgi?id=45749) glxinfo.txt -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.39-rc3
On Sun, Apr 17, 2011 at 10:09 AM, Joerg Roedel wrote: > On Sat, Apr 16, 2011 at 02:54:04PM -0400, Jerome Glisse wrote: > >> If you want to go the printk way you can add printk before each test >> ring_test, ib_test in r600.c this 2 functions are the own that might >> trigger the first GPU gart activities. > > Okay, I found the place in source that triggers this. It happens in the > function r600_ib_test. The interesting thing is that not the ib-command > itself is responsible but the fence that is emitted afterwards (proved > by removing the fence command, where the problem went away). > I don't know enough about the command semantics to make a guess what > goes wrong there. But maybe you GPU folks have an idea? > > Joerg > > I can't think of any theory, at that point the wb, irq ring, cp buffer & ib pool are all allocated and pinned into gtt so they all have valid entry backed by a real page. Maybe the GART flush & update is seriously buggy but i expect we would have been hurt sooner by such things. Maybe there is a bug in the hw... wouldn't be surprised. Will try to think to crazy theory. Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36332] Missing rendering in Unity dash
https://bugs.freedesktop.org/show_bug.cgi?id=36332 --- Comment #4 from Christopher James Halse Rogers 2011-04-17 18:18:27 PDT --- This occurs on both mesa master (as of 2011/04/18, shown in logs) and 7.10.2. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36332] Missing rendering in Unity dash
https://bugs.freedesktop.org/show_bug.cgi?id=36332 --- Comment #5 from Jay Taoko 2011-04-17 18:24:09 PDT --- The bug can be reproduced on ATI R300/400/500 GPUs. These GPUs are no longer supported by fglrx so I couldn't verify if it was strictly a driver issue or if there was some error in our program code. However, the problem cannot be reproduced with a Radeon HD 4670 and the open source driver (or fglrx). Nor can it be reproduced with Intel GPUs such as the GMA 950 and above. The bug manifest itself in the Unity Dash. When an action is performed to show more icons in the dash, the rendering does not happen. Elements of the Dash only appear after the mouse moves over them, but this is the result of Unity refreshing the rendering. Some elements of the dash also disappear. This make me think that clipping could be involved. Unity makes extensive use of opengl scissoring. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: Create and use drm_err
Reduce drm text size ~1% by using drm_err and
printf extension %pV to emit error messages.
Remove unused macro DRM_MEM_ERROR.
$ size drivers/gpu/drm/built-in.o*
textdata bss dec hex filename
3611599663 256 371078 5a986 drivers/gpu/drm/built-in.o.new
3654169663 256 375335 5ba27 drivers/gpu/drm/built-in.o.old
Signed-off-by: Joe Perches
---
drivers/gpu/drm/drm_stub.c | 21 +
include/drm/drmP.h | 21 +++--
2 files changed, 28 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 001273d..6d7b083 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -62,6 +62,26 @@ struct idr drm_minors_idr;
struct class *drm_class;
struct proc_dir_entry *drm_proc_root;
struct dentry *drm_debugfs_root;
+
+int drm_err(const char *func, const char *format, ...)
+{
+ struct va_format vaf;
+ va_list args;
+ int r;
+
+ va_start(args, format);
+
+ vaf.fmt = format;
+ vaf.va = &args;
+
+ r = printk(KERN_ERR "[" DRM_NAME ":%s] *ERROR* %pV", func, &vaf);
+
+ va_end(args);
+
+ return r;
+}
+EXPORT_SYMBOL(drm_err);
+
void drm_ut_debug_printk(unsigned int request_level,
const char *prefix,
const char *function_name,
@@ -78,6 +98,7 @@ void drm_ut_debug_printk(unsigned int request_level,
}
}
EXPORT_SYMBOL(drm_ut_debug_printk);
+
static int drm_minor_get_id(struct drm_device *dev, int type)
{
int new_id;
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 202424d..22db51d 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -126,6 +126,9 @@ extern void drm_ut_debug_printk(unsigned int request_level,
const char *prefix,
const char *function_name,
const char *format, ...);
+extern __attribute__((format (printf, 2, 3)))
+int drm_err(const char *func, const char *format, ...);
+
/***/
/** \name DRM template customization defaults */
/*@{*/
@@ -181,21 +184,11 @@ extern void drm_ut_debug_printk(unsigned int
request_level,
* \param fmt printf() like format string.
* \param arg arguments
*/
-#define DRM_ERROR(fmt, arg...) \
- printk(KERN_ERR "[" DRM_NAME ":%s] *ERROR* " fmt , __func__ , ##arg)
-
-/**
- * Memory error output.
- *
- * \param area memory area where the error occurred.
- * \param fmt printf() like format string.
- * \param arg arguments
- */
-#define DRM_MEM_ERROR(area, fmt, arg...) \
- printk(KERN_ERR "[" DRM_NAME ":%s:%s] *ERROR* " fmt , __func__, \
- drm_mem_stats[area].name , ##arg)
+#define DRM_ERROR(fmt, ...)\
+ drm_err(__func__, fmt, ##__VA_ARGS__)
-#define DRM_INFO(fmt, arg...) printk(KERN_INFO "[" DRM_NAME "] " fmt , ##arg)
+#define DRM_INFO(fmt, ...) \
+ printk(KERN_INFO "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
/**
* Debug output.
--
1.7.4.2.g597a6.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm: Verify debug message arguments
Add __attribute__((format (printf, 4, 5))) to drm_ut_debug_printk
and fix fallout.
Signed-off-by: Joe Perches
---
drivers/gpu/drm/drm_irq.c |9 +
drivers/gpu/drm/i915/intel_bios.c |6 +++---
drivers/gpu/drm/i915/intel_display.c|8
drivers/gpu/drm/radeon/radeon_display.c |5 +++--
include/drm/drmP.h |3 ++-
5 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 741457b..62ced75 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -684,10 +684,11 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct
drm_device *dev, int crtc,
*/
*vblank_time = ns_to_timeval(timeval_to_ns(&raw_time) - delta_ns);
- DRM_DEBUG("crtc %d : v %d p(%d,%d)@ %d.%d -> %d.%d [e %d us, %d rep]\n",
- crtc, (int) vbl_status, hpos, vpos, raw_time.tv_sec,
- raw_time.tv_usec, vblank_time->tv_sec, vblank_time->tv_usec,
- (int) duration_ns/1000, i);
+ DRM_DEBUG("crtc %d : v %d p(%d,%d)@ %ld.%ld -> %ld.%ld [e %d us, %d
rep]\n",
+ crtc, (int)vbl_status, hpos, vpos,
+ (long)raw_time.tv_sec, (long)raw_time.tv_usec,
+ (long)vblank_time->tv_sec, (long)vblank_time->tv_usec,
+ (int)duration_ns/1000, i);
vbl_status = DRM_VBLANKTIME_SCANOUTPOS_METHOD;
if (invbl)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index fb5b4d4..927442a 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -214,9 +214,9 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv,
i915_lvds_downclock) {
dev_priv->lvds_downclock_avail = 1;
dev_priv->lvds_downclock = temp_downclock;
- DRM_DEBUG_KMS("LVDS downclock is found in VBT. ",
- "Normal Clock %dKHz, downclock %dKHz\n",
- temp_downclock, panel_fixed_mode->clock);
+ DRM_DEBUG_KMS("LVDS downclock is found in VBT. "
+ "Normal Clock %dKHz, downclock %dKHz\n",
+ temp_downclock, panel_fixed_mode->clock);
}
return;
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 432fc04..63bc2af 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3497,11 +3497,11 @@ static unsigned long intel_calculate_wm(unsigned long
clock_in_khz,
1000;
entries_required = DIV_ROUND_UP(entries_required, wm->cacheline_size);
- DRM_DEBUG_KMS("FIFO entries required for mode: %d\n", entries_required);
+ DRM_DEBUG_KMS("FIFO entries required for mode: %ld\n",
entries_required);
wm_size = fifo_size - (entries_required + wm->guard_size);
- DRM_DEBUG_KMS("FIFO watermark level: %d\n", wm_size);
+ DRM_DEBUG_KMS("FIFO watermark level: %ld\n", wm_size);
/* Don't promote wm_size to unsigned... */
if (wm_size > (long)wm->max_wm)
@@ -3820,13 +3820,13 @@ static bool g4x_check_srwm(struct drm_device *dev,
display_wm, cursor_wm);
if (display_wm > display->max_wm) {
- DRM_DEBUG_KMS("display watermark is too large(%d), disabling\n",
+ DRM_DEBUG_KMS("display watermark is too large(%d/%ld),
disabling\n",
display_wm, display->max_wm);
return false;
}
if (cursor_wm > cursor->max_wm) {
- DRM_DEBUG_KMS("cursor watermark is too large(%d), disabling\n",
+ DRM_DEBUG_KMS("cursor watermark is too large(%d/%ld),
disabling\n",
cursor_wm, cursor->max_wm);
return false;
}
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index bdbab5c..0671934 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -1087,8 +1087,9 @@ void radeon_compute_pll_legacy(struct radeon_pll *pll,
*frac_fb_div_p = best_frac_feedback_div;
*ref_div_p = best_ref_div;
*post_div_p = best_post_div;
- DRM_DEBUG_KMS("%d %d, pll dividers - fb: %d.%d ref: %d, post %d\n",
- freq, best_freq / 1000, best_feedback_div,
best_frac_feedback_div,
+ DRM_DEBUG_KMS("%lld %d, pll dividers - fb: %d.%d ref: %d, post %d\n",
+ (long long)freq,
+ best_freq / 1000, best_feedback_div,
best_frac_feedback_div,
best_ref_div, best_post_div);
}
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 22db51d..4ab866e 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -122,7 +122,8 @@ struct drm_device;
* using the DRM_DEBUG_KMS and DRM_DEBUG.
*/
-exter
[PATCH 0/2] drm: Message logging cleanups
Reduce the text space required and verify debug arguments. Joe Perches (2): drm: Create and use drm_err drm: Verify debug message arguments drivers/gpu/drm/drm_irq.c |9 + drivers/gpu/drm/drm_stub.c | 21 + drivers/gpu/drm/i915/intel_bios.c |6 +++--- drivers/gpu/drm/i915/intel_display.c|8 drivers/gpu/drm/radeon/radeon_display.c |5 +++-- include/drm/drmP.h | 24 +--- 6 files changed, 45 insertions(+), 28 deletions(-) -- 1.7.4.2.g597a6.dirty ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33542] radeon: Don't read BIOS in VRAM on SPARC64
https://bugzilla.kernel.org/show_bug.cgi?id=33542 Jason Detring changed: What|Removed |Added Status|NEW |RESOLVED Resolution||OBSOLETE --- Comment #1 from Jason Detring 2011-04-18 06:47:24 --- Wow, I really messed this report up. I mistakenly copy-and-pasted the wrong kernel version from another Radeon bug I'm toying with. This particular dmesg block and patch was from the drm-2.6 tree, on the master branch (2.6.36-rc6, aka drm-2.6-899611e), which is neither current for the main linux-2.6 tree nor the sundry drm-2.6 staging branches. Oops. The current drm-2.6-e001978 tree seems to bring up a framebuffer console with no patching necessary. There's something wrong with the command processor, so all acceleration is disabled, but that's a topic for another ticket. Closing this ticket, sorry for the noise. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
2.6.39-rc1 nouveau regression (bisected)
Hi. On 15/04/11 16:11, Dominik Brodowski wrote: > On Thu, Apr 14, 2011 at 09:02:01PM +0200, Marcin Slusarz wrote: >> On Thu, Apr 14, 2011 at 07:05:59PM +0200, Dominik Brodowski wrote: >>> Thought about CCing Linus to show him that 2.6.39-rcX isn't as "calm" >>> to everyone, but then chose to CC Maciej instead: Would you be so kind and >>> add this to your regression list? Thanks! >>> >>> Since commit 38f1cff >>> >>> From: Dave Airlie >>> Date: Wed, 16 Mar 2011 11:34:41 +1000 >>> Subject: [PATCH] Merge commit >>> '5359533801e3dd3abca5b7d3d985b0b33fd9fe8b' into dr >>> >>> This commit changed an internal radeon structure, that meant a new >>> driver >>> in -next had to be fixed up, merge in the commit and fix up the driver. >>> >>> Also fixes a trivial nouveau merge. >>> >>> Conflicts: >>> drivers/gpu/drm/nouveau/nouveau_mem.c >>> >>> booting my atom/NM10/ION2 system crashes hard during boot, right after >>> blanking the screen, and before the initramfs gets loaded. I just >>> re-checked: both parent commits ( 5359533 and 4819d2e ) do indeed work >>> just fine, but the merge commit ( 38f1cff ) fails, same as tip ( 85f2e68 ). >> Can you activate netconsole and check whether kernel spits anything >> interesting? >> You might try to load nouveau module after boot - maybe something will be >> saved >> to /var/log or you could even ssh into the box and check dmesg... > Compiling it as a module seems to work fine. When I do so, no regression is > obvious from what gets reported in "dmesg". However, somehow I now do get > some output: The last message I see is > > [drm] nouveau :01:00.0: allocated 1680x1050, fb 0x40 b0 value> > > Then, nothing more. However, it really is quite strange why this error only > appears in the CONFIG_NOUVEAU=y case, not in the =m case... Try disabling CONFIG_BOOT_LOGO. I reported on freedesktop.org that it is causing me an oops at boot, but my bug has been ignored there so far - perhaps I should have posted it here instead. Regards, Nigel
[Bug 36318] r600g segfaults
https://bugs.freedesktop.org/show_bug.cgi?id=36318 --- Comment #2 from Yannick Dirou 2011-04-17 02:28:10 PDT --- I had similar problem (with r300g) , In fact glxgears did not load the right mesa lib despite a good ldconfig -v (added new mesa path 000_mesa.conf) do: ldd /usr/bin/glxgears it should show the path of the lib used by the app if it is wrong and you use natty or another ubuntu a temporary fix is: sudo rm /etc/ld.so.conf.d/GL.conf (symbolic link to original mesa) sudo ldconfig don't know the right fix though -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
2.6.39-rc3-git7: Reported regressions from 2.6.38
This message contains a list of some regressions from 2.6.38, for which there are no fixes in the mainline known to the tracking team. If any of them have been fixed already, please let us know. If you know of any other unresolved regressions from 2.6.38, please let us know either and we'll add them to the list. Also, please let us know if any of the entries below are invalid. Each entry from the list will be sent additionally in an automatic reply to this message with CCs to the people involved in reporting and handling the issue. Listed regressions statistics: Date Total Pending Unresolved 2011-04-17 17 11 10 Unresolved regressions -- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=33342 Subject : [2.6.39-rc2][bisected] Constant DISK_MEDIA_CHANGE_EVENTS from CDROM drive. Submitter : Shaun Ruffell Date: 2011-04-08 20:15 (10 days old) Message-ID : <20110408201513.GA3040 at digium.com> References : http://marc.info/?l=linux-kernel&m=130229371907209&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=33272 Subject : drm related hard-hang Submitter : Peter Teoh Date: 2011-04-14 01:29 (4 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=33242 Subject : Lockdep splat in autofs with 2.6.39-rc2 Submitter : Nick Bowler Date: 2011-04-07 19:44 (11 days old) Message-ID : <20110407194403.GA29404 at elliptictech.com> References : http://marc.info/?l=linux-kernel&m=130220545614682&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=33142 Subject : 2.6.39-rc2 regression: X201s fails to resume b77dcf8460ae57d4eb9fd3633eb4f97b8fb20716 Submitter : Keith Packard Date: 2011-04-06 7:44 (12 days old) Message-ID : References : http://marc.info/?l=linux-kernel&m=130207593728273&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=33102 Subject : File's copied from client->linux server only copy 1st 64K data;rest is lost Submitter : Linda Walsh Date: 2011-04-11 22:12 (7 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=33092 Subject : [regression] 2.6.39-rc1 - Beagleboard usbnet broken Submitter : Mark Jackson Date: 2011-04-04 9:22 (14 days old) First-Bad-Commit: http://git.kernel.org/linus/087809fce28f50098d9c3ef1a6865c722f23afd2 Message-ID : <4D998DC9.3040109 at mimc.co.uk> References : http://marc.info/?l=linux-kernel&m=130191386508831&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=32982 Subject : Kernel locks up a few minutes after boot Submitter : Bart Van Assche Date: 2011-04-10 19:55 (8 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=32902 Subject : 2.6.39-rc1 doesn't boot on thinkpad t61p x86_64 Submitter : Alex Romosan Date: 2011-04-03 19:41 (15 days old) Message-ID : <87k4fbnmw8.fsf at sycorax.lbl.gov> References : http://marc.info/?l=linux-kernel&m=130186054431678&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=32892 Subject : 2.6.39-rc1 data corruption with rtorrent Submitter : Jindrich Makovicka Date: 2011-04-02 20:21 (16 days old) Message-ID : <2011040118.3b5c2fa8 at holly> References : http://marc.info/?l=linux-kernel&m=130177570309226&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=32262 Subject : 2.6.38-git15+ IDE hangs boot Submitter : Pete Clements Date: 2011-03-25 15:38 (24 days old) Message-ID : <201103251538.p2PFc11i001674 at clem.clem-digital.net> References : http://marc.info/?l=linux-kernel&m=130106749313695&w=2 Regressions with patches Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=33252 Subject : [regression 2.6.39-rc2][bisected] "perf, x86: P4 PMU - Read proper MSR register to catch" and NMIs Submitter : Shaun Ruffell Date: 2011-04-06 22:30 (12 days old) First-Bad-Commit: http://git.kernel.org/linus/242214f9c1eeaae40eca11e3b4d37bfce960a7cd Message-ID : <20110406223036.GA15721 at digium.com> References : http://marc.info/?l=linux-kernel&m=130212907032580&w=2 Handled-By : Don Zickus Patch : http://cache.gmane.org//gmane/linux/kernel/1125621-001.bin For details, please visit the bug entries and follow the links given in references. As you can see, there is a Bugzilla entry for each of the listed regressions. There also is a Bugzilla entry used for tracking the regressions from 2.6.38, unresolved as well as resolved, at: http://bugzilla.kernel.org/show_bug.cgi?id=32012 Please let the tracking team know if there are any Bugzilla entries that should be added to the list in ther
2.6.36-rc3-git7: Reported regressions 2.6.37 -> 2.6.38
This message contains a list of some post-2.6.37 regressions introduced before 2.6.38, for which there are no fixes in the mainline known to the tracking team. If any of them have been fixed already, please let us know. If you know of any other unresolved post-2.6.37 regressions, please let us know either and we'll add them to the list. Also, please let us know if any of the entries below are invalid. Each entry from the list will be sent additionally in an automatic reply to this message with CCs to the people involved in reporting and handling the issue. Listed regressions statistics: Date Total Pending Unresolved 2011-04-17 98 28 28 2011-03-27 88 26 26 2011-03-06 70 27 26 2011-02-21 51 18 17 2011-02-12 39 20 18 2011-02-03 19 11 7 Unresolved regressions -- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=32862 Subject : acer_wmi partially crashes ACPI/EC (Aspire 8930G) Submitter : Hector Martin Date: 2011-04-07 17:44 (11 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=32762 Subject : Booting with external monitor attached results in red flickering screen on the external monitor Submitter : Anton Date: 2011-04-06 04:50 (12 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=32202 Subject : 2.6.38 hangs on boot until key is pressed Submitter : Tvrtko Ursulin Date: 2011-03-27 19:18 (22 days old) Message-ID : <1301253485.2500.2.camel at deuteros> References : http://marc.info/?l=linux-kernel&m=13012546558&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=32112 Subject : Writes to USB flash drives are extremely slow in 2.6.38 Submitter : Delan Azabani Date: 2011-03-29 08:10 (20 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=32072 Subject : 2.6.38 Regression: Nvidia GeForce8400 + i915 = Crash on Boot Submitter : simon at mungewell.org Date: 2011-03-24 15:20 (25 days old) Message-ID : References : http://marc.info/?l=linux-kernel&m=130100955926434&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=31982 Subject : XFS memory allocation deadlock in 2.6.38 Submitter : Sean Noonan Date: 2011-03-21 16:19 (28 days old) Message-ID : <081DDE43F61F3D43929A181B477DCA95639B52FD at MSXAOA6.twosigma.com> References : http://marc.info/?l=linux-kernel&m=130072585111310&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=31922 Subject : ath5k: Decreased throughput in IBSS or 802.11n mode Submitter : Jeff Cook Date: 2011-03-26 20:06 (23 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=31872 Subject : boot panic unless acpi=off, Thread overran stack, or stack corrupted - Toshiba Satellite/mobile P4 Submitter : Pascal Dormeau Date: 2011-03-25 20:17 (24 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=31782 Subject : nouveau: lockdep spew Submitter : Johannes Berg Date: 2011-03-24 09:51 (25 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=31702 Subject : ath5k phy2: failed to wakeup the MAC Chip Submitter : Justin P. Mattock Date: 2011-03-22 19:15 (27 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=31572 Subject : BUG in vb_alloc() - firewire crash at boot Submitter : Pavel Kysilka Date: 2011-03-21 12:40 (28 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=31532 Subject : 2.6.38: Quota over NFS4 Submitter : Adam Lackorzynski Date: 2011-03-17 13:32 (32 days old) Message-ID : <20110317133247.GB6424 at os.inf.tu-dresden.de> References : http://marc.info/?l=linux-kernel&m=130036878203485&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=31452 Subject : ath9k: throughput issue in 802.11n and also IBSS mode Submitter : Richard Sch?tz Date: 2011-03-19 19:06 (30 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=31402 Subject : Diminished brightness at startup Submitter : Guilherme Salazar Date: 2011-03-18 16:29 (31 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=31322 Subject : 2.6.38-rc echo 3 > /proc/sys/vm/drop_caches repairs mplayer distortions Submitter : Hans de Bruin Date: 2011-03-14 21:34 (35 days old) Message-ID : <4D7E89E7.3080505 at xmsnet.nl> References : http://marc.info/?l=linux-kernel&m=130014181919827&w=2 Bug-Entry : http://bugzi
Linux 2.6.39-rc3
On Sat, Apr 16, 2011 at 02:54:04PM -0400, Jerome Glisse wrote: > If you want to go the printk way you can add printk before each test > ring_test, ib_test in r600.c this 2 functions are the own that might > trigger the first GPU gart activities. Okay, I found the place in source that triggers this. It happens in the function r600_ib_test. The interesting thing is that not the ib-command itself is responsible but the fence that is emitted afterwards (proved by removing the fence command, where the problem went away). I don't know enough about the command semantics to make a guess what goes wrong there. But maybe you GPU folks have an idea? Joerg
[Bug 31782] nouveau: lockdep spew
https://bugzilla.kernel.org/show_bug.cgi?id=31782 --- Comment #6 from Lucas Stach 2011-04-17 14:15:07 --- Created an attachment (id=54522) --> (https://bugzilla.kernel.org/attachment.cgi?id=54522) fix in nouveau tree Could you please try the attached patch? It is already in nouveau tree and should hopefully fix the issue. Just want to make sure if we can close this bug. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 36327] New: fujitsu siemens amilo li1718: ati radeon x200m does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=36327 Summary: fujitsu siemens amilo li1718: ati radeon x200m does not resume from suspend Product: DRI Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: lengyel.karesz at gmail.com Created an attachment (id=45728) --> (https://bugs.freedesktop.org/attachment.cgi?id=45728) lspci -v When trying to resume from suspend, the computer freezes totally, after a second or so. Nothing can be found in the logs, because loging doesn't even start until then. Resuming from hibernation works fine. I've realised, that if i delete the i2c-algo-bit.ko file (therefore preventing it from being loaded) the resume/suspend will work fine, but there is no compositing, sadly. Using "nomodeset", and trying resume from suspend failed. It is an RC415ME chip (it is written on it). This bug was also submitted a long time ago here: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/577340/ -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36327] fujitsu siemens amilo li1718: ati radeon x200m does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=36327 --- Comment #1 from Karesz L. 2011-04-17 07:26:09 PDT --- Created an attachment (id=45729) --> (https://bugs.freedesktop.org/attachment.cgi?id=45729) Xorg.0.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
2.6.39-rc1 nouveau regression (bisected)
On Sun, Apr 17, 2011 at 11:12:04AM -0400, Kyle Spaans wrote: > On Sat, Apr 16, 2011 at 07:50:28PM -0400, Kyle Spaans wrote: > > On Sun, Apr 17, 2011 at 08:12:35AM +1000, Nigel Cunningham wrote: > > > On 15/04/11 16:11, Dominik Brodowski wrote: > > > > On Thu, Apr 14, 2011 at 09:02:01PM +0200, Marcin Slusarz wrote: > > > >> On Thu, Apr 14, 2011 at 07:05:59PM +0200, Dominik Brodowski wrote: > > > >>> Thought about CCing Linus to show him that 2.6.39-rcX isn't as "calm" > > > >>> to everyone, but then chose to CC Maciej instead: Would you be so > > > >>> kind and > > > >>> add this to your regression list? Thanks! > > > >>> > > > >>> Since commit 38f1cff > > > >>> > > > >>> From: Dave Airlie > > > >>> Date: Wed, 16 Mar 2011 11:34:41 +1000 > > > >>> Subject: [PATCH] Merge commit > > > >>> '5359533801e3dd3abca5b7d3d985b0b33fd9fe8b' into dr > > > >>> > > > >>> This commit changed an internal radeon structure, that meant a > > > >>> new driver > > > >>> in -next had to be fixed up, merge in the commit and fix up the > > > >>> driver. > > > >>> > > > >>> Also fixes a trivial nouveau merge. > > > >>> > > > >>> Conflicts: > > > >>> drivers/gpu/drm/nouveau/nouveau_mem.c > > > >>> > > > >>> booting my atom/NM10/ION2 system crashes hard during boot, right after > > > >>> blanking the screen, and before the initramfs gets loaded. I just > > > >>> re-checked: both parent commits ( 5359533 and 4819d2e ) do indeed work > > > >>> just fine, but the merge commit ( 38f1cff ) fails, same as tip ( > > > >>> 85f2e68 ). > > > >> Can you activate netconsole and check whether kernel spits anything > > > >> interesting? > > > >> You might try to load nouveau module after boot - maybe something will > > > >> be saved > > > >> to /var/log or you could even ssh into the box and check dmesg... > > > > Compiling it as a module seems to work fine. When I do so, no > > > > regression is > > > > obvious from what gets reported in "dmesg". However, somehow I now do > > > > get > > > > some output: The last message I see is > > > > > > > > [drm] nouveau :01:00.0: allocated 1680x1050, fb 0x40 b0 > > > pointer value> > > > > > > > > Then, nothing more. However, it really is quite strange why this error > > > > only > > > > appears in the CONFIG_NOUVEAU=y case, not in the =m case... > > > Try disabling CONFIG_BOOT_LOGO. I reported on freedesktop.org that it is > > > causing me an oops at boot, but my bug has been ignored there so far - > > > perhaps I should have posted it here instead. > > > > I'm getting the exact same symptoms on my Atom + ION hardware. Crashes > > before it > > can write any logs if it's compiled in and the logo is selected, but boots > > fine > > if compiled as a module or the logo is removed. > > > > In my case I bisected and found 8969960 by Nick Piggin (change to > > mm/vmalloc.c) > > to be the first bad one in 2.6.38+. This makes me think that it's not a bug > > in > > nouveau, but maybe a bug in the order that things are initialized? > > FWIW, reverting commit 89699605fe7cfd8611900346f61cb6cbf179b10a on 2.6.39-rc3+ > makes my system boot just fine with the nouveau drivers compiled into the > kernel. I've seen some similar looking bugs on LKML that this regression may > or > may not be related to? It works fine on 2.6.38. > > https://bugzilla.kernel.org/show_bug.cgi?id=33272 > http://lkml.org/lkml/2011/4/15/194 > > I'm still trying to figure out exactly where the kernel is crashing after > printing > [drm] nouveau :03:00.0: allocated 1280x1024 fb: 0x4000, b0 f4cf7600 > > Any thoughts on what else I should look for? I reproduced this bug today, and reverting 89699605fe7cfd8611900346f61cb6cbf179b10a does not fix it for me. Here's the backtrace: Entering kdb (current=0x8801becb, pid 1) on processor 6 Oops: (null) due to oops @ 0x81255081 CPU 6 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.39-rc2-nv+ #640 System manufacturer System Product Name/P6T SE RIP: 0010:[] [] iowrite32+0x12/0x34 RSP: :8801becab4b0 EFLAGS: 00010296 RAX: RBX: 8801bd334800 RCX: 16fc RDX: RSI: c900100bbf4c RDI: c900100bbf4c RBP: 8801becab4b0 R08: 0002 R09: 0001 R10: 00bb R11: 8801becab540 R12: 8801bd336000 R13: 8801bd334818 R14: 8801bd60 R15: 0020 FS: () GS:8801bfd8() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: c900100bbf4c CR3: 01a2b000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process swapper (pid: 1, threadinfo 8801becaa000, task 8801becb) <0>Stack: 8801becab4c0 812f5bd5 8801becab4f0 8130f1f8 8801bd336000 c90012a0 8801becab620 8801becab590
[REGRESSION] [2.6.39-rc3] Wrong resolution in framebuffer and X Window
Hi Last known good: 2.6.38 Failing kernel: 2.6.39-rc3 Subsystem: Intel graphics driver. Description: PC should work with 1440x900 resolution. But console (and after) X Window start work with 1024x768. I attach dmesg and Xorg.0.log with drm.debug=14 log_buf_len=16M options: http://unixy.pl/maciek/download/kernel/2.6.39-rc1/zlom/kms/ seems that driver cannot detect resolution higher than 1024x768. Also I boot kernel replace "i915.modeset=1" with "nomodeset" option: http://unixy.pl/maciek/download/kernel/2.6.39-rc1/zlom/nomodeset/ But then X Window fails to start and got message: "(EE) No devices detected." Config for 2.6.39-rc3: http://unixy.pl/maciek/download/kernel/2.6.39-rc1/zlom/config-2.6.39-rc3 Best regards -- Maciej Rutecki http://www.maciek.unixy.pl
[REGRESSION] [2.6.39-rc3] Wrong resolution in framebuffer and X Window
On niedziela, 17 kwietnia 2011 o 18:04:04 Maciej Rutecki wrote: > Hi > > Last known good: 2.6.38 > Failing kernel: 2.6.39-rc3 > Subsystem: Intel graphics driver. > > Description: > PC should work with 1440x900 resolution. But console (and after) X Window > start work with 1024x768. > > I attach dmesg and Xorg.0.log with drm.debug=14 log_buf_len=16M options: > http://unixy.pl/maciek/download/kernel/2.6.39-rc1/zlom/kms/ > > seems that driver cannot detect resolution higher than 1024x768. > > Also I boot kernel replace "i915.modeset=1" with "nomodeset" option: > http://unixy.pl/maciek/download/kernel/2.6.39-rc1/zlom/nomodeset/ > > But then X Window fails to start and got message: "(EE) No devices > detected." > > Config for 2.6.39-rc3: > http://unixy.pl/maciek/download/kernel/2.6.39-rc1/zlom/config-2.6.39-rc3 > > Best regards Forgot: 00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 02) Regards -- Maciej Rutecki http://www.maciek.unixy.pl
[Bug 36318] r600g segfaults
https://bugs.freedesktop.org/show_bug.cgi?id=36318 --- Comment #3 from Alexandre Demers 2011-04-17 09:22:02 PDT --- If ldd confirms you are using the good library, have a look at the following bug: https://bugs.freedesktop.org/show_bug.cgi?id=36282 It may explain the problem. Otherwise, watchout for Natty, things are a real mess because drivers are now installed under the multiarch folder, but the dev files are installed in a different folder. So if you just compiled and installed like you were doing in previous Ubuntu version, you will end up in a dead end. I had to work a bit to figure everything out. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
2.6.39-rc1 nouveau regression (bisected)
[Repost with different Nick Piggin's address.] On Sun, Apr 17, 2011 at 11:12:04AM -0400, Kyle Spaans wrote: > On Sat, Apr 16, 2011 at 07:50:28PM -0400, Kyle Spaans wrote: > > On Sun, Apr 17, 2011 at 08:12:35AM +1000, Nigel Cunningham wrote: > > > On 15/04/11 16:11, Dominik Brodowski wrote: > > > > On Thu, Apr 14, 2011 at 09:02:01PM +0200, Marcin Slusarz wrote: > > > >> On Thu, Apr 14, 2011 at 07:05:59PM +0200, Dominik Brodowski wrote: > > > >>> Thought about CCing Linus to show him that 2.6.39-rcX isn't as "calm" > > > >>> to everyone, but then chose to CC Maciej instead: Would you be so > > > >>> kind and > > > >>> add this to your regression list? Thanks! > > > >>> > > > >>> Since commit 38f1cff > > > >>> > > > >>> From: Dave Airlie > > > >>> Date: Wed, 16 Mar 2011 11:34:41 +1000 > > > >>> Subject: [PATCH] Merge commit > > > >>> '5359533801e3dd3abca5b7d3d985b0b33fd9fe8b' into dr > > > >>> > > > >>> This commit changed an internal radeon structure, that meant a > > > >>> new driver > > > >>> in -next had to be fixed up, merge in the commit and fix up the > > > >>> driver. > > > >>> > > > >>> Also fixes a trivial nouveau merge. > > > >>> > > > >>> Conflicts: > > > >>> drivers/gpu/drm/nouveau/nouveau_mem.c > > > >>> > > > >>> booting my atom/NM10/ION2 system crashes hard during boot, right after > > > >>> blanking the screen, and before the initramfs gets loaded. I just > > > >>> re-checked: both parent commits ( 5359533 and 4819d2e ) do indeed work > > > >>> just fine, but the merge commit ( 38f1cff ) fails, same as tip ( > > > >>> 85f2e68 ). > > > >> Can you activate netconsole and check whether kernel spits anything > > > >> interesting? > > > >> You might try to load nouveau module after boot - maybe something will > > > >> be saved > > > >> to /var/log or you could even ssh into the box and check dmesg... > > > > Compiling it as a module seems to work fine. When I do so, no > > > > regression is > > > > obvious from what gets reported in "dmesg". However, somehow I now do > > > > get > > > > some output: The last message I see is > > > > > > > > [drm] nouveau :01:00.0: allocated 1680x1050, fb 0x40 b0 > > > pointer value> > > > > > > > > Then, nothing more. However, it really is quite strange why this error > > > > only > > > > appears in the CONFIG_NOUVEAU=y case, not in the =m case... > > > Try disabling CONFIG_BOOT_LOGO. I reported on freedesktop.org that it is > > > causing me an oops at boot, but my bug has been ignored there so far - > > > perhaps I should have posted it here instead. > > > > I'm getting the exact same symptoms on my Atom + ION hardware. Crashes > > before it > > can write any logs if it's compiled in and the logo is selected, but boots > > fine > > if compiled as a module or the logo is removed. > > > > In my case I bisected and found 8969960 by Nick Piggin (change to > > mm/vmalloc.c) > > to be the first bad one in 2.6.38+. This makes me think that it's not a bug > > in > > nouveau, but maybe a bug in the order that things are initialized? > > FWIW, reverting commit 89699605fe7cfd8611900346f61cb6cbf179b10a on 2.6.39-rc3+ > makes my system boot just fine with the nouveau drivers compiled into the > kernel. I've seen some similar looking bugs on LKML that this regression may > or > may not be related to? It works fine on 2.6.38. > > https://bugzilla.kernel.org/show_bug.cgi?id=33272 > http://lkml.org/lkml/2011/4/15/194 > > I'm still trying to figure out exactly where the kernel is crashing after > printing > [drm] nouveau :03:00.0: allocated 1280x1024 fb: 0x4000, b0 f4cf7600 > > Any thoughts on what else I should look for? I reproduced this bug today, and reverting 89699605fe7cfd8611900346f61cb6cbf179b10a does not fix it for me. Here's the backtrace: Entering kdb (current=0x8801becb, pid 1) on processor 6 Oops: (null) due to oops @ 0x81255081 CPU 6 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.39-rc2-nv+ #640 System manufacturer System Product Name/P6T SE RIP: 0010:[] [] iowrite32+0x12/0x34 RSP: :8801becab4b0 EFLAGS: 00010296 RAX: RBX: 8801bd334800 RCX: 16fc RDX: RSI: c900100bbf4c RDI: c900100bbf4c RBP: 8801becab4b0 R08: 0002 R09: 0001 R10: 00bb R11: 8801becab540 R12: 8801bd336000 R13: 8801bd334818 R14: 8801bd60 R15: 0020 FS: () GS:8801bfd8() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: c900100bbf4c CR3: 01a2b000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process swapper (pid: 1, threadinfo 8801b
[PATCH] drm: Recover DPMS properly after XRandr re-enablement
On Wed, 22 Dec 2010 12:53:07 + Chris Wilson wrote: > On Wed, 22 Dec 2010 12:42:32 +, Chris Wilson chris-wilson.co.uk> wrote: > > From: Takashi Iwai > > > This patch adds a new helper function to manage the drm_connector > > DPMS so that it can be called commonly in both places. > > > > Signed-off-by: Takashi Iwai > > FWIW, > > Reviewed-by: Chris Wilson > > -Chris > Is this patch still necessary for 2.6.39? It was needed to fix a regression from 2.6.36 (at least in February). ( https://bugzilla.kernel.org/show_bug.cgi?id=24982 ) Regards, Flo
[Bug 33392] suspend/resume stopped working
https://bugzilla.kernel.org/show_bug.cgi?id=33392 Maciej Rutecki changed: What|Removed |Added Blocks||32012, 7216 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 33392] New: suspend/resume stopped working
https://bugzilla.kernel.org/show_bug.cgi?id=33392 Summary: suspend/resume stopped working Product: Drivers Version: 2.5 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri at kernel-bugs.osdl.org ReportedBy: maciej.rutecki at gmail.com CC: rjw at sisk.pl, maciej.rutecki at gmail.com, sergey.senozhatsky at gmail.com Regression: Yes Subject: suspend/resume stopped working Submitter : Sergey Senozhatsky Date : 2011-04-11 21:02 Message-ID : 20110411210228.GB4227 at swordfish References : http://marc.info/?l=linux-kernel&m=130255574912234&w=2 This entry is being used for tracking a regression from 2.6.38. Please don't close it until the problem is fixed in the mainline. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
2.6.39-rc1 nouveau regression (bisected)
On Sun, Apr 17, 2011 at 12:24:27PM -0400, Kyle Spaans wrote: > On Sun, Apr 17, 2011 at 05:45:57PM +0200, Marcin Slusarz wrote: > > On Sun, Apr 17, 2011 at 11:12:04AM -0400, Kyle Spaans wrote: > > > On Sat, Apr 16, 2011 at 07:50:28PM -0400, Kyle Spaans wrote: > > > > On Sun, Apr 17, 2011 at 08:12:35AM +1000, Nigel Cunningham wrote: > > > > > On 15/04/11 16:11, Dominik Brodowski wrote: > > > > > > On Thu, Apr 14, 2011 at 09:02:01PM +0200, Marcin Slusarz wrote: > > > > > >> On Thu, Apr 14, 2011 at 07:05:59PM +0200, Dominik Brodowski wrote: > > > > > >>> Thought about CCing Linus to show him that 2.6.39-rcX isn't as > > > > > >>> "calm" > > > > > >>> to everyone, but then chose to CC Maciej instead: Would you be so > > > > > >>> kind and > > > > > >>> add this to your regression list? Thanks! > > > > > >>> > > > > > >>> Since commit 38f1cff > > > > > >>> > > > > > >>> From: Dave Airlie > > > > > >>> Date: Wed, 16 Mar 2011 11:34:41 +1000 > > > > > >>> Subject: [PATCH] Merge commit > > > > > >>> '5359533801e3dd3abca5b7d3d985b0b33fd9fe8b' into dr > > > > > >>> > > > > > >>> This commit changed an internal radeon structure, that meant > > > > > >>> a new driver > > > > > >>> in -next had to be fixed up, merge in the commit and fix up > > > > > >>> the driver. > > > > > >>> > > > > > >>> Also fixes a trivial nouveau merge. > > > > > >>> > > > > > >>> Conflicts: > > > > > >>> drivers/gpu/drm/nouveau/nouveau_mem.c > > > > > >>> > > > > > >>> booting my atom/NM10/ION2 system crashes hard during boot, right > > > > > >>> after > > > > > >>> blanking the screen, and before the initramfs gets loaded. I just > > > > > >>> re-checked: both parent commits ( 5359533 and 4819d2e ) do indeed > > > > > >>> work > > > > > >>> just fine, but the merge commit ( 38f1cff ) fails, same as tip ( > > > > > >>> 85f2e68 ). > > > > > >> Can you activate netconsole and check whether kernel spits > > > > > >> anything interesting? > > > > > >> You might try to load nouveau module after boot - maybe something > > > > > >> will be saved > > > > > >> to /var/log or you could even ssh into the box and check dmesg... > > > > > > Compiling it as a module seems to work fine. When I do so, no > > > > > > regression is > > > > > > obvious from what gets reported in "dmesg". However, somehow I now > > > > > > do get > > > > > > some output: The last message I see is > > > > > > > > > > > > [drm] nouveau :01:00.0: allocated 1680x1050, fb 0x40 b0 > > > > > > > > > > > > > > > > > > Then, nothing more. However, it really is quite strange why this > > > > > > error only > > > > > > appears in the CONFIG_NOUVEAU=y case, not in the =m case... > > > > > Try disabling CONFIG_BOOT_LOGO. I reported on freedesktop.org that it > > > > > is > > > > > causing me an oops at boot, but my bug has been ignored there so far - > > > > > perhaps I should have posted it here instead. > > > > > > > > I'm getting the exact same symptoms on my Atom + ION hardware. Crashes > > > > before it > > > > can write any logs if it's compiled in and the logo is selected, but > > > > boots fine > > > > if compiled as a module or the logo is removed. > > > > > > > > In my case I bisected and found 8969960 by Nick Piggin (change to > > > > mm/vmalloc.c) > > > > to be the first bad one in 2.6.38+. This makes me think that it's not a > > > > bug in > > > > nouveau, but maybe a bug in the order that things are initialized? > > > > > > FWIW, reverting commit 89699605fe7cfd8611900346f61cb6cbf179b10a on > > > 2.6.39-rc3+ > > > makes my system boot just fine with the nouveau drivers compiled into the > > > kernel. I've seen some similar looking bugs on LKML that this regression > > > may or > > > may not be related to? It works fine on 2.6.38. > > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=33272 > > > http://lkml.org/lkml/2011/4/15/194 > > > > > > I'm still trying to figure out exactly where the kernel is crashing after > > > printing > > > [drm] nouveau :03:00.0: allocated 1280x1024 fb: 0x4000, b0 > > > f4cf7600 > > > > > > Any thoughts on what else I should look for? > > > > I reproduced this bug today, and reverting > > 89699605fe7cfd8611900346f61cb6cbf179b10a > > does not fix it for me. Here's the backtrace: > > > > Entering kdb (current=0x8801becb, pid 1) on processor 6 Oops: (null) > > due to oops @ 0x81255081 > > CPU 6 Modules linked in: > > > > Pid: 1, comm: swapper Not tainted 2.6.39-rc2-nv+ #640 System > > manufacturer System Product Name/P6T SE > > RIP: 0010:[] [] iowrite32+0x12/0x34 > > RSP: :8801becab4b0 EFLAGS: 00010296 > > RAX: RBX: 8801bd334800 RCX: 16fc > > RDX: RSI: c900100bbf4c RDI: c900100bbf4c > > RBP: 8801becab4b0 R08: 0002 R09: 0001 > > R10: 00bb R11: 8801becab540 R12: 8801bd336000 > > R13: 8801bd334818 R14: 8801bd60 R15: 00
[Bug 36327] fujitsu siemens amilo li1718: ati radeon x200m does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=36327 Alex Deucher changed: What|Removed |Added Attachment #45729|text/x-log |text/plain mime type|| Attachment #45729|0 |1 is patch|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36327] fujitsu siemens amilo li1718: ati radeon x200m does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=36327 --- Comment #2 from Alex Deucher 2011-04-17 10:11:28 PDT --- Removing i2c-algo-bit.ko prevents radeon from loading since it depends on it; that's why 3D/compositing fail. Please attach your xorg log and dmesg output both with and without i2c-algo-bit.ko present. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 33392] suspend/resume stopped working
https://bugzilla.kernel.org/show_bug.cgi?id=33392 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1 from Alex Deucher 2011-04-17 17:13:33 --- Is this a regression? If so, what was the last version that worked and can you bisect? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 33422] New: oops in radeon_ddc_get_modes on first boot of rc3
https://bugzilla.kernel.org/show_bug.cgi?id=33422 Summary: oops in radeon_ddc_get_modes on first boot of rc3 Product: Drivers Version: 2.5 Kernel Version: 2.6.39-rc3 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri at kernel-bugs.osdl.org ReportedBy: maciej.rutecki at gmail.com CC: rjw at sisk.pl, maciej.rutecki at gmail.com Regression: Yes Subject: oops in radeon_ddc_get_modes on first boot of rc3 Submitter : Steve French Date : 2011-04-12 17:54 Message-ID : BANLkTikTVuV9eH4GiLDs0DewGJXo_3daeg at mail.gmail.com References : http://marc.info/?l=linux-kernel&m=130263086322702&w=2 This entry is being used for tracking a regression from 2.6.38. Please don't close it until the problem is fixed in the mainline. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 33422] oops in radeon_ddc_get_modes on first boot of rc3
https://bugzilla.kernel.org/show_bug.cgi?id=33422 Maciej Rutecki changed: What|Removed |Added Blocks||32012 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
2.6.39-rc1 nouveau regression (bisected)
Hey, On Sun, Apr 17, 2011 at 08:12:35AM +1000, Nigel Cunningham wrote: > On 15/04/11 16:11, Dominik Brodowski wrote: > > On Thu, Apr 14, 2011 at 09:02:01PM +0200, Marcin Slusarz wrote: > >> On Thu, Apr 14, 2011 at 07:05:59PM +0200, Dominik Brodowski wrote: > >>> Thought about CCing Linus to show him that 2.6.39-rcX isn't as "calm" > >>> to everyone, but then chose to CC Maciej instead: Would you be so kind and > >>> add this to your regression list? Thanks! > >>> > >>> Since commit 38f1cff > >>> > >>> From: Dave Airlie > >>> Date: Wed, 16 Mar 2011 11:34:41 +1000 > >>> Subject: [PATCH] Merge commit > >>> '5359533801e3dd3abca5b7d3d985b0b33fd9fe8b' into dr > >>> > >>> This commit changed an internal radeon structure, that meant a new > >>> driver > >>> in -next had to be fixed up, merge in the commit and fix up the > >>> driver. > >>> > >>> Also fixes a trivial nouveau merge. > >>> > >>> Conflicts: > >>> drivers/gpu/drm/nouveau/nouveau_mem.c > >>> > >>> booting my atom/NM10/ION2 system crashes hard during boot, right after > >>> blanking the screen, and before the initramfs gets loaded. I just > >>> re-checked: both parent commits ( 5359533 and 4819d2e ) do indeed work > >>> just fine, but the merge commit ( 38f1cff ) fails, same as tip ( 85f2e68 > >>> ). > >> Can you activate netconsole and check whether kernel spits anything > >> interesting? > >> You might try to load nouveau module after boot - maybe something will be > >> saved > >> to /var/log or you could even ssh into the box and check dmesg... > > Compiling it as a module seems to work fine. When I do so, no regression is > > obvious from what gets reported in "dmesg". However, somehow I now do get > > some output: The last message I see is > > > > [drm] nouveau :01:00.0: allocated 1680x1050, fb 0x40 b0 > pointer value> > > > > Then, nothing more. However, it really is quite strange why this error only > > appears in the CONFIG_NOUVEAU=y case, not in the =m case... > Try disabling CONFIG_BOOT_LOGO. I reported on freedesktop.org that it is > causing me an oops at boot, but my bug has been ignored there so far - > perhaps I should have posted it here instead. indeed, setting CONFIG_LOGO=n makes it boot. Same as compiling nouveau as a module. With all the different bisect results and reverts which make it work, it seems to me to be a timing / interference issue... Best, Dominik
[Bug 33392] suspend/resume stopped working
https://bugzilla.kernel.org/show_bug.cgi?id=33392 --- Comment #2 from Sergey Senozhatsky 2011-04-17 17:35:22 --- > --- Comment #1 from Alex Deucher 2011-04-17 > 17:13:33 --- > Is this a regression? If so, what was the last version that worked and can > you > bisect? > Hello, I'll try to bisect. It'll take some time. Sergey -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 36327] fujitsu siemens amilo li1718: ati radeon x200m does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=36327 --- Comment #3 from Karesz L. 2011-04-17 10:37:35 PDT --- Created an attachment (id=45733) --> (https://bugs.freedesktop.org/attachment.cgi?id=45733) Dmesg - i2c_algo_bit loaded -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36327] fujitsu siemens amilo li1718: ati radeon x200m does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=36327 --- Comment #4 from Karesz L. 2011-04-17 10:39:02 PDT --- Created an attachment (id=45734) --> (https://bugs.freedesktop.org/attachment.cgi?id=45734) Dmesg - i2c_algo_bit NOT loaded, before suspending -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36327] fujitsu siemens amilo li1718: ati radeon x200m does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=36327 --- Comment #5 from Karesz L. 2011-04-17 10:39:52 PDT --- Created an attachment (id=45735) --> (https://bugs.freedesktop.org/attachment.cgi?id=45735) Dmesg - i2c_algo_bit NOT loaded, after a succesful resume -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36327] fujitsu siemens amilo li1718: ati radeon x200m does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=36327 --- Comment #6 from Karesz L. 2011-04-17 10:42:19 PDT --- Created an attachment (id=45736) --> (https://bugs.freedesktop.org/attachment.cgi?id=45736) Xorg.0.log - i2c_algo_bit NOT loaded -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36327] fujitsu siemens amilo li1718: ati radeon x200m does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=36327 --- Comment #7 from Karesz L. 2011-04-17 10:46:19 PDT --- Created an attachment (id=45737) --> (https://bugs.freedesktop.org/attachment.cgi?id=45737) Lsmod - i2c present -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36327] fujitsu siemens amilo li1718: ati radeon x200m does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=36327 --- Comment #8 from Karesz L. 2011-04-17 10:47:06 PDT --- Created an attachment (id=45738) --> (https://bugs.freedesktop.org/attachment.cgi?id=45738) lsmod - i2c NOT present -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 33392] suspend/resume stopped working
https://bugzilla.kernel.org/show_bug.cgi?id=33392 Rafael J. Wysocki changed: What|Removed |Added Kernel Version||2.6.39-rc --- Comment #3 from Rafael J. Wysocki 2011-04-17 18:08:49 --- Also please try the current Linus' tree in case the underlying bug has been fixed already. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 32982] Kernel locks up a few minutes after boot
https://bugzilla.kernel.org/show_bug.cgi?id=32982 --- Comment #9 from Rafael J. Wysocki 2011-04-17 18:20:39 --- On Sunday, April 17, 2011, Linus Torvalds wrote: > Is this machine running a RAID5 setup or something like that? > > There is a known interaction with the new block layer plugging code > and MD. The "hung task" report in that bugzilla looks very much like > that issue. And you do have "root=/dev/md0", so clearly there's some > md thing going on. > > And bisecting might not work all that well for it, because I suspect > it ends up being very much a matter of IO patterns how it triggers. > > Neil supposedly has a patch for it, but I haven't seen it yet. Neil, Jens? > >Linus -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Problems caused by commit 6803ed69994a14824081adbf1b58fd21a9966215 to 2.6.38-rc5
Good day, night, or whatever, The above mentioned commit which changed the flags passed to nouveau_gem_new to domain creates a problem in nouveau_notifier_init_channel (in nouveau_notifier.c) when it calls nouveau_bo_pin with the domain flags. That function seems to want TTM_PL_FLAGs. If this problem is not fixed, notifier allocation during channel allocation goes awry the kernel thinks that the gpu is locked up and switches to software fbcon, and X is gone. The solution is obvious. However, I am not clear on what the original purpose of the patch was nor why the TTM placement flags and the NOUVEAU placement flags are reversed for GART and VRAM. I'm not saying there isn't a good reason, I just don't know what it is. The choices are: 1. Revert the patch 2. Add code to nouveau_notifier_init_channel to pass the TTM_PL_FLAGS to nouveau_bo_pin. 3. Change nouveau_bo_pin so that it accepts the nouveau domain flags, and fix every place that nouveau_bo_pin is called (not all that many) to give it the flags it will then expect. 4. None of the above Maybe this is only a problem with earlier cards. I have a 6800 Ultra. It's hard to believe that no one else noticed it for a month as it's pretty difficult to ignore. Best Wishes, Bob Gleitsmann
[Bug 33512] New: radeon: lots of time spent in atombios_crtc_disable
https://bugzilla.kernel.org/show_bug.cgi?id=33512 Summary: radeon: lots of time spent in atombios_crtc_disable Product: Drivers Version: 2.5 Kernel Version: 2.6.39-rc3 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri at kernel-bugs.osdl.org ReportedBy: edwintorok at gmail.com Regression: No Created an attachment (id=54532) --> (https://bugzilla.kernel.org/attachment.cgi?id=54532) dmesg On a mostly idle system this is what I see with perf top (after exiting a game): --- PerfTop: 386 irqs/sec kernel:72.8% exact: 0.0% [1000Hz cycles], (all, 6 CPUs) --- samples pcnt function DSO ___ _ __ 171.00 18.0% atombios_crtc_disable /lib/modules/2.6.39-rc3-phenom-00117-ge38f5b7/kernel/drivers/gpu/drm/radeon/radeon.ko 47.00 4.9% find_next_bit [kernel.kallsyms] 31.00 3.3% format_decode [kernel.kallsyms] When playing a game that function is still on top, albeit with a lower percentage (7.5%). If the function does what its name says then it should be called at most once, when switching modes, entering standby, etc. I don't see why it is being called during normal operation, and why is it called so many times that it makes it the top function using the CPU... The graphics in games is quite laggy too, maybe because of this... My dmesg is attached. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 33512] radeon: lots of time spent in atombios_crtc_disable
https://bugzilla.kernel.org/show_bug.cgi?id=33512 --- Comment #1 from T?r?k Edwin 2011-04-17 20:45:53 --- Created an attachment (id=54542) --> (https://bugzilla.kernel.org/attachment.cgi?id=54542) Xorg.0.log Xorg log attached too -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 36332] New: Missing rendering in Unity dash
https://bugs.freedesktop.org/show_bug.cgi?id=36332 Summary: Missing rendering in Unity dash Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: chalserogers at gmail.com Forwarded from https://bugs.launchpad.net/ubuntu/+source/unity/+bug/726033 When rendering the Unity dash icons are frequently missing from the rendering. This video is a good demonstration of the problem: https://launchpadlibrarian.net/68813544/unity-bug.ogv This works on r600g, nouveau, i915 and i965, so it looks like it's a bug somewhere in r300g. The dash rendering uses FBOs and ARB shaders, with glscissor for clipping. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36332] Missing rendering in Unity dash
https://bugs.freedesktop.org/show_bug.cgi?id=36332 --- Comment #1 from Jay Taoko 2011-04-17 18:10:21 PDT --- Created an attachment (id=45747) --> (https://bugs.freedesktop.org/attachment.cgi?id=45747) Xorg.0.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36332] Missing rendering in Unity dash
https://bugs.freedesktop.org/show_bug.cgi?id=36332 --- Comment #2 from Jay Taoko 2011-04-17 18:11:05 PDT --- Created an attachment (id=45748) --> (https://bugs.freedesktop.org/attachment.cgi?id=45748) dmesg.txt -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36332] Missing rendering in Unity dash
https://bugs.freedesktop.org/show_bug.cgi?id=36332 --- Comment #3 from Jay Taoko 2011-04-17 18:11:41 PDT --- Created an attachment (id=45749) --> (https://bugs.freedesktop.org/attachment.cgi?id=45749) glxinfo.txt -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Linux 2.6.39-rc3
On Sun, Apr 17, 2011 at 10:09 AM, Joerg Roedel wrote: > On Sat, Apr 16, 2011 at 02:54:04PM -0400, Jerome Glisse wrote: > >> If you want to go the printk way you can add printk before each test >> ring_test, ib_test in r600.c this 2 functions are the own that might >> trigger the first GPU gart activities. > > Okay, I found the place in source that triggers this. It happens in the > function r600_ib_test. The interesting thing is that not the ib-command > itself is responsible but the fence that is emitted afterwards (proved > by removing the fence command, where the problem went away). > I don't know enough about the command semantics to make a guess what > goes wrong there. But maybe you GPU folks have an idea? > > ? ? ? ?Joerg > > I can't think of any theory, at that point the wb, irq ring, cp buffer & ib pool are all allocated and pinned into gtt so they all have valid entry backed by a real page. Maybe the GART flush & update is seriously buggy but i expect we would have been hurt sooner by such things. Maybe there is a bug in the hw... wouldn't be surprised. Will try to think to crazy theory. Cheers, Jerome
[Bug 36332] Missing rendering in Unity dash
https://bugs.freedesktop.org/show_bug.cgi?id=36332 --- Comment #4 from Christopher James Halse Rogers 2011-04-17 18:18:27 PDT --- This occurs on both mesa master (as of 2011/04/18, shown in logs) and 7.10.2. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36332] Missing rendering in Unity dash
https://bugs.freedesktop.org/show_bug.cgi?id=36332 --- Comment #5 from Jay Taoko 2011-04-17 18:24:09 PDT --- The bug can be reproduced on ATI R300/400/500 GPUs. These GPUs are no longer supported by fglrx so I couldn't verify if it was strictly a driver issue or if there was some error in our program code. However, the problem cannot be reproduced with a Radeon HD 4670 and the open source driver (or fglrx). Nor can it be reproduced with Intel GPUs such as the GMA 950 and above. The bug manifest itself in the Unity Dash. When an action is performed to show more icons in the dash, the rendering does not happen. Elements of the Dash only appear after the mouse moves over them, but this is the result of Unity refreshing the rendering. Some elements of the dash also disappear. This make me think that clipping could be involved. Unity makes extensive use of opengl scissoring. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 1/2] drm: Create and use drm_err
Reduce drm text size ~1% by using drm_err and
printf extension %pV to emit error messages.
Remove unused macro DRM_MEM_ERROR.
$ size drivers/gpu/drm/built-in.o*
textdata bss dec hex filename
3611599663 256 371078 5a986 drivers/gpu/drm/built-in.o.new
3654169663 256 375335 5ba27 drivers/gpu/drm/built-in.o.old
Signed-off-by: Joe Perches
---
drivers/gpu/drm/drm_stub.c | 21 +
include/drm/drmP.h | 21 +++--
2 files changed, 28 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 001273d..6d7b083 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -62,6 +62,26 @@ struct idr drm_minors_idr;
struct class *drm_class;
struct proc_dir_entry *drm_proc_root;
struct dentry *drm_debugfs_root;
+
+int drm_err(const char *func, const char *format, ...)
+{
+ struct va_format vaf;
+ va_list args;
+ int r;
+
+ va_start(args, format);
+
+ vaf.fmt = format;
+ vaf.va = &args;
+
+ r = printk(KERN_ERR "[" DRM_NAME ":%s] *ERROR* %pV", func, &vaf);
+
+ va_end(args);
+
+ return r;
+}
+EXPORT_SYMBOL(drm_err);
+
void drm_ut_debug_printk(unsigned int request_level,
const char *prefix,
const char *function_name,
@@ -78,6 +98,7 @@ void drm_ut_debug_printk(unsigned int request_level,
}
}
EXPORT_SYMBOL(drm_ut_debug_printk);
+
static int drm_minor_get_id(struct drm_device *dev, int type)
{
int new_id;
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 202424d..22db51d 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -126,6 +126,9 @@ extern void drm_ut_debug_printk(unsigned int request_level,
const char *prefix,
const char *function_name,
const char *format, ...);
+extern __attribute__((format (printf, 2, 3)))
+int drm_err(const char *func, const char *format, ...);
+
/***/
/** \name DRM template customization defaults */
/*@{*/
@@ -181,21 +184,11 @@ extern void drm_ut_debug_printk(unsigned int
request_level,
* \param fmt printf() like format string.
* \param arg arguments
*/
-#define DRM_ERROR(fmt, arg...) \
- printk(KERN_ERR "[" DRM_NAME ":%s] *ERROR* " fmt , __func__ , ##arg)
-
-/**
- * Memory error output.
- *
- * \param area memory area where the error occurred.
- * \param fmt printf() like format string.
- * \param arg arguments
- */
-#define DRM_MEM_ERROR(area, fmt, arg...) \
- printk(KERN_ERR "[" DRM_NAME ":%s:%s] *ERROR* " fmt , __func__, \
- drm_mem_stats[area].name , ##arg)
+#define DRM_ERROR(fmt, ...)\
+ drm_err(__func__, fmt, ##__VA_ARGS__)
-#define DRM_INFO(fmt, arg...) printk(KERN_INFO "[" DRM_NAME "] " fmt , ##arg)
+#define DRM_INFO(fmt, ...) \
+ printk(KERN_INFO "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
/**
* Debug output.
--
1.7.4.2.g597a6.dirty
[PATCH 2/2] drm: Verify debug message arguments
Add __attribute__((format (printf, 4, 5))) to drm_ut_debug_printk
and fix fallout.
Signed-off-by: Joe Perches
---
drivers/gpu/drm/drm_irq.c |9 +
drivers/gpu/drm/i915/intel_bios.c |6 +++---
drivers/gpu/drm/i915/intel_display.c|8
drivers/gpu/drm/radeon/radeon_display.c |5 +++--
include/drm/drmP.h |3 ++-
5 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 741457b..62ced75 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -684,10 +684,11 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct
drm_device *dev, int crtc,
*/
*vblank_time = ns_to_timeval(timeval_to_ns(&raw_time) - delta_ns);
- DRM_DEBUG("crtc %d : v %d p(%d,%d)@ %d.%d -> %d.%d [e %d us, %d rep]\n",
- crtc, (int) vbl_status, hpos, vpos, raw_time.tv_sec,
- raw_time.tv_usec, vblank_time->tv_sec, vblank_time->tv_usec,
- (int) duration_ns/1000, i);
+ DRM_DEBUG("crtc %d : v %d p(%d,%d)@ %ld.%ld -> %ld.%ld [e %d us, %d
rep]\n",
+ crtc, (int)vbl_status, hpos, vpos,
+ (long)raw_time.tv_sec, (long)raw_time.tv_usec,
+ (long)vblank_time->tv_sec, (long)vblank_time->tv_usec,
+ (int)duration_ns/1000, i);
vbl_status = DRM_VBLANKTIME_SCANOUTPOS_METHOD;
if (invbl)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index fb5b4d4..927442a 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -214,9 +214,9 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv,
i915_lvds_downclock) {
dev_priv->lvds_downclock_avail = 1;
dev_priv->lvds_downclock = temp_downclock;
- DRM_DEBUG_KMS("LVDS downclock is found in VBT. ",
- "Normal Clock %dKHz, downclock %dKHz\n",
- temp_downclock, panel_fixed_mode->clock);
+ DRM_DEBUG_KMS("LVDS downclock is found in VBT. "
+ "Normal Clock %dKHz, downclock %dKHz\n",
+ temp_downclock, panel_fixed_mode->clock);
}
return;
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 432fc04..63bc2af 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3497,11 +3497,11 @@ static unsigned long intel_calculate_wm(unsigned long
clock_in_khz,
1000;
entries_required = DIV_ROUND_UP(entries_required, wm->cacheline_size);
- DRM_DEBUG_KMS("FIFO entries required for mode: %d\n", entries_required);
+ DRM_DEBUG_KMS("FIFO entries required for mode: %ld\n",
entries_required);
wm_size = fifo_size - (entries_required + wm->guard_size);
- DRM_DEBUG_KMS("FIFO watermark level: %d\n", wm_size);
+ DRM_DEBUG_KMS("FIFO watermark level: %ld\n", wm_size);
/* Don't promote wm_size to unsigned... */
if (wm_size > (long)wm->max_wm)
@@ -3820,13 +3820,13 @@ static bool g4x_check_srwm(struct drm_device *dev,
display_wm, cursor_wm);
if (display_wm > display->max_wm) {
- DRM_DEBUG_KMS("display watermark is too large(%d), disabling\n",
+ DRM_DEBUG_KMS("display watermark is too large(%d/%ld),
disabling\n",
display_wm, display->max_wm);
return false;
}
if (cursor_wm > cursor->max_wm) {
- DRM_DEBUG_KMS("cursor watermark is too large(%d), disabling\n",
+ DRM_DEBUG_KMS("cursor watermark is too large(%d/%ld),
disabling\n",
cursor_wm, cursor->max_wm);
return false;
}
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index bdbab5c..0671934 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -1087,8 +1087,9 @@ void radeon_compute_pll_legacy(struct radeon_pll *pll,
*frac_fb_div_p = best_frac_feedback_div;
*ref_div_p = best_ref_div;
*post_div_p = best_post_div;
- DRM_DEBUG_KMS("%d %d, pll dividers - fb: %d.%d ref: %d, post %d\n",
- freq, best_freq / 1000, best_feedback_div,
best_frac_feedback_div,
+ DRM_DEBUG_KMS("%lld %d, pll dividers - fb: %d.%d ref: %d, post %d\n",
+ (long long)freq,
+ best_freq / 1000, best_feedback_div,
best_frac_feedback_div,
best_ref_div, best_post_div);
}
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 22db51d..4ab866e 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -122,7 +122,8 @@ struct drm_device;
* using the DRM_DEBUG_KMS and DRM_DEBUG.
*/
-extern void drm
[PATCH 0/2] drm: Message logging cleanups
Reduce the text space required and verify debug arguments. Joe Perches (2): drm: Create and use drm_err drm: Verify debug message arguments drivers/gpu/drm/drm_irq.c |9 + drivers/gpu/drm/drm_stub.c | 21 + drivers/gpu/drm/i915/intel_bios.c |6 +++--- drivers/gpu/drm/i915/intel_display.c|8 drivers/gpu/drm/radeon/radeon_display.c |5 +++-- include/drm/drmP.h | 24 +--- 6 files changed, 45 insertions(+), 28 deletions(-) -- 1.7.4.2.g597a6.dirty
2.6.39-rc1 nouveau regression (bisected)
On Sat, Apr 16, 2011 at 07:50:28PM -0400, Kyle Spaans wrote: > On Sun, Apr 17, 2011 at 08:12:35AM +1000, Nigel Cunningham wrote: > > On 15/04/11 16:11, Dominik Brodowski wrote: > > > On Thu, Apr 14, 2011 at 09:02:01PM +0200, Marcin Slusarz wrote: > > >> On Thu, Apr 14, 2011 at 07:05:59PM +0200, Dominik Brodowski wrote: > > >>> Thought about CCing Linus to show him that 2.6.39-rcX isn't as "calm" > > >>> to everyone, but then chose to CC Maciej instead: Would you be so kind > > >>> and > > >>> add this to your regression list? Thanks! > > >>> > > >>> Since commit 38f1cff > > >>> > > >>> From: Dave Airlie > > >>> Date: Wed, 16 Mar 2011 11:34:41 +1000 > > >>> Subject: [PATCH] Merge commit > > >>> '5359533801e3dd3abca5b7d3d985b0b33fd9fe8b' into dr > > >>> > > >>> This commit changed an internal radeon structure, that meant a new > > >>> driver > > >>> in -next had to be fixed up, merge in the commit and fix up the > > >>> driver. > > >>> > > >>> Also fixes a trivial nouveau merge. > > >>> > > >>> Conflicts: > > >>> drivers/gpu/drm/nouveau/nouveau_mem.c > > >>> > > >>> booting my atom/NM10/ION2 system crashes hard during boot, right after > > >>> blanking the screen, and before the initramfs gets loaded. I just > > >>> re-checked: both parent commits ( 5359533 and 4819d2e ) do indeed work > > >>> just fine, but the merge commit ( 38f1cff ) fails, same as tip ( > > >>> 85f2e68 ). > > >> Can you activate netconsole and check whether kernel spits anything > > >> interesting? > > >> You might try to load nouveau module after boot - maybe something will > > >> be saved > > >> to /var/log or you could even ssh into the box and check dmesg... > > > Compiling it as a module seems to work fine. When I do so, no regression > > > is > > > obvious from what gets reported in "dmesg". However, somehow I now do get > > > some output: The last message I see is > > > > > > [drm] nouveau :01:00.0: allocated 1680x1050, fb 0x40 b0 > > pointer value> > > > > > > Then, nothing more. However, it really is quite strange why this error > > > only > > > appears in the CONFIG_NOUVEAU=y case, not in the =m case... > > Try disabling CONFIG_BOOT_LOGO. I reported on freedesktop.org that it is > > causing me an oops at boot, but my bug has been ignored there so far - > > perhaps I should have posted it here instead. > > I'm getting the exact same symptoms on my Atom + ION hardware. Crashes before > it > can write any logs if it's compiled in and the logo is selected, but boots > fine > if compiled as a module or the logo is removed. > > In my case I bisected and found 8969960 by Nick Piggin (change to > mm/vmalloc.c) > to be the first bad one in 2.6.38+. This makes me think that it's not a bug in > nouveau, but maybe a bug in the order that things are initialized? FWIW, reverting commit 89699605fe7cfd8611900346f61cb6cbf179b10a on 2.6.39-rc3+ makes my system boot just fine with the nouveau drivers compiled into the kernel. I've seen some similar looking bugs on LKML that this regression may or may not be related to? It works fine on 2.6.38. https://bugzilla.kernel.org/show_bug.cgi?id=33272 http://lkml.org/lkml/2011/4/15/194 I'm still trying to figure out exactly where the kernel is crashing after printing [drm] nouveau :03:00.0: allocated 1280x1024 fb: 0x4000, b0 f4cf7600 Any thoughts on what else I should look for?
2.6.39-rc1 nouveau regression (bisected)
On Sun, Apr 17, 2011 at 05:45:57PM +0200, Marcin Slusarz wrote: > On Sun, Apr 17, 2011 at 11:12:04AM -0400, Kyle Spaans wrote: > > On Sat, Apr 16, 2011 at 07:50:28PM -0400, Kyle Spaans wrote: > > > On Sun, Apr 17, 2011 at 08:12:35AM +1000, Nigel Cunningham wrote: > > > > On 15/04/11 16:11, Dominik Brodowski wrote: > > > > > On Thu, Apr 14, 2011 at 09:02:01PM +0200, Marcin Slusarz wrote: > > > > >> On Thu, Apr 14, 2011 at 07:05:59PM +0200, Dominik Brodowski wrote: > > > > >>> Thought about CCing Linus to show him that 2.6.39-rcX isn't as > > > > >>> "calm" > > > > >>> to everyone, but then chose to CC Maciej instead: Would you be so > > > > >>> kind and > > > > >>> add this to your regression list? Thanks! > > > > >>> > > > > >>> Since commit 38f1cff > > > > >>> > > > > >>> From: Dave Airlie > > > > >>> Date: Wed, 16 Mar 2011 11:34:41 +1000 > > > > >>> Subject: [PATCH] Merge commit > > > > >>> '5359533801e3dd3abca5b7d3d985b0b33fd9fe8b' into dr > > > > >>> > > > > >>> This commit changed an internal radeon structure, that meant a > > > > >>> new driver > > > > >>> in -next had to be fixed up, merge in the commit and fix up the > > > > >>> driver. > > > > >>> > > > > >>> Also fixes a trivial nouveau merge. > > > > >>> > > > > >>> Conflicts: > > > > >>> drivers/gpu/drm/nouveau/nouveau_mem.c > > > > >>> > > > > >>> booting my atom/NM10/ION2 system crashes hard during boot, right > > > > >>> after > > > > >>> blanking the screen, and before the initramfs gets loaded. I just > > > > >>> re-checked: both parent commits ( 5359533 and 4819d2e ) do indeed > > > > >>> work > > > > >>> just fine, but the merge commit ( 38f1cff ) fails, same as tip ( > > > > >>> 85f2e68 ). > > > > >> Can you activate netconsole and check whether kernel spits anything > > > > >> interesting? > > > > >> You might try to load nouveau module after boot - maybe something > > > > >> will be saved > > > > >> to /var/log or you could even ssh into the box and check dmesg... > > > > > Compiling it as a module seems to work fine. When I do so, no > > > > > regression is > > > > > obvious from what gets reported in "dmesg". However, somehow I now do > > > > > get > > > > > some output: The last message I see is > > > > > > > > > > [drm] nouveau :01:00.0: allocated 1680x1050, fb 0x40 b0 > > > > pointer value> > > > > > > > > > > Then, nothing more. However, it really is quite strange why this > > > > > error only > > > > > appears in the CONFIG_NOUVEAU=y case, not in the =m case... > > > > Try disabling CONFIG_BOOT_LOGO. I reported on freedesktop.org that it is > > > > causing me an oops at boot, but my bug has been ignored there so far - > > > > perhaps I should have posted it here instead. > > > > > > I'm getting the exact same symptoms on my Atom + ION hardware. Crashes > > > before it > > > can write any logs if it's compiled in and the logo is selected, but > > > boots fine > > > if compiled as a module or the logo is removed. > > > > > > In my case I bisected and found 8969960 by Nick Piggin (change to > > > mm/vmalloc.c) > > > to be the first bad one in 2.6.38+. This makes me think that it's not a > > > bug in > > > nouveau, but maybe a bug in the order that things are initialized? > > > > FWIW, reverting commit 89699605fe7cfd8611900346f61cb6cbf179b10a on > > 2.6.39-rc3+ > > makes my system boot just fine with the nouveau drivers compiled into the > > kernel. I've seen some similar looking bugs on LKML that this regression > > may or > > may not be related to? It works fine on 2.6.38. > > > > https://bugzilla.kernel.org/show_bug.cgi?id=33272 > > http://lkml.org/lkml/2011/4/15/194 > > > > I'm still trying to figure out exactly where the kernel is crashing after > > printing > > [drm] nouveau :03:00.0: allocated 1280x1024 fb: 0x4000, b0 f4cf7600 > > > > Any thoughts on what else I should look for? > > I reproduced this bug today, and reverting > 89699605fe7cfd8611900346f61cb6cbf179b10a > does not fix it for me. Here's the backtrace: > > Entering kdb (current=0x8801becb, pid 1) on processor 6 Oops: (null) > due to oops @ 0x81255081 > CPU 6 Modules linked in: > > Pid: 1, comm: swapper Not tainted 2.6.39-rc2-nv+ #640 System > manufacturer System Product Name/P6T SE > RIP: 0010:[] [] iowrite32+0x12/0x34 > RSP: :8801becab4b0 EFLAGS: 00010296 > RAX: RBX: 8801bd334800 RCX: 16fc > RDX: RSI: c900100bbf4c RDI: c900100bbf4c > RBP: 8801becab4b0 R08: 0002 R09: 0001 > R10: 00bb R11: 8801becab540 R12: 8801bd336000 > R13: 8801bd334818 R14: 8801bd60 R15: 0020 > FS: () GS:8801bfd8() > knlGS: > CS: 0010 DS: ES: CR0: 8005003b > CR2: c900100bbf4c CR3: 01a2b000 CR4: 06e0 > DR0: DR1: DR2:
