From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Michel_D=c3=a4nzer?= Subject: Re: Softlockup on boot with Cape Verde XT on many kernels Date: Thu, 15 Jan 2015 15:21:29 +0900 Message-ID: <54B75C69.4070907@daenzer.net> References: <54B4C3FE.5090707@daenzer.net> <54B5D21B.3090701@daenzer.net> <54B5E881.4090003@daenzer.net> <54B72A15.9090206@daenzer.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------080904000208050407090209" Return-path: Received: from mail.gna.ch (darkcity.gna.ch [195.226.6.51]) by gabe.freedesktop.org (Postfix) with ESMTP id 290896E0AF for ; Wed, 14 Jan 2015 22:21:37 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Federico Cc: Maling list - DRI developers List-Id: dri-devel@lists.freedesktop.org This is a multi-part message in MIME format. --------------080904000208050407090209 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 15.01.2015 12:53, Federico wrote: > How about this? It seems at least related. >=20 > https://github.com/alterapraxisptyltd/openatom/issues/1 >=20 > Quote: > [linux] Infinite loop in pci_get_rom_size() >=20 > This is one of those issues that you find when putting supposedly stabl= e > code through unusual situations. I did expect any function in linux tha= t > is not part of radeon.ko to not be rock solid. Turns out that's not > really the case. >=20 > If we have a PCIR structure with a zero size length, the loop iterating > through those structure does not advance. It simply does "image +=3D > 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. >=20 > Luckily, it doesn't crash the kernel, but it hangs any driver that call= s > the function under said circumstances. No more modprobe -r or unbinding= . > Reboot is needed. No idea why a firmware blob here is treated as truste= d > input. That could indeed explain it, does the attached patch help? --=20 Earthling Michel D=C3=A4nzer | http://www.amd= .com Libre software enthusiast | Mesa and X developer --------------080904000208050407090209 Content-Type: text/x-patch; name="pci_get_rom_size.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pci_get_rom_size.diff" 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 __io= mem *rom, size_t size) image =3D rom; do { void __iomem *pds; + u16 length; /* Standard PCI ROMs start out with these bytes 55 AA */ if (readb(image) !=3D 0x55) { dev_err(&pdev->dev, "Invalid ROM contents\n"); @@ -93,8 +94,10 @@ size_t pci_get_rom_size(struct pci_dev *pdev, void __i= omem *rom, size_t size) if (readb(pds + 3) !=3D 'R') break; last_image =3D readb(pds + 21) & 0x80; - /* this length is reliable */ - image +=3D readw(pds + 16) * 512; + length =3D readw(pds + 16); + if (!length) + break; + image +=3D length * 512; } while (!last_image); =20 /* never return a size larger than the PCI resource window */ --------------080904000208050407090209 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --------------080904000208050407090209--