Softlockup on boot with Cape Verde XT on many kernels

Softlockup on boot with Cape Verde XT on many kernels

[Federico]

[-- 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

Re: Softlockup on boot with Cape Verde XT on many kernels

[Alex Deucher]

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

Fwd: Softlockup on boot with Cape Verde XT on many kernels

[Federico]

[-- 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

Re: Softlockup on boot with Cape Verde XT on many kernels

[Federico]

[-- 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

Re: Softlockup on boot with Cape Verde XT on many kernels

[Alex Deucher]

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

Re: Softlockup on boot with Cape Verde XT on many kernels

[Federico]

[-- 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

Re: Softlockup on boot with Cape Verde XT on many kernels

[Michel Dänzer]

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

Re: Softlockup on boot with Cape Verde XT on many kernels

[Federico]

[-- 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

Re: Softlockup on boot with Cape Verde XT on many kernels

[Michel Dänzer]

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

Re: Softlockup on boot with Cape Verde XT on many kernels

[Federico]

[-- 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

Re: Softlockup on boot with Cape Verde XT on many kernels

[Michel Dänzer]

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

Re: Softlockup on boot with Cape Verde XT on many kernels

[Federico]

[-- 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

Re: Softlockup on boot with Cape Verde XT on many kernels

[Federico]

[-- 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

Re: Softlockup on boot with Cape Verde XT on many kernels

[Federico]

[-- 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

Re: Softlockup on boot with Cape Verde XT on many kernels

[Michel Dänzer]

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

Re: Softlockup on boot with Cape Verde XT on many kernels

[Federico]

[-- 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

Re: Softlockup on boot with Cape Verde XT on many kernels

[Federico]

[-- 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

Re: Softlockup on boot with Cape Verde XT on many kernels

[Federico]

[-- 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

Re: Softlockup on boot with Cape Verde XT on many kernels

[Michel Dänzer]

[-- 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

Re: Softlockup on boot with Cape Verde XT on many kernels

[Federico]

[-- 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

Re: Softlockup on boot with Cape Verde XT on many kernels

[Federico]

[-- 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

[PATCH v2] pci: Fix infinite loop with ROM image of size 0

[Michel Dänzer]

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

[PATCH v2] pci: Fix infinite loop with ROM image of size 0

[Michel Dänzer]

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

Re: [PATCH v2] pci: Fix infinite loop with ROM image of size 0

[Alex Deucher]

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

Re: [PATCH v2] pci: Fix infinite loop with ROM image of size 0

[Alex Deucher]

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

Re: [PATCH v2] pci: Fix infinite loop with ROM image of size 0

[Bjorn Helgaas]

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
> 

Re: [PATCH v2] pci: Fix infinite loop with ROM image of size 0

[Bjorn Helgaas]

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