* Softlockup on boot with Cape Verde XT on many kernels @ 2015-01-11 1:58 Federico 2015-01-11 17:19 ` Alex Deucher 2015-01-13 7:06 ` Michel Dänzer 0 siblings, 2 replies; 26+ messages in thread From: Federico @ 2015-01-11 1:58 UTC (permalink / raw) To: dri-devel [-- Attachment #1.1: Type: text/plain, Size: 883 bytes --] Hi. I always get a soft lockup when booting since I bought a Cape Verde XT [Radeon HD 7770/8760 / R7 250X]. In this bug report you can find screenshots of the softlockup and the kernel panic generated by using softlockup_panic=1 https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973 I have this problem with and without nomodeset and I have tested the kernels that come with Ubuntu 14.04, 14.10 and 15.04 (today's daily image). The live session shows me the boot menu where I can enter kernel options and such, but when booting into a live session it soon prints the softlockup messages forever. In order to install catalyst I had to disable the card in the BIOS and boot into the integrated graphics. Catalyst works perfectly. MoBo is based on AMD 780G (Radeon HD3200 IGP). If there's anything I can do to help find a workaround or a fix for this, let me know. [-- Attachment #1.2: Type: text/html, Size: 1188 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Softlockup on boot with Cape Verde XT on many kernels 2015-01-11 1:58 Softlockup on boot with Cape Verde XT on many kernels Federico @ 2015-01-11 17:19 ` Alex Deucher [not found] ` <CAFUqUc7qXoNQJwyXJtcx=6gmG0hwnHeor-NyfoPPchX9EYTDzA@mail.gmail.com> 2015-01-13 7:06 ` Michel Dänzer 1 sibling, 1 reply; 26+ messages in thread From: Alex Deucher @ 2015-01-11 17:19 UTC (permalink / raw) To: Federico; +Cc: Maling list - DRI developers On Sat, Jan 10, 2015 at 8:58 PM, Federico <federicotg@gmail.com> wrote: > Hi. > I always get a soft lockup when booting since I bought a Cape Verde XT > [Radeon HD 7770/8760 / R7 250X]. > > In this bug report you can find screenshots of the softlockup and the kernel > panic generated by using softlockup_panic=1 > > https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973 > > I have this problem with and without nomodeset and I have tested the kernels > that come with Ubuntu 14.04, 14.10 and 15.04 (today's daily image). > > The live session shows me the boot menu where I can enter kernel options > and such, but when booting into a live session it soon prints the softlockup > messages forever. > > In order to install catalyst I had to disable the card in the BIOS and boot > into the integrated graphics. Catalyst works perfectly. > > MoBo is based on AMD 780G (Radeon HD3200 IGP). > > If there's anything I can do to help find a workaround or a fix for this, > let me know. Booting with nomodeset disables the graphics drivers so if you are still getting problems, it may a hardware problem. Can you attach your full dmesg and lspci output? Are you disabling the onboard graphics when enabling the external dGPU? Alex _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <CAFUqUc7qXoNQJwyXJtcx=6gmG0hwnHeor-NyfoPPchX9EYTDzA@mail.gmail.com>]
* Fwd: Softlockup on boot with Cape Verde XT on many kernels [not found] ` <CAFUqUc7qXoNQJwyXJtcx=6gmG0hwnHeor-NyfoPPchX9EYTDzA@mail.gmail.com> @ 2015-01-11 19:44 ` Federico 2015-01-11 20:27 ` Federico 0 siblings, 1 reply; 26+ messages in thread From: Federico @ 2015-01-11 19:44 UTC (permalink / raw) To: dri-devel [-- Attachment #1.1: Type: text/plain, Size: 847 bytes --] 2015-01-11 14:19 GMT-03:00 Alex Deucher <alexdeucher@gmail.com>: > Booting with nomodeset disables the graphics drivers so if you are > still getting problems, it may a hardware problem. Can you attach > your full dmesg and lspci output? Are you disabling the onboard > graphics when enabling the external dGPU? > > Alex > I attached those outputs to https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973 I wasn't sure if you meant attaching to this response. I was able to boot with nomodeset into Ubuntu 15.04's image. I get to a graphic log in screen, but I also get some errors in the kernel log [drm:radeon_init] *ERROR* No UMS support in radeon module! Which seems by design so I assume the VESA driver was in use. I will try to boot Ubuntu 14.10 live image with nomodeset to see if I can get some error messages there. [-- Attachment #1.2: Type: text/html, Size: 1545 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Softlockup on boot with Cape Verde XT on many kernels 2015-01-11 19:44 ` Fwd: " Federico @ 2015-01-11 20:27 ` Federico 2015-01-12 21:48 ` Alex Deucher 0 siblings, 1 reply; 26+ messages in thread From: Federico @ 2015-01-11 20:27 UTC (permalink / raw) To: dri-devel [-- Attachment #1.1: Type: text/plain, Size: 1662 bytes --] Ubuntu 14.10 (kernel is 3.16.0) with nomodeset also boots. But it seems to be using the a generic driver cat /var/log/kern.log | grep ERROR Jan 11 20:07:56 ubuntu kernel: [ 6.174086] [drm:radeon_init] *ERROR* No UMS support in radeon module! Jan 11 20:07:56 ubuntu kernel: [ 54.093686] [drm:radeon_init] *ERROR* No UMS support in radeon module! Jan 11 20:08:10 ubuntu kernel: [ 94.983647] [drm:radeon_init] *ERROR* No UMS support in radeon module! glxinfo | grep Open OpenGL vendor string: VMware, Inc. OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.5, 128 bits) OpenGL version string: 3.0 Mesa 10.3.0 OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: 2015-01-11 19:44 GMT+00:00 Federico <federicotg@gmail.com>: > > > 2015-01-11 14:19 GMT-03:00 Alex Deucher <alexdeucher@gmail.com>: > >> Booting with nomodeset disables the graphics drivers so if you are >> still getting problems, it may a hardware problem. Can you attach >> your full dmesg and lspci output? Are you disabling the onboard >> graphics when enabling the external dGPU? >> >> Alex >> > > I attached those outputs to > https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973 > I wasn't sure if you meant attaching to this response. > > I was able to boot with nomodeset into Ubuntu 15.04's image. I get to a > graphic log in screen, but I also get some errors in the kernel log > > [drm:radeon_init] *ERROR* No UMS support in radeon module! > > Which seems by design so I assume the VESA driver was in use. > > I will try to boot Ubuntu 14.10 live image with nomodeset to see if I can > get some error messages there. > [-- Attachment #1.2: Type: text/html, Size: 2704 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Softlockup on boot with Cape Verde XT on many kernels 2015-01-11 20:27 ` Federico @ 2015-01-12 21:48 ` Alex Deucher 2015-01-12 23:34 ` Federico 0 siblings, 1 reply; 26+ messages in thread From: Alex Deucher @ 2015-01-12 21:48 UTC (permalink / raw) To: Federico; +Cc: Maling list - DRI developers On Sun, Jan 11, 2015 at 3:27 PM, Federico <federicotg@gmail.com> wrote: > Ubuntu 14.10 (kernel is 3.16.0) with nomodeset also boots. But it seems to > be using the a generic driver Right. As I mentioned, using nomodeset disables the gfx driver and you end up with fw drivers (vesa of efifb). Do you still have the issue even with nomodeset as you previously stated? Alex > > cat /var/log/kern.log | grep ERROR > Jan 11 20:07:56 ubuntu kernel: [ 6.174086] [drm:radeon_init] *ERROR* No > UMS support in radeon module! > Jan 11 20:07:56 ubuntu kernel: [ 54.093686] [drm:radeon_init] *ERROR* No > UMS support in radeon module! > Jan 11 20:08:10 ubuntu kernel: [ 94.983647] [drm:radeon_init] *ERROR* No > UMS support in radeon module! > > glxinfo | grep Open > OpenGL vendor string: VMware, Inc. > OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.5, 128 bits) > OpenGL version string: 3.0 Mesa 10.3.0 > OpenGL shading language version string: 1.30 > OpenGL context flags: (none) > OpenGL extensions: > > > 2015-01-11 19:44 GMT+00:00 Federico <federicotg@gmail.com>: >> >> >> >> 2015-01-11 14:19 GMT-03:00 Alex Deucher <alexdeucher@gmail.com>: >>> >>> Booting with nomodeset disables the graphics drivers so if you are >>> still getting problems, it may a hardware problem. Can you attach >>> your full dmesg and lspci output? Are you disabling the onboard >>> graphics when enabling the external dGPU? >>> >>> Alex >> >> >> I attached those outputs to >> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973 >> I wasn't sure if you meant attaching to this response. >> >> I was able to boot with nomodeset into Ubuntu 15.04's image. I get to a >> graphic log in screen, but I also get some errors in the kernel log >> >> [drm:radeon_init] *ERROR* No UMS support in radeon module! >> >> Which seems by design so I assume the VESA driver was in use. >> >> I will try to boot Ubuntu 14.10 live image with nomodeset to see if I can >> get some error messages there. > > > > _______________________________________________ > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Softlockup on boot with Cape Verde XT on many kernels 2015-01-12 21:48 ` Alex Deucher @ 2015-01-12 23:34 ` Federico 0 siblings, 0 replies; 26+ messages in thread From: Federico @ 2015-01-12 23:34 UTC (permalink / raw) To: Alex Deucher; +Cc: Maling list - DRI developers [-- Attachment #1.1: Type: text/plain, Size: 3279 bytes --] No, with nomodeset I don't have the softlockup and I can boot, but Xorg does not load the radeon driver. The kernel logs some radeon errors $ dmesg | grep drm [ 6.139753] [drm] Initialized drm 1.1.0 20060810 [ 6.173103] [drm] VGACON disable radeon kernel modesetting. [ 6.173153] [drm:radeon_init] *ERROR* No UMS support in radeon module! [ 50.032476] [drm] VGACON disable radeon kernel modesetting. [ 50.032494] [drm:radeon_init] *ERROR* No UMS support in radeon module! [ 89.408520] [drm] VGACON disable radeon kernel modesetting. [ 89.408526] [drm:radeon_init] *ERROR* No UMS support in radeon module! Here's Xorg.log. It tries to load radeon, but then in unloads it. https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4296840/+files/Xorg.0.log I also checked the bios and yes, the IGP is disabled and the setting is set to start from the PCI Express slot. 2015-01-12 21:48 GMT+00:00 Alex Deucher <alexdeucher@gmail.com>: > On Sun, Jan 11, 2015 at 3:27 PM, Federico <federicotg@gmail.com> wrote: > > Ubuntu 14.10 (kernel is 3.16.0) with nomodeset also boots. But it seems > to > > be using the a generic driver > > Right. As I mentioned, using nomodeset disables the gfx driver and > you end up with fw drivers (vesa of efifb). Do you still have the > issue even with nomodeset as you previously stated? > > Alex > > > > > cat /var/log/kern.log | grep ERROR > > Jan 11 20:07:56 ubuntu kernel: [ 6.174086] [drm:radeon_init] *ERROR* > No > > UMS support in radeon module! > > Jan 11 20:07:56 ubuntu kernel: [ 54.093686] [drm:radeon_init] *ERROR* > No > > UMS support in radeon module! > > Jan 11 20:08:10 ubuntu kernel: [ 94.983647] [drm:radeon_init] *ERROR* > No > > UMS support in radeon module! > > > > glxinfo | grep Open > > OpenGL vendor string: VMware, Inc. > > OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.5, 128 bits) > > OpenGL version string: 3.0 Mesa 10.3.0 > > OpenGL shading language version string: 1.30 > > OpenGL context flags: (none) > > OpenGL extensions: > > > > > > 2015-01-11 19:44 GMT+00:00 Federico <federicotg@gmail.com>: > >> > >> > >> > >> 2015-01-11 14:19 GMT-03:00 Alex Deucher <alexdeucher@gmail.com>: > >>> > >>> Booting with nomodeset disables the graphics drivers so if you are > >>> still getting problems, it may a hardware problem. Can you attach > >>> your full dmesg and lspci output? Are you disabling the onboard > >>> graphics when enabling the external dGPU? > >>> > >>> Alex > >> > >> > >> I attached those outputs to > >> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973 > >> I wasn't sure if you meant attaching to this response. > >> > >> I was able to boot with nomodeset into Ubuntu 15.04's image. I get to a > >> graphic log in screen, but I also get some errors in the kernel log > >> > >> [drm:radeon_init] *ERROR* No UMS support in radeon module! > >> > >> Which seems by design so I assume the VESA driver was in use. > >> > >> I will try to boot Ubuntu 14.10 live image with nomodeset to see if I > can > >> get some error messages there. > > > > > > > > _______________________________________________ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/dri-devel > > > [-- Attachment #1.2: Type: text/html, Size: 4760 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Softlockup on boot with Cape Verde XT on many kernels 2015-01-11 1:58 Softlockup on boot with Cape Verde XT on many kernels Federico 2015-01-11 17:19 ` Alex Deucher @ 2015-01-13 7:06 ` Michel Dänzer 2015-01-13 18:20 ` Federico 1 sibling, 1 reply; 26+ messages in thread From: Michel Dänzer @ 2015-01-13 7:06 UTC (permalink / raw) To: Federico; +Cc: dri-devel On 11.01.2015 10:58, Federico wrote: > Hi. > I always get a soft lockup when booting since I bought a Cape Verde XT > [Radeon HD 7770/8760 / R7 250X]. > > In this bug report you can find screenshots of the softlockup and the > kernel panic generated by using softlockup_panic=1 > > https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973 Is that the full backtrace from the panic? Maybe you can set a higher console resolution or a smaller console font? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Softlockup on boot with Cape Verde XT on many kernels 2015-01-13 7:06 ` Michel Dänzer @ 2015-01-13 18:20 ` Federico 2015-01-14 2:19 ` Michel Dänzer 0 siblings, 1 reply; 26+ messages in thread From: Federico @ 2015-01-13 18:20 UTC (permalink / raw) To: Michel Dänzer; +Cc: Maling list - DRI developers [-- Attachment #1.1: Type: text/plain, Size: 1051 bytes --] I tried setting vga=791, but the panic messages done appear on screen, only the normal kernel boot log until the key lights start flashing. Also tried a video capture, but the text goes too fast even for the LCD to update the image. Do you know how to set the console font size as a kernel parameter? 2015-01-13 4:06 GMT-03:00 Michel Dänzer <michel@daenzer.net>: > On 11.01.2015 10:58, Federico wrote: > > Hi. > > I always get a soft lockup when booting since I bought a Cape Verde XT > > [Radeon HD 7770/8760 / R7 250X]. > > > > In this bug report you can find screenshots of the softlockup and the > > kernel panic generated by using softlockup_panic=1 > > > > https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973 > > Is that the full backtrace from the panic? Maybe you can set a higher > console resolution or a smaller console font? > > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Mesa and X developer > [-- Attachment #1.2: Type: text/html, Size: 1744 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Softlockup on boot with Cape Verde XT on many kernels 2015-01-13 18:20 ` Federico @ 2015-01-14 2:19 ` Michel Dänzer 2015-01-14 3:41 ` Federico 0 siblings, 1 reply; 26+ messages in thread From: Michel Dänzer @ 2015-01-14 2:19 UTC (permalink / raw) To: Federico; +Cc: Maling list - DRI developers On 14.01.2015 03:20, Federico wrote: > I tried setting vga=791, but the panic messages done appear on screen, > only the normal kernel boot log until the key lights start flashing. Sounds like the panic happens after vesafb is already shut down in favour of radeon. > Also tried a video capture, but the text goes too fast even for the LCD > to update the image. > > Do you know how to set the console font size as a kernel parameter? Search for '8-.*font' in Documentation/svga.txt. Other possibilities would be serial console or possibly netconsole. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Softlockup on boot with Cape Verde XT on many kernels 2015-01-14 2:19 ` Michel Dänzer @ 2015-01-14 3:41 ` Federico 2015-01-14 3:54 ` Michel Dänzer 0 siblings, 1 reply; 26+ messages in thread From: Federico @ 2015-01-14 3:41 UTC (permalink / raw) To: Michel Dänzer; +Cc: Maling list - DRI developers [-- Attachment #1.1: Type: text/plain, Size: 1189 bytes --] I tried 3.16.0 just using radeon.dpm=0 (without softlockup_panic=1) and I got a different stack trace. Shorter. It repeats itself every about 30 seconds more or less. Keyboard lights don't flash. The same message keeps coming out. https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298034/+files/20150114_003043.png 2015-01-13 23:19 GMT-03:00 Michel Dänzer <michel@daenzer.net>: > On 14.01.2015 03:20, Federico wrote: > > I tried setting vga=791, but the panic messages done appear on screen, > > only the normal kernel boot log until the key lights start flashing. > > Sounds like the panic happens after vesafb is already shut down in > favour of radeon. > > > > Also tried a video capture, but the text goes too fast even for the LCD > > to update the image. > > > > Do you know how to set the console font size as a kernel parameter? > > Search for '8-.*font' in Documentation/svga.txt. > > Other possibilities would be serial console or possibly netconsole. > > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Mesa and X developer > [-- Attachment #1.2: Type: text/html, Size: 1858 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Softlockup on boot with Cape Verde XT on many kernels 2015-01-14 3:41 ` Federico @ 2015-01-14 3:54 ` Michel Dänzer 2015-01-14 13:29 ` Federico 0 siblings, 1 reply; 26+ messages in thread From: Michel Dänzer @ 2015-01-14 3:54 UTC (permalink / raw) To: Federico; +Cc: Maling list - DRI developers On 14.01.2015 12:41, Federico wrote: > I tried 3.16.0 just using radeon.dpm=0 (without softlockup_panic=1) and > I got a different stack trace. Shorter. It repeats itself every about 30 > seconds more or less. Keyboard lights don't flash. The same message > keeps coming out. > > https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298034/+files/20150114_003043.png That's again missing some of the information, but it doesn't look directly related to the radeon driver. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Softlockup on boot with Cape Verde XT on many kernels 2015-01-14 3:54 ` Michel Dänzer @ 2015-01-14 13:29 ` Federico 2015-01-15 0:10 ` Federico 0 siblings, 1 reply; 26+ messages in thread From: Federico @ 2015-01-14 13:29 UTC (permalink / raw) To: Michel Dänzer; +Cc: Maling list - DRI developers [-- Attachment #1.1: Type: text/plain, Size: 959 bytes --] Here's a stack trace with soflockup_panic=1 using 50 lines per screen. https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298395/+files/20150114_100952.png 2015-01-14 0:54 GMT-03:00 Michel Dänzer <michel@daenzer.net>: > On 14.01.2015 12:41, Federico wrote: > > I tried 3.16.0 just using radeon.dpm=0 (without softlockup_panic=1) and > > I got a different stack trace. Shorter. It repeats itself every about 30 > > seconds more or less. Keyboard lights don't flash. The same message > > keeps coming out. > > > > > https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298034/+files/20150114_003043.png > > That's again missing some of the information, but it doesn't look > directly related to the radeon driver. > > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Mesa and X developer > [-- Attachment #1.2: Type: text/html, Size: 1751 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Softlockup on boot with Cape Verde XT on many kernels 2015-01-14 13:29 ` Federico @ 2015-01-15 0:10 ` Federico 2015-01-15 2:10 ` Federico 0 siblings, 1 reply; 26+ messages in thread From: Federico @ 2015-01-15 0:10 UTC (permalink / raw) To: Michel Dänzer; +Cc: Maling list - DRI developers [-- Attachment #1.1: Type: text/plain, Size: 1309 bytes --] Here's a stacktrace with 60 lines. It is more complete. It's 3.18 64 bits. Next I'm going to try the same with a 32 bit kernel. https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298722/+files/20150114_205715.png 2015-01-14 10:29 GMT-03:00 Federico <federicotg@gmail.com>: > Here's a stack trace with soflockup_panic=1 using 50 lines per screen. > > > https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298395/+files/20150114_100952.png > > > 2015-01-14 0:54 GMT-03:00 Michel Dänzer <michel@daenzer.net>: > > On 14.01.2015 12:41, Federico wrote: >> > I tried 3.16.0 just using radeon.dpm=0 (without softlockup_panic=1) and >> > I got a different stack trace. Shorter. It repeats itself every about 30 >> > seconds more or less. Keyboard lights don't flash. The same message >> > keeps coming out. >> > >> > >> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298034/+files/20150114_003043.png >> >> That's again missing some of the information, but it doesn't look >> directly related to the radeon driver. >> >> >> -- >> Earthling Michel Dänzer | http://www.amd.com >> Libre software enthusiast | Mesa and X developer >> > > [-- Attachment #1.2: Type: text/html, Size: 2536 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Softlockup on boot with Cape Verde XT on many kernels 2015-01-15 0:10 ` Federico @ 2015-01-15 2:10 ` Federico 2015-01-15 2:46 ` Michel Dänzer 0 siblings, 1 reply; 26+ messages in thread From: Federico @ 2015-01-15 2:10 UTC (permalink / raw) To: Michel Dänzer; +Cc: Maling list - DRI developers [-- Attachment #1.1: Type: text/plain, Size: 1697 bytes --] Here's the 3.18 32-bits 60 lines per screen stack trace. Always using softlockup_panic=1. Quite similar, but slightly different. Hopefully, useful. https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298769/+files/20150114_230142.png 2015-01-14 21:10 GMT-03:00 Federico <federicotg@gmail.com>: > Here's a stacktrace with 60 lines. It is more complete. > It's 3.18 64 bits. > Next I'm going to try the same with a 32 bit kernel. > > > https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298722/+files/20150114_205715.png > > > 2015-01-14 10:29 GMT-03:00 Federico <federicotg@gmail.com>: > > Here's a stack trace with soflockup_panic=1 using 50 lines per screen. >> >> >> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298395/+files/20150114_100952.png >> >> >> 2015-01-14 0:54 GMT-03:00 Michel Dänzer <michel@daenzer.net>: >> >> On 14.01.2015 12:41, Federico wrote: >>> > I tried 3.16.0 just using radeon.dpm=0 (without softlockup_panic=1) and >>> > I got a different stack trace. Shorter. It repeats itself every about >>> 30 >>> > seconds more or less. Keyboard lights don't flash. The same message >>> > keeps coming out. >>> > >>> > >>> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298034/+files/20150114_003043.png >>> >>> That's again missing some of the information, but it doesn't look >>> directly related to the radeon driver. >>> >>> >>> -- >>> Earthling Michel Dänzer | http://www.amd.com >>> Libre software enthusiast | Mesa and X developer >>> >> >> > [-- Attachment #1.2: Type: text/html, Size: 3391 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Softlockup on boot with Cape Verde XT on many kernels 2015-01-15 2:10 ` Federico @ 2015-01-15 2:46 ` Michel Dänzer 2015-01-15 2:59 ` Federico 0 siblings, 1 reply; 26+ messages in thread From: Michel Dänzer @ 2015-01-15 2:46 UTC (permalink / raw) To: Federico; +Cc: Maling list - DRI developers On 15.01.2015 11:10, Federico wrote: > Here's the 3.18 32-bits 60 lines per screen stack trace. Always using > softlockup_panic=1. > > Quite similar, but slightly different. Hopefully, useful. > > https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298769/+files/20150114_230142.png Looks like it hangs while reading the video BIOS ROM. If the integrated GPU is still enabled in the system BIOS setup, does disabling it avoid the problem? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Softlockup on boot with Cape Verde XT on many kernels 2015-01-15 2:46 ` Michel Dänzer @ 2015-01-15 2:59 ` Federico 2015-01-15 3:14 ` Federico 0 siblings, 1 reply; 26+ messages in thread From: Federico @ 2015-01-15 2:59 UTC (permalink / raw) To: Michel Dänzer; +Cc: Maling list - DRI developers [-- Attachment #1.1: Type: text/plain, Size: 1107 bytes --] AFAIK this BIOS requires me to disable IGP to even use the discrete graphics. At least that's the first thing I had to do when I first installed the card and every time I wanted to change the monitor connection. Here's how "disabled" it is: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298792/+files/20150114_234953.png 2015-01-14 23:46 GMT-03:00 Michel Dänzer <michel@daenzer.net>: > On 15.01.2015 11:10, Federico wrote: > > Here's the 3.18 32-bits 60 lines per screen stack trace. Always using > > softlockup_panic=1. > > > > Quite similar, but slightly different. Hopefully, useful. > > > > > https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298769/+files/20150114_230142.png > > Looks like it hangs while reading the video BIOS ROM. > > If the integrated GPU is still enabled in the system BIOS setup, does > disabling it avoid the problem? > > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Mesa and X developer > [-- Attachment #1.2: Type: text/html, Size: 1921 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Softlockup on boot with Cape Verde XT on many kernels 2015-01-15 2:59 ` Federico @ 2015-01-15 3:14 ` Federico 2015-01-15 3:53 ` Federico 0 siblings, 1 reply; 26+ messages in thread From: Federico @ 2015-01-15 3:14 UTC (permalink / raw) To: Michel Dänzer; +Cc: Maling list - DRI developers [-- Attachment #1.1: Type: text/plain, Size: 1476 bytes --] Also just tried *enabling* the IGP and keeping PEG as the primary graphics. Video output stayed on the discrete card output and the same stack trace happened when booting without nomodeset. So now I'm back to setting it as disabled as it had been before. 2015-01-14 23:59 GMT-03:00 Federico <federicotg@gmail.com>: > AFAIK this BIOS requires me to disable IGP to even use the discrete > graphics. At least that's the first thing I had to do when I first > installed the card and every time I wanted to change the monitor connection. > Here's how "disabled" it is: > > > https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298792/+files/20150114_234953.png > > > 2015-01-14 23:46 GMT-03:00 Michel Dänzer <michel@daenzer.net>: > > On 15.01.2015 11:10, Federico wrote: >> > Here's the 3.18 32-bits 60 lines per screen stack trace. Always using >> > softlockup_panic=1. >> > >> > Quite similar, but slightly different. Hopefully, useful. >> > >> > >> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298769/+files/20150114_230142.png >> >> Looks like it hangs while reading the video BIOS ROM. >> >> If the integrated GPU is still enabled in the system BIOS setup, does >> disabling it avoid the problem? >> >> >> -- >> Earthling Michel Dänzer | http://www.amd.com >> Libre software enthusiast | Mesa and X developer >> > > [-- Attachment #1.2: Type: text/html, Size: 2570 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Softlockup on boot with Cape Verde XT on many kernels 2015-01-15 3:14 ` Federico @ 2015-01-15 3:53 ` Federico 2015-01-15 6:21 ` Michel Dänzer 0 siblings, 1 reply; 26+ messages in thread From: Federico @ 2015-01-15 3:53 UTC (permalink / raw) To: Michel Dänzer; +Cc: Maling list - DRI developers [-- Attachment #1.1: Type: text/plain, Size: 2637 bytes --] How about this? It seems at least related. https://github.com/alterapraxisptyltd/openatom/issues/1 Quote: [linux] Infinite loop in pci_get_rom_size() This is one of those issues that you find when putting supposedly stable code through unusual situations. I did expect any function in linux that is not part of radeon.ko to not be rock solid. Turns out that's not really the case. If we have a PCIR structure with a zero size length, the loop iterating through those structure does not advance. It simply does "image += readw(pds + 16) * 512;", but if that field is zero we're back analyzing the same structure on the next loop. The way to get out of this loop is to set bit 7 of the type field. That's what 'last_image' does. If that bit is not set, with the above, that's an infinite loop. Luckily, it doesn't crash the kernel, but it hangs any driver that calls the function under said circumstances. No more modprobe -r or unbinding. Reboot is needed. No idea why a firmware blob here is treated as trusted input. 2015-01-15 0:14 GMT-03:00 Federico <federicotg@gmail.com>: > Also just tried *enabling* the IGP and keeping PEG as the primary > graphics. Video output stayed on the discrete card output and the same > stack trace happened when booting without nomodeset. So now I'm back to > setting it as disabled as it had been before. > > > 2015-01-14 23:59 GMT-03:00 Federico <federicotg@gmail.com>: > > AFAIK this BIOS requires me to disable IGP to even use the discrete >> graphics. At least that's the first thing I had to do when I first >> installed the card and every time I wanted to change the monitor connection. >> Here's how "disabled" it is: >> >> >> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298792/+files/20150114_234953.png >> >> >> 2015-01-14 23:46 GMT-03:00 Michel Dänzer <michel@daenzer.net>: >> >> On 15.01.2015 11:10, Federico wrote: >>> > Here's the 3.18 32-bits 60 lines per screen stack trace. Always using >>> > softlockup_panic=1. >>> > >>> > Quite similar, but slightly different. Hopefully, useful. >>> > >>> > >>> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298769/+files/20150114_230142.png >>> >>> Looks like it hangs while reading the video BIOS ROM. >>> >>> If the integrated GPU is still enabled in the system BIOS setup, does >>> disabling it avoid the problem? >>> >>> >>> -- >>> Earthling Michel Dänzer | http://www.amd.com >>> Libre software enthusiast | Mesa and X developer >>> >> >> > [-- Attachment #1.2: Type: text/html, Size: 4273 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Softlockup on boot with Cape Verde XT on many kernels 2015-01-15 3:53 ` Federico @ 2015-01-15 6:21 ` Michel Dänzer 2015-01-15 20:33 ` Federico 0 siblings, 1 reply; 26+ messages in thread From: Michel Dänzer @ 2015-01-15 6:21 UTC (permalink / raw) To: Federico; +Cc: Maling list - DRI developers [-- Attachment #1: Type: text/plain, Size: 1351 bytes --] On 15.01.2015 12:53, Federico wrote: > How about this? It seems at least related. > > https://github.com/alterapraxisptyltd/openatom/issues/1 > > Quote: > [linux] Infinite loop in pci_get_rom_size() > > This is one of those issues that you find when putting supposedly stable > code through unusual situations. I did expect any function in linux that > is not part of radeon.ko to not be rock solid. Turns out that's not > really the case. > > If we have a PCIR structure with a zero size length, the loop iterating > through those structure does not advance. It simply does "image += > readw(pds + 16) * 512;", but if that field is zero we're back analyzing > the same structure on the next loop. The way to get out of this loop is > to set bit 7 of the type field. That's what 'last_image' does. If that > bit is not set, with the above, that's an infinite loop. > > Luckily, it doesn't crash the kernel, but it hangs any driver that calls > the function under said circumstances. No more modprobe -r or unbinding. > Reboot is needed. No idea why a firmware blob here is treated as trusted > input. That could indeed explain it, does the attached patch help? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: pci_get_rom_size.diff --] [-- Type: text/x-patch; name="pci_get_rom_size.diff", Size: 870 bytes --] diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c index f955edb..2fb5013 100644 --- a/drivers/pci/rom.c +++ b/drivers/pci/rom.c @@ -75,6 +75,7 @@ size_t pci_get_rom_size(struct pci_dev *pdev, void __iomem *rom, size_t size) image = rom; do { void __iomem *pds; + u16 length; /* Standard PCI ROMs start out with these bytes 55 AA */ if (readb(image) != 0x55) { dev_err(&pdev->dev, "Invalid ROM contents\n"); @@ -93,8 +94,10 @@ size_t pci_get_rom_size(struct pci_dev *pdev, void __iomem *rom, size_t size) if (readb(pds + 3) != 'R') break; last_image = readb(pds + 21) & 0x80; - /* this length is reliable */ - image += readw(pds + 16) * 512; + length = readw(pds + 16); + if (!length) + break; + image += length * 512; } while (!last_image); /* never return a size larger than the PCI resource window */ [-- Attachment #3: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: Softlockup on boot with Cape Verde XT on many kernels 2015-01-15 6:21 ` Michel Dänzer @ 2015-01-15 20:33 ` Federico 2015-01-16 13:02 ` Federico 0 siblings, 1 reply; 26+ messages in thread From: Federico @ 2015-01-15 20:33 UTC (permalink / raw) To: Michel Dänzer, Maling list - DRI developers [-- Attachment #1.1: Type: text/plain, Size: 2934 bytes --] It works. - I applied the patch (manually), - recompiled Ubuntu 14.04's kernel 3.13.0-44-generic AMD64, - uninstalled Catalyst, - and removed nomodeset kernel parameter from grub. Ubuntu says I'm running Gallium 0.4 on AMD CAPE VERDE sudo lshw -c video [sudo] password for fede: *-display descripción: VGA compatible controller producto: Cape Verde XT [Radeon HD 7770/8760 / R7 250X] fabricante: Advanced Micro Devices, Inc. [AMD/ATI] id físico: 0 información del bus: pci@0000:01:00.0 versión: 00 anchura: 64 bits reloj: 33MHz capacidades: pm pciexpress msi vga_controller bus_master cap_list rom configuración: driver=radeon latency=0 recursos: irq:50 memoria:d0000000-dfffffff memoria:fde80000-fdebffff ioport:ee00(size=256) memoria:fde00000-fde1ffff It's working fine AFAIK. I player a few 1080 videos full screen, played duke nukem3d. Unity desktop seems fine. Here are some logs in case you want to see anything there. Xorg.log: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4299507/+files/Xorg.0.log dmesg: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4299508/+files/dmesg_working.txt lspci: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4299509/+files/lspci_working.txt I'd love to see this patch pushed everywhere. :-) 2015-01-15 3:21 GMT-03:00 Michel Dänzer <michel@daenzer.net>: > On 15.01.2015 12:53, Federico wrote: > > How about this? It seems at least related. > > > > https://github.com/alterapraxisptyltd/openatom/issues/1 > > > > Quote: > > [linux] Infinite loop in pci_get_rom_size() > > > > This is one of those issues that you find when putting supposedly stable > > code through unusual situations. I did expect any function in linux that > > is not part of radeon.ko to not be rock solid. Turns out that's not > > really the case. > > > > If we have a PCIR structure with a zero size length, the loop iterating > > through those structure does not advance. It simply does "image += > > readw(pds + 16) * 512;", but if that field is zero we're back analyzing > > the same structure on the next loop. The way to get out of this loop is > > to set bit 7 of the type field. That's what 'last_image' does. If that > > bit is not set, with the above, that's an infinite loop. > > > > Luckily, it doesn't crash the kernel, but it hangs any driver that calls > > the function under said circumstances. No more modprobe -r or unbinding. > > Reboot is needed. No idea why a firmware blob here is treated as trusted > > input. > > That could indeed explain it, does the attached patch help? > > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Mesa and X developer > [-- Attachment #1.2: Type: text/html, Size: 4343 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Softlockup on boot with Cape Verde XT on many kernels 2015-01-15 20:33 ` Federico @ 2015-01-16 13:02 ` Federico 2015-01-19 8:53 ` Michel Dänzer 0 siblings, 1 reply; 26+ messages in thread From: Federico @ 2015-01-16 13:02 UTC (permalink / raw) To: Michel Dänzer, Maling list - DRI developers [-- Attachment #1.1: Type: text/plain, Size: 295 bytes --] I left the machine running all night with no issues. What would be the best way for me to help get this solution integrated in future kernels? Should I file a bug in the kernel's bugzilla? I guess this isn't a radeon bug. Should I bring the problem/solution to the kernel mailing list? Thanks. [-- Attachment #1.2: Type: text/html, Size: 410 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH v2] pci: Fix infinite loop with ROM image of size 0 2015-01-16 13:02 ` Federico @ 2015-01-19 8:53 ` Michel Dänzer 0 siblings, 0 replies; 26+ messages in thread From: Michel Dänzer @ 2015-01-19 8:53 UTC (permalink / raw) To: Bjorn Helgaas; +Cc: linux-pci, linux-kernel, Federico, dri-devel From: Michel Dänzer <michel.daenzer@amd.com> If the image size would ever read as 0, pci_get_rom_size could keep processing the same image over and over again. Reported-by: Federico <federicotg@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> --- v2: * Use unsigned instead of u16 for the local length variable (not sure if the multiplication by 512 could overflow otherwise) * Integrate length condition into while statement * Add stable tag drivers/pci/rom.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c index f955edb..eb0ad53 100644 --- a/drivers/pci/rom.c +++ b/drivers/pci/rom.c @@ -71,6 +71,7 @@ size_t pci_get_rom_size(struct pci_dev *pdev, void __iomem *rom, size_t size) { void __iomem *image; int last_image; + unsigned length; image = rom; do { @@ -93,9 +94,9 @@ size_t pci_get_rom_size(struct pci_dev *pdev, void __iomem *rom, size_t size) if (readb(pds + 3) != 'R') break; last_image = readb(pds + 21) & 0x80; - /* this length is reliable */ - image += readw(pds + 16) * 512; - } while (!last_image); + length = readw(pds + 16); + image += length * 512; + } while (length && !last_image); /* never return a size larger than the PCI resource window */ /* there are known ROMs that get the size wrong */ -- 2.1.4 ^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH v2] pci: Fix infinite loop with ROM image of size 0 @ 2015-01-19 8:53 ` Michel Dänzer 0 siblings, 0 replies; 26+ messages in thread From: Michel Dänzer @ 2015-01-19 8:53 UTC (permalink / raw) To: Bjorn Helgaas; +Cc: linux-pci, linux-kernel, dri-devel From: Michel Dänzer <michel.daenzer@amd.com> If the image size would ever read as 0, pci_get_rom_size could keep processing the same image over and over again. Reported-by: Federico <federicotg@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> --- v2: * Use unsigned instead of u16 for the local length variable (not sure if the multiplication by 512 could overflow otherwise) * Integrate length condition into while statement * Add stable tag drivers/pci/rom.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c index f955edb..eb0ad53 100644 --- a/drivers/pci/rom.c +++ b/drivers/pci/rom.c @@ -71,6 +71,7 @@ size_t pci_get_rom_size(struct pci_dev *pdev, void __iomem *rom, size_t size) { void __iomem *image; int last_image; + unsigned length; image = rom; do { @@ -93,9 +94,9 @@ size_t pci_get_rom_size(struct pci_dev *pdev, void __iomem *rom, size_t size) if (readb(pds + 3) != 'R') break; last_image = readb(pds + 21) & 0x80; - /* this length is reliable */ - image += readw(pds + 16) * 512; - } while (!last_image); + length = readw(pds + 16); + image += length * 512; + } while (length && !last_image); /* never return a size larger than the PCI resource window */ /* there are known ROMs that get the size wrong */ -- 2.1.4 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: [PATCH v2] pci: Fix infinite loop with ROM image of size 0 2015-01-19 8:53 ` Michel Dänzer (?) @ 2015-01-19 18:48 ` Alex Deucher -1 siblings, 0 replies; 26+ messages in thread From: Alex Deucher @ 2015-01-19 18:48 UTC (permalink / raw) To: Michel Dänzer Cc: Bjorn Helgaas, Linux PCI, LKML, Maling list - DRI developers On Mon, Jan 19, 2015 at 3:53 AM, Michel Dänzer <michel@daenzer.net> wrote: > From: Michel Dänzer <michel.daenzer@amd.com> > > If the image size would ever read as 0, pci_get_rom_size could keep > processing the same image over and over again. > > Reported-by: Federico <federicotg@gmail.com> > Cc: stable@vger.kernel.org > Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> > --- > > v2: > * Use unsigned instead of u16 for the local length variable (not sure if > the multiplication by 512 could overflow otherwise) > * Integrate length condition into while statement > * Add stable tag > > drivers/pci/rom.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c > index f955edb..eb0ad53 100644 > --- a/drivers/pci/rom.c > +++ b/drivers/pci/rom.c > @@ -71,6 +71,7 @@ size_t pci_get_rom_size(struct pci_dev *pdev, void __iomem *rom, size_t size) > { > void __iomem *image; > int last_image; > + unsigned length; > > image = rom; > do { > @@ -93,9 +94,9 @@ size_t pci_get_rom_size(struct pci_dev *pdev, void __iomem *rom, size_t size) > if (readb(pds + 3) != 'R') > break; > last_image = readb(pds + 21) & 0x80; > - /* this length is reliable */ > - image += readw(pds + 16) * 512; > - } while (!last_image); > + length = readw(pds + 16); > + image += length * 512; > + } while (length && !last_image); > > /* never return a size larger than the PCI resource window */ > /* there are known ROMs that get the size wrong */ > -- > 2.1.4 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2] pci: Fix infinite loop with ROM image of size 0 2015-01-19 8:53 ` Michel Dänzer @ 2015-01-23 23:51 ` Bjorn Helgaas -1 siblings, 0 replies; 26+ messages in thread From: Bjorn Helgaas @ 2015-01-23 23:51 UTC (permalink / raw) To: Michel Dänzer; +Cc: linux-pci, linux-kernel, Federico, dri-devel On Mon, Jan 19, 2015 at 05:53:20PM +0900, Michel Dänzer wrote: > From: Michel Dänzer <michel.daenzer@amd.com> > > If the image size would ever read as 0, pci_get_rom_size could keep > processing the same image over and over again. > > Reported-by: Federico <federicotg@gmail.com> > Cc: stable@vger.kernel.org > Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Applied with Alex's ack to pci/resource for v3.20, thanks! > --- > > v2: > * Use unsigned instead of u16 for the local length variable (not sure if > the multiplication by 512 could overflow otherwise) > * Integrate length condition into while statement > * Add stable tag > > drivers/pci/rom.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c > index f955edb..eb0ad53 100644 > --- a/drivers/pci/rom.c > +++ b/drivers/pci/rom.c > @@ -71,6 +71,7 @@ size_t pci_get_rom_size(struct pci_dev *pdev, void __iomem *rom, size_t size) > { > void __iomem *image; > int last_image; > + unsigned length; > > image = rom; > do { > @@ -93,9 +94,9 @@ size_t pci_get_rom_size(struct pci_dev *pdev, void __iomem *rom, size_t size) > if (readb(pds + 3) != 'R') > break; > last_image = readb(pds + 21) & 0x80; > - /* this length is reliable */ > - image += readw(pds + 16) * 512; > - } while (!last_image); > + length = readw(pds + 16); > + image += length * 512; > + } while (length && !last_image); > > /* never return a size larger than the PCI resource window */ > /* there are known ROMs that get the size wrong */ > -- > 2.1.4 > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2] pci: Fix infinite loop with ROM image of size 0 @ 2015-01-23 23:51 ` Bjorn Helgaas 0 siblings, 0 replies; 26+ messages in thread From: Bjorn Helgaas @ 2015-01-23 23:51 UTC (permalink / raw) To: Michel Dänzer; +Cc: linux-pci, linux-kernel, dri-devel, Federico On Mon, Jan 19, 2015 at 05:53:20PM +0900, Michel Dänzer wrote: > From: Michel Dänzer <michel.daenzer@amd.com> > > If the image size would ever read as 0, pci_get_rom_size could keep > processing the same image over and over again. > > Reported-by: Federico <federicotg@gmail.com> > Cc: stable@vger.kernel.org > Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Applied with Alex's ack to pci/resource for v3.20, thanks! > --- > > v2: > * Use unsigned instead of u16 for the local length variable (not sure if > the multiplication by 512 could overflow otherwise) > * Integrate length condition into while statement > * Add stable tag > > drivers/pci/rom.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c > index f955edb..eb0ad53 100644 > --- a/drivers/pci/rom.c > +++ b/drivers/pci/rom.c > @@ -71,6 +71,7 @@ size_t pci_get_rom_size(struct pci_dev *pdev, void __iomem *rom, size_t size) > { > void __iomem *image; > int last_image; > + unsigned length; > > image = rom; > do { > @@ -93,9 +94,9 @@ size_t pci_get_rom_size(struct pci_dev *pdev, void __iomem *rom, size_t size) > if (readb(pds + 3) != 'R') > break; > last_image = readb(pds + 21) & 0x80; > - /* this length is reliable */ > - image += readw(pds + 16) * 512; > - } while (!last_image); > + length = readw(pds + 16); > + image += length * 512; > + } while (length && !last_image); > > /* never return a size larger than the PCI resource window */ > /* there are known ROMs that get the size wrong */ > -- > 2.1.4 > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2015-01-23 23:51 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-01-11 1:58 Softlockup on boot with Cape Verde XT on many kernels Federico
2015-01-11 17:19 ` Alex Deucher
[not found] ` <CAFUqUc7qXoNQJwyXJtcx=6gmG0hwnHeor-NyfoPPchX9EYTDzA@mail.gmail.com>
2015-01-11 19:44 ` Fwd: " Federico
2015-01-11 20:27 ` Federico
2015-01-12 21:48 ` Alex Deucher
2015-01-12 23:34 ` Federico
2015-01-13 7:06 ` Michel Dänzer
2015-01-13 18:20 ` Federico
2015-01-14 2:19 ` Michel Dänzer
2015-01-14 3:41 ` Federico
2015-01-14 3:54 ` Michel Dänzer
2015-01-14 13:29 ` Federico
2015-01-15 0:10 ` Federico
2015-01-15 2:10 ` Federico
2015-01-15 2:46 ` Michel Dänzer
2015-01-15 2:59 ` Federico
2015-01-15 3:14 ` Federico
2015-01-15 3:53 ` Federico
2015-01-15 6:21 ` Michel Dänzer
2015-01-15 20:33 ` Federico
2015-01-16 13:02 ` Federico
2015-01-19 8:53 ` [PATCH v2] pci: Fix infinite loop with ROM image of size 0 Michel Dänzer
2015-01-19 8:53 ` Michel Dänzer
2015-01-19 18:48 ` Alex Deucher
2015-01-23 23:51 ` Bjorn Helgaas
2015-01-23 23:51 ` Bjorn Helgaas
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.