Linux 3.7-rc1 (nouveau_bios_score oops).
On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> On 20.10.2012, Marcin Slusarz wrote:
>
> > Try this one.
>
> It works, now I can boot again. However, nouveau seems to be dead now.
> The dmesg output with your patch on top of 3.7-rc1 is:
>
> [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on
> minor 0
> [3.687784] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1
> [3.689960] nouveau [ DEVICE][:01:00.0] Chipset: GT218 (NVA8)
> [3.692471] nouveau [ DEVICE][:01:00.0] Family : NV50
> [3.695716] nouveau [ VBIOS][:01:00.0] checking PRAMIN for image...
> [3.697087] nouveau [ VBIOS][:01:00.0] ... signature not found
> [3.698471] nouveau [ VBIOS][:01:00.0] checking PROM for image...
> [3.699838] nouveau [ VBIOS][:01:00.0] ... signature not found
> [3.701223] nouveau [ VBIOS][:01:00.0] checking ACPI for image...
> [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond
> end of region [VROM] (length 24) (20120913/exfldio-210)
> [3.704139] ACPI Error: Method parse/execution
> failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8),
> AE_AML_REGION_LIMIT (20120913/psparse-536)
> [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT
> [3.718776] nouveau [ VBIOS][:01:00.0] ... signature not found
> [3.721349] nouveau [ VBIOS][:01:00.0] checking PCIROM for image...
> [3.724111] nouveau :01:00.0: Invalid ROM contents
> [3.726663] nouveau [ VBIOS][:01:00.0] ... signature not found
> [3.729159] nouveau E[ VBIOS][:01:00.0] unable to locate usable image
> [3.731677] nouveau E[ DEVICE][:01:00.0] failed to create 0x1001,
> -22
> [3.734231] nouveau E[ DRM] failed to create 0x8080, -22
> [3.736097] nouveau: probe of :01:00.0 failed with error -22
> [3.740523] dracut: Starting plymouth daemon
Hmm, maybe we can't fetch 3 bytes only...
Let's check this:
---
diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
index 824eea0..8bd71aa 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
@@ -192,14 +192,16 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
{
struct pci_dev *pdev = nv_device(bios)->pdev;
int ret, cnt, i;
- u8 data[3];
+ u8 *data;
if (!nouveau_acpi_rom_supported(pdev))
return;
bios->size = 0;
- if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
+ data = kmalloc(4096, GFP_KERNEL);
+ if (data && nouveau_acpi_get_bios_chunk(data, 0, 4096) >= 3)
bios->size = data[2] * 512;
+ kfree(data);
if (!bios->size)
return;
---
Please attach acpidump output.
[REGRESSION] nouveau: Severe screen corruption on (0xaf, nv50)
On Thu, Oct 18, 2012 at 11:58:09AM +0200, Henrik Rydberg wrote: > Hi Ben, > > 3.7-rc1 messed up the screen on my MacBookAir3,1 (nv50, 0xaf) pretty > badly. Not surprisingly, > > commit 3863c9bc887e9638a9d905d55f6038641ece78d6 > Author: Ben Skeggs > Date: Sat Jul 14 19:09:17 2012 +1000 > > drm/nouveau/instmem: completely new implementation, as a subdev module > > is the first bad commit. Standing on that commit, booting and then > starting X yields the output below. Hints are especially appreciated, > considering the patch is almost 8000 lines. Going through one suspend/resume cycle makes the corruption go away, and there are no more errors in dmesg. Oddly enough, I have seen something very similar when using i915 on the MBP10. Builtin modules and systemd in both cases. Maybe this is a general drm issue. Any thoughts? Thanks, Henrik
[PATCH 2/2] drm: fb: cma: Fail gracefully on allocation failure
On Sat, Oct 20, 2012 at 12:32:47PM +0200, Thierry Reding wrote: > The drm_gem_cma_create() function never returns NULL but rather an error > encoded in the return value using the ERR_PTR() macro. Callers therefore > need to check for errors using the IS_ERR() macro. This change allows > drivers to handle contiguous DMA allocation failures gracefully. > > Signed-off-by: Thierry Reding Acked-by: Sascha Hauer Sascha > --- > drivers/gpu/drm/drm_fb_cma_helper.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c > b/drivers/gpu/drm/drm_fb_cma_helper.c > index d6c80a3..fd9d0af 100644 > --- a/drivers/gpu/drm/drm_fb_cma_helper.c > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c > @@ -220,7 +220,7 @@ static int drm_fbdev_cma_create(struct drm_fb_helper > *helper, > > size = mode_cmd.pitches[0] * mode_cmd.height; > obj = drm_gem_cma_create(dev, size); > - if (!obj) > + if (IS_ERR(obj)) > return -ENOMEM; > > fbi = framebuffer_alloc(0, dev->dev); > -- > 1.7.12.4 > > -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Linux 3.7-rc1 (nouveau_bios_score oops).
On Sun, Oct 21, 2012 at 08:58:07AM +0200, Pawe? Sikora wrote:
> On Sunday 21 of October 2012 00:19:48 Marcin Slusarz wrote:
> > On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> > > On 20.10.2012, Marcin Slusarz wrote:
> > >
> > > > Try this one.
> > >
> > > It works, now I can boot again. However, nouveau seems to be dead now.
> > > The dmesg output with your patch on top of 3.7-rc1 is:
> > >
> > > [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on
> > > minor 0
> > > [3.687784] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1
> > > [3.689960] nouveau [ DEVICE][:01:00.0] Chipset: GT218 (NVA8)
> > > [3.692471] nouveau [ DEVICE][:01:00.0] Family : NV50
> > > [3.695716] nouveau [ VBIOS][:01:00.0] checking PRAMIN for
> > > image...
> > > [3.697087] nouveau [ VBIOS][:01:00.0] ... signature not found
> > > [3.698471] nouveau [ VBIOS][:01:00.0] checking PROM for
> > > image...
> > > [3.699838] nouveau [ VBIOS][:01:00.0] ... signature not found
> > > [3.701223] nouveau [ VBIOS][:01:00.0] checking ACPI for
> > > image...
> > > [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is
> > > beyond end of region [VROM] (length 24) (20120913/exfldio-210)
> > > [3.704139] ACPI Error: Method parse/execution
> > > failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8),
> > > AE_AML_REGION_LIMIT (20120913/psparse-536)
> > > [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT
> > > [3.718776] nouveau [ VBIOS][:01:00.0] ... signature not found
> > > [3.721349] nouveau [ VBIOS][:01:00.0] checking PCIROM for
> > > image...
> > > [3.724111] nouveau :01:00.0: Invalid ROM contents
> > > [3.726663] nouveau [ VBIOS][:01:00.0] ... signature not found
> > > [3.729159] nouveau E[ VBIOS][:01:00.0] unable to locate usable
> > > image
> > > [3.731677] nouveau E[ DEVICE][:01:00.0] failed to create
> > > 0x1001, -22
> > > [3.734231] nouveau E[ DRM] failed to create 0x8080, -22
> > > [3.736097] nouveau: probe of :01:00.0 failed with error -22
> > > [3.740523] dracut: Starting plymouth daemon
> >
> > Hmm, maybe we can't fetch 3 bytes only...
> >
> > Let's check this:
> >
> > ---
> > diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> > b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> > index 824eea0..8bd71aa 100644
> > --- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> > +++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> > @@ -192,14 +192,16 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
> > {
> > struct pci_dev *pdev = nv_device(bios)->pdev;
> > int ret, cnt, i;
> > - u8 data[3];
> > + u8 *data;
> >
> > if (!nouveau_acpi_rom_supported(pdev))
> > return;
> >
> > bios->size = 0;
> > - if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
> > + data = kmalloc(4096, GFP_KERNEL);
> > + if (data && nouveau_acpi_get_bios_chunk(data, 0, 4096) >= 3)
> > bios->size = data[2] * 512;
> > + kfree(data);
> > if (!bios->size)
> > return;
>
> with these both patches applied my laptop boots and gui works fine.
> here's dmesg:
>
> (...)
> [8.751795] nouveau [ VBIOS][:01:00.0] ... appears to be valid
> [8.751798] nouveau [ VBIOS][:01:00.0] using image from ACPI
> [8.751895] nouveau [ VBIOS][:01:00.0] BIT signature found
> [8.751898] nouveau [ VBIOS][:01:00.0] version 70.08.45.00
> [8.752366] nouveau [ DEVINIT][:01:00.0] adaptor not initialised
> [8.752368] nouveau [ VBIOS][:01:00.0] running init tables
> [8.867660] nouveau [ MXM][:01:00.0] no VBIOS data, nothing to do
> [8.867690] nouveau [ PFB][:01:00.0] RAM type: DDR3
> [8.867692] nouveau [ PFB][:01:00.0] RAM size: 512 MiB
> [8.901523] vga_switcheroo: enabled
> [8.901979] [TTM] Zone kernel: Available graphics memory: 6104282 kiB
> [8.901980] [TTM] Zone dma32: Available graphics memory: 2097152 kiB
> [8.901982] [TTM] Initializing pool allocator
> [8.902014] [TTM] Initializing DMA pool allocator
> [8.902180] mtrr: type mismatch for c000,1000 old: write-back new:
> write-combining
> [8.902184] nouveau [ DRM] VRAM: 512 MiB
> [8.902185] nouveau [ DRM] GART: 512 MiB
> [8.902188] nouveau [ DRM] BIT BIOS found
> [8.902190] nouveau [ DRM] Bios version 70.08.45.00
> [8.902192] nouveau [ DRM] TMDS table version 2.0
> [8.902194] nouveau [ DRM] DCB version 4.0
> [8.902196] nouveau [ DRM] DCB outp 00: 02011300
> [8.902198] nouveau [ DRM] DCB conn 01: 0100
> [8.903540] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [8.903541] [drm] No driver support for vblank timestamp query.
> [8.903545] nouveau [ DRM] ACPI backlight
Linux 3.7-rc1 (nouveau_bios_score oops).
On Sun, Oct 21, 2012 at 5:09 AM, Marcin Slusarz wrote: > > This looks like ACPI bug... I'm _shocked_ to hear that firmware would be fragile. Anyway, here's the #1 thing to keep in mind about firmware: - firmware is *always* buggy. It's that simple. Don't expect anything else. Firmware is written by people who have lost the will to live (why? Because they do firmware development for a living), and the only thing keeping them going is the drugs. And they're not the "fun" kind of drugs. The end result is predictable. In their drug-induced haze, they make a mess. So saying "ACPI is buggy" is like saying "water is wet". Deal with it. > Nouveau calls this method: [...] > > with Arg0 == 0, Arg1 == 3 and gets: > > ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond end of region > [VROM] (length 24) (20120913/exfldio-210) > ACPI Error: Method parse/execution failed [\_SB_.PCI0.PEGR.GFX0._ROM] (Node > 88033e47fe88), AE_AML_REGION_LIMIT (20120913/psparse-536) > > We can workaround it by aligning Arg1 to 4096 (I'm wondering what is the > minimal > value), but do we really have to? Yes, you really have to. You need to understand that ACPI has been tested with one thing, and one thing only: Windows. Clearly windows doesn't ask for some three-byte region. So it doesn't work. Big surprise. Untested code written by monkeys on crack - what did you expect? So don't do "clever" things. When it comes to firmware, you need to expect it to be buggy, and try to access it the way Windows accesses it. Now, whether Windows realy always does things with a 4kB-aligned access, or whether you just need to make sure that you're (say) 4-byte-aligned, I don't know. Maybe doing things four (or eight, or sixteen) bytes at a time will work. You can try. But if we know from past experience that a 4kB block-size will work, I'd suggest just saying "It's stupid, but stupid is good - we're working with firmware" Think of firmware the way you think of hardware: it's buggy and needs workarounds. Linus
Linux 3.7-rc1 (nouveau_bios_score oops).
On Sun, Oct 21, 2012 at 07:38:58AM -0700, Linus Torvalds wrote: > On Sun, Oct 21, 2012 at 5:09 AM, Marcin Slusarz > wrote: > > > > This looks like ACPI bug... > > I'm _shocked_ to hear that firmware would be fragile. > > Anyway, here's the #1 thing to keep in mind about firmware: > > - firmware is *always* buggy. I know. But this bug is not about broken firmware. It's about Linux kernel ACPI implementation, which (I think) wrongly interprets ACPI script. Marcin
Linux 3.7-rc1 (nouveau_bios_score oops).
On Sun, Oct 21, 2012 at 5:49 PM, Marcin Slusarz wrote: > > I know. But this bug is not about broken firmware. It's about Linux kernel > ACPI implementation, which (I think) wrongly interprets ACPI script. Hmm. Len, care to comment? Marcin quoted the AML and our arguments in an earlier thing. I don't read AML, so I was assuming it's the AML itself that was buggy, not our interpretation of it.. Linus
[Bug 39612] radeon blocks with new style fencing
https://bugzilla.kernel.org/show_bug.cgi?id=39612 --- Comment #4 from Linas 2012-10-21 19:31:38 --- Created an attachment (id=84201) --> (https://bugzilla.kernel.org/attachment.cgi?id=84201) Xorg log mieq Testing with 3.6.2, radeon.no_wb=1 is still needed, although it seems a bit better. You can get -with a little difficulty- to switch virtual terminals, so it is possible to SIGINT the xserver. Interestingly, although the first startx leads to a blank screen, a second startx runs the DE without being apparently affected. ?! Booting with radeon.no_wb=1 the DE shows directly the first time, as it should. In one failed instance, the Xorg log showed errors of ?[mi] EQ overflowing.?, ?[mi] EQ overflow continuing. 100 events have been dropped.?, ?[mi] EQ overflow continuing. 200 events have been dropped.?... I am attaching this log. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 39612] radeon blocks with new style fencing
https://bugzilla.kernel.org/show_bug.cgi?id=39612 --- Comment #5 from Linas 2012-10-21 19:34:45 --- Created an attachment (id=84211) --> (https://bugzilla.kernel.org/attachment.cgi?id=84211) Other Xorg log Another failed Xorg log, this time without overflowing errors. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
Linux 3.7-rc1 (nouveau_bios_score oops).
On Sunday 21 of October 2012 00:19:48 Marcin Slusarz wrote:
> On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> > On 20.10.2012, Marcin Slusarz wrote:
> >
> > > Try this one.
> >
> > It works, now I can boot again. However, nouveau seems to be dead now.
> > The dmesg output with your patch on top of 3.7-rc1 is:
> >
> > [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on
> > minor 0
> > [3.687784] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1
> > [3.689960] nouveau [ DEVICE][:01:00.0] Chipset: GT218 (NVA8)
> > [3.692471] nouveau [ DEVICE][:01:00.0] Family : NV50
> > [3.695716] nouveau [ VBIOS][:01:00.0] checking PRAMIN for
> > image...
> > [3.697087] nouveau [ VBIOS][:01:00.0] ... signature not found
> > [3.698471] nouveau [ VBIOS][:01:00.0] checking PROM for image...
> > [3.699838] nouveau [ VBIOS][:01:00.0] ... signature not found
> > [3.701223] nouveau [ VBIOS][:01:00.0] checking ACPI for image...
> > [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond
> > end of region [VROM] (length 24) (20120913/exfldio-210)
> > [3.704139] ACPI Error: Method parse/execution
> > failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8),
> > AE_AML_REGION_LIMIT (20120913/psparse-536)
> > [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT
> > [3.718776] nouveau [ VBIOS][:01:00.0] ... signature not found
> > [3.721349] nouveau [ VBIOS][:01:00.0] checking PCIROM for
> > image...
> > [3.724111] nouveau :01:00.0: Invalid ROM contents
> > [3.726663] nouveau [ VBIOS][:01:00.0] ... signature not found
> > [3.729159] nouveau E[ VBIOS][:01:00.0] unable to locate usable
> > image
> > [3.731677] nouveau E[ DEVICE][:01:00.0] failed to create
> > 0x1001, -22
> > [3.734231] nouveau E[ DRM] failed to create 0x8080, -22
> > [3.736097] nouveau: probe of :01:00.0 failed with error -22
> > [3.740523] dracut: Starting plymouth daemon
>
> Hmm, maybe we can't fetch 3 bytes only...
>
> Let's check this:
>
> ---
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> index 824eea0..8bd71aa 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> @@ -192,14 +192,16 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
> {
> struct pci_dev *pdev = nv_device(bios)->pdev;
> int ret, cnt, i;
> - u8 data[3];
> + u8 *data;
>
> if (!nouveau_acpi_rom_supported(pdev))
> return;
>
> bios->size = 0;
> - if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
> + data = kmalloc(4096, GFP_KERNEL);
> + if (data && nouveau_acpi_get_bios_chunk(data, 0, 4096) >= 3)
> bios->size = data[2] * 512;
> + kfree(data);
> if (!bios->size)
> return;
with these both patches applied my laptop boots and gui works fine.
here's dmesg:
(...)
[8.751795] nouveau [ VBIOS][:01:00.0] ... appears to be valid
[8.751798] nouveau [ VBIOS][:01:00.0] using image from ACPI
[8.751895] nouveau [ VBIOS][:01:00.0] BIT signature found
[8.751898] nouveau [ VBIOS][:01:00.0] version 70.08.45.00
[8.752366] nouveau [ DEVINIT][:01:00.0] adaptor not initialised
[8.752368] nouveau [ VBIOS][:01:00.0] running init tables
[8.867660] nouveau [ MXM][:01:00.0] no VBIOS data, nothing to do
[8.867690] nouveau [ PFB][:01:00.0] RAM type: DDR3
[8.867692] nouveau [ PFB][:01:00.0] RAM size: 512 MiB
[8.901523] vga_switcheroo: enabled
[8.901979] [TTM] Zone kernel: Available graphics memory: 6104282 kiB
[8.901980] [TTM] Zone dma32: Available graphics memory: 2097152 kiB
[8.901982] [TTM] Initializing pool allocator
[8.902014] [TTM] Initializing DMA pool allocator
[8.902180] mtrr: type mismatch for c000,1000 old: write-back new:
write-combining
[8.902184] nouveau [ DRM] VRAM: 512 MiB
[8.902185] nouveau [ DRM] GART: 512 MiB
[8.902188] nouveau [ DRM] BIT BIOS found
[8.902190] nouveau [ DRM] Bios version 70.08.45.00
[8.902192] nouveau [ DRM] TMDS table version 2.0
[8.902194] nouveau [ DRM] DCB version 4.0
[8.902196] nouveau [ DRM] DCB outp 00: 02011300
[8.902198] nouveau [ DRM] DCB conn 01: 0100
[8.903540] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[8.903541] [drm] No driver support for vblank timestamp query.
[8.903545] nouveau [ DRM] ACPI backlight interface available, not
registering our own
[8.903938] nouveau [ DRM] 3 available performance level(s)
[8.903941] nouveau [ DRM] 0: core 50MHz shader 101MHz memory 135MHz
voltage 830mV
[8.903943] nouveau [ DRM] 1: c
Linux 3.7-rc1 (nouveau_bios_score oops).
On 21.10.2012, Marcin Slusarz wrote: > On 3.6 kernel? (It doesn't exist on 3.7) > Note that it may be in other directory than "0". [root at wildsau linux-3.6.2]# cat .config | grep -i "nouveau" CONFIG_DRM_NOUVEAU=m CONFIG_DRM_NOUVEAU_BACKLIGHT=y CONFIG_DRM_NOUVEAU_DEBUG=y I grepped the whole disk, there's no vbios.rom at all.
Linux 3.7-rc1 (nouveau_bios_score oops).
On 21.10.2012, Pawe? Sikora wrote: > with these both patches applied my laptop boots and gui works fine. The same here. The two patches together, applied to 3.7-rc1 let my machine boot again. Here's the relevant dmesg cut: [3.702671] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1 [3.704643] nouveau [ DEVICE][:01:00.0] Chipset: GT218 (NVA8) [3.707003] nouveau [ DEVICE][:01:00.0] Family : NV50 [3.711393] nouveau [ VBIOS][:01:00.0] checking PRAMIN for image... [3.712793] nouveau [ VBIOS][:01:00.0] ... signature not found [3.714147] nouveau [ VBIOS][:01:00.0] checking PROM for image... [3.715578] nouveau [ VBIOS][:01:00.0] ... signature not found [3.716969] nouveau [ VBIOS][:01:00.0] checking ACPI for image... [4.207512] nouveau [ VBIOS][:01:00.0] ... appears to be valid [4.209711] nouveau [ VBIOS][:01:00.0] using image from ACPI [4.212469] nouveau [ VBIOS][:01:00.0] BIT signature found [4.214855] nouveau [ VBIOS][:01:00.0] version 70.18.5d.00 [4.217554] nouveau [ DEVINIT][:01:00.0] adaptor not initialised [4.219922] nouveau [ VBIOS][:01:00.0] running init tables [4.342202] nouveau [ MXM][:01:00.0] no VBIOS data, nothing to do [4.343590] nouveau [ PFB][:01:00.0] RAM type: DDR3 [4.344916] nouveau [ PFB][:01:00.0] RAM size: 1024 MiB [4.991887] vga_switcheroo: enabled [4.993495] [TTM] Zone kernel: Available graphics memory: 1917720 kiB [4.994911] [TTM] Initializing pool allocator [4.996228] [TTM] Initializing DMA pool allocator [4.998915] nouveau [ DRM] VRAM: 1024 MiB [5.000251] nouveau [ DRM] GART: 512 MiB [5.001579] nouveau [ DRM] BIT BIOS found [5.002904] nouveau [ DRM] Bios version 70.18.5d.00 [5.004229] nouveau [ DRM] TMDS table version 2.0 [5.005545] nouveau [ DRM] DCB version 4.0 [5.006810] nouveau [ DRM] DCB outp 00: 02014300 [5.008115] nouveau [ DRM] DCB conn 00: 0040 [5.009441] nouveau [ DRM] DCB conn 01: 00410146 [5.010745] nouveau [ DRM] DCB conn 02: 1261 [5.012019] nouveau [ DRM] DCB conn 03: 2330 [5.013255] nouveau [ DRM] DCB conn 04: 0400 [5.014452] nouveau [ DRM] DCB conn 05: 0560 [5.052344] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [5.053486] [drm] No driver support for vblank timestamp query. [5.054590] nouveau [ DRM] ACPI backlight interface available,not registering our own [5.356822] nouveau [ DRM] 3 available performance level(s) [5.358682] nouveau [ DRM] 0: core 135MHz shader 270MHz memory 135MHz voltage 850mV [5.360442] nouveau [ DRM] 1: core 405MHz shader 810MHz memory 405MHz voltage 850mV [5.362215] nouveau [ DRM] 3: core 606MHz shader 1468MHz memory 667MHz voltage 1000mV [5.363998] nouveau [ DRM] c: core 405MHz shader 810MHz memory 405MHz [5.404143] nouveau [ DRM] MM: using COPY for buffer copies [5.481593] No connectors reported connected with modes [5.482667] [drm] Cannot find any crtc or sizes - going 1024x768 [5.517932] nouveau [ DRM] allocated 1024x768 fb: 0x7, bo 88013a6d3400 [5.519236] fb1: nouveaufb frame buffer device [5.520368] [drm] Initialized nouveau 1.1.0 20120801 for :01:00.0 on minor 1 [5.527378] dracut: Starting plymouth daemon
Linux 3.7-rc1 (nouveau_bios_score oops).
On 21.10.2012, Marcin Slusarz wrote: > > > Please attach acpidump output. > > > > http://pluto.agmk.net/nv/acpidump.txt > > > > This looks like ACPI bug... I guess my acpidump didn't make it to the list. Anyway, here it is: http://www.fritha.org/acpidump.gz
[3.0.y, 3.2.y, 3.4.y] Please add LVDS patch for the Zotac ZBOX SD ID13
Hi Ben and Greg, Please consider 9756fe38d10b drm/i915: no lvds quirk for Zotac ZDBOX SD ID12/ID13 for application to the 3.0.y, 3.2.y, and 3.4.y trees. It was applied upstream during the 3.6 merge window, so newer kernels don't need it. Alexander Kurtz writes, using a kernel closely based on 3.2.30[2]: > The Zotac ZBOX SD ID13 has an internal LVDS connector which (at least in > this model) isn't connected to anything. This leads to X adjusting the > maximum resolution to the resolution of the (nonexistent) LVDS display, > which is way too low. It also seems to confuse the Linux kernel when > choosing the resolution for the virtual terminals. > > The problem has been fixed upstream[0] and has also been reported in > Ubuntu[1], so fixing this bug upstream by including the patch in the > stable 3.2 branch might also be a good idea. > > Anyway, after dropping the attached patch into debian/patches/bugfix/x86 > and rebuilding the kernel, the problem was fixed here. Thoughts of all kinds welcome, as always. Thanks, Jonathan > [0] > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=9756fe38d10b2bf90c81dc4d2f17d5632e135364 > [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1064924 [2] http://bugs.debian.org/691122
[Bug 36522] Caught 16-bit read from uninitialized memory in drm_fb_helper_setcmap
https://bugzilla.kernel.org/show_bug.cgi?id=36522 --- Comment #10 from Christian Casteyde 2012-10-21 21:49:34 --- Update: Still present in 3.7-rc2 on Slackware 64 + xf86-video-ati-6.14.6 + libdrm-2.4.39-x86_64 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
Linux 3.7-rc1 (nouveau_bios_score oops).
On Sunday 21 October 2012 16:49:08 Marcin Slusarz wrote:
> On Sun, Oct 21, 2012 at 07:38:58AM -0700, Linus Torvalds wrote:
> > On Sun, Oct 21, 2012 at 5:09 AM, Marcin Slusarz
> >
> > wrote:
> > > This looks like ACPI bug...
> >
> > I'm shocked to hear that firmware would be fragile.
> >
> > Anyway, here's the #1 thing to keep in mind about firmware:
> >
> > - firmware is always buggy.
>
> I know. But this bug is not about broken firmware. It's about Linux kernel
> ACPI implementation, which (I think) wrongly interprets ACPI script.
The ACPI implementation is fine, it is just the fw engineers that suck. I see I
have not cc'd the linux-vger ml when replying to a previous mail. I'll paste
it below:
Since commit 9a334cd "drm/nouveau/bios: fix shadowing of ACPI ROMs larger than
64KiB" chunks are not always read in multiples of 4KiB anymore (less is
possible). That is the only obvious thing I can think of atm (besides the
kmalloc(0) bug for which Martin submitted a patch in the previous mail).
Do you still still have an Asus laptop with the same BIOS as in
https://bugzilla.kernel.org/show_bug.cgi?id=19702? (if yes, then the acpidump
from that bug still applies).
This is the ACPI _ROM method that is being called:
Method (_ROM, 2, NotSerialized) // _ROM: Read-Only Memory
{
Add (Arg0, RBUF, Local0)
ShiftLeft (Arg1, 0x03, Local1) // times 8, bytes to bits?
Name (VBUF, Buffer (Arg1) {})
OperationRegion (VROM, SystemMemory, Local0, Local1)
Field (VROM, ByteAcc, NoLock, Preserve)
{
ROMI, 65536
}
Store (ROMI, VBUF)
Return (VBUF)
}
Arg0 is the offset (0 when first reading the size), Arg1 is the number of read
bytes (3). Note the use of Local1 in OperationRegion. The meaning there is
bytes, but a multiple of the requested bytes is passed. So if we request 4096
bytes, we end up with a VROM of size 32KiB. ROMI is 65536 bits (or 8192
bytes), hence reading 4096 does not give errors. But reading only 3 bytes will
fail. Martin, I saw your second patch (https://lkml.org/lkml/2012/10/20/150)
which takes care of the first case, but it skips the case where the ROM is of
an odd size (does that even happen, something like 64KiB+1 bytes? No idea.)
Addition: Conclusion: this means that the request must have a length must be
at least 1 KiB or it will fail with the ACPI error that you have seen before.
This AML snippet suck.
Regards,
Peter
Re: [REGRESSION] nouveau: Severe screen corruption on (0xaf, nv50)
On Thu, Oct 18, 2012 at 11:58:09AM +0200, Henrik Rydberg wrote: > Hi Ben, > > 3.7-rc1 messed up the screen on my MacBookAir3,1 (nv50, 0xaf) pretty > badly. Not surprisingly, > > commit 3863c9bc887e9638a9d905d55f6038641ece78d6 > Author: Ben Skeggs > Date: Sat Jul 14 19:09:17 2012 +1000 > > drm/nouveau/instmem: completely new implementation, as a subdev module > > is the first bad commit. Standing on that commit, booting and then > starting X yields the output below. Hints are especially appreciated, > considering the patch is almost 8000 lines. Going through one suspend/resume cycle makes the corruption go away, and there are no more errors in dmesg. Oddly enough, I have seen something very similar when using i915 on the MBP10. Builtin modules and systemd in both cases. Maybe this is a general drm issue. Any thoughts? Thanks, Henrik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm: fb: cma: Fail gracefully on allocation failure
On Sat, Oct 20, 2012 at 12:32:47PM +0200, Thierry Reding wrote: > The drm_gem_cma_create() function never returns NULL but rather an error > encoded in the return value using the ERR_PTR() macro. Callers therefore > need to check for errors using the IS_ERR() macro. This change allows > drivers to handle contiguous DMA allocation failures gracefully. > > Signed-off-by: Thierry Reding Acked-by: Sascha Hauer Sascha > --- > drivers/gpu/drm/drm_fb_cma_helper.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c > b/drivers/gpu/drm/drm_fb_cma_helper.c > index d6c80a3..fd9d0af 100644 > --- a/drivers/gpu/drm/drm_fb_cma_helper.c > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c > @@ -220,7 +220,7 @@ static int drm_fbdev_cma_create(struct drm_fb_helper > *helper, > > size = mode_cmd.pitches[0] * mode_cmd.height; > obj = drm_gem_cma_create(dev, size); > - if (!obj) > + if (IS_ERR(obj)) > return -ENOMEM; > > fbi = framebuffer_alloc(0, dev->dev); > -- > 1.7.12.4 > > -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sun, Oct 21, 2012 at 08:58:07AM +0200, Paweł Sikora wrote:
> On Sunday 21 of October 2012 00:19:48 Marcin Slusarz wrote:
> > On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> > > On 20.10.2012, Marcin Slusarz wrote:
> > >
> > > > Try this one.
> > >
> > > It works, now I can boot again. However, nouveau seems to be dead now.
> > > The dmesg output with your patch on top of 3.7-rc1 is:
> > >
> > > [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on
> > > minor 0
> > > [3.687784] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1
> > > [3.689960] nouveau [ DEVICE][:01:00.0] Chipset: GT218 (NVA8)
> > > [3.692471] nouveau [ DEVICE][:01:00.0] Family : NV50
> > > [3.695716] nouveau [ VBIOS][:01:00.0] checking PRAMIN for
> > > image...
> > > [3.697087] nouveau [ VBIOS][:01:00.0] ... signature not found
> > > [3.698471] nouveau [ VBIOS][:01:00.0] checking PROM for
> > > image...
> > > [3.699838] nouveau [ VBIOS][:01:00.0] ... signature not found
> > > [3.701223] nouveau [ VBIOS][:01:00.0] checking ACPI for
> > > image...
> > > [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is
> > > beyond end of region [VROM] (length 24) (20120913/exfldio-210)
> > > [3.704139] ACPI Error: Method parse/execution
> > > failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8),
> > > AE_AML_REGION_LIMIT (20120913/psparse-536)
> > > [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT
> > > [3.718776] nouveau [ VBIOS][:01:00.0] ... signature not found
> > > [3.721349] nouveau [ VBIOS][:01:00.0] checking PCIROM for
> > > image...
> > > [3.724111] nouveau :01:00.0: Invalid ROM contents
> > > [3.726663] nouveau [ VBIOS][:01:00.0] ... signature not found
> > > [3.729159] nouveau E[ VBIOS][:01:00.0] unable to locate usable
> > > image
> > > [3.731677] nouveau E[ DEVICE][:01:00.0] failed to create
> > > 0x1001, -22
> > > [3.734231] nouveau E[ DRM] failed to create 0x8080, -22
> > > [3.736097] nouveau: probe of :01:00.0 failed with error -22
> > > [3.740523] dracut: Starting plymouth daemon
> >
> > Hmm, maybe we can't fetch 3 bytes only...
> >
> > Let's check this:
> >
> > ---
> > diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> > b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> > index 824eea0..8bd71aa 100644
> > --- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> > +++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> > @@ -192,14 +192,16 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
> > {
> > struct pci_dev *pdev = nv_device(bios)->pdev;
> > int ret, cnt, i;
> > - u8 data[3];
> > + u8 *data;
> >
> > if (!nouveau_acpi_rom_supported(pdev))
> > return;
> >
> > bios->size = 0;
> > - if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
> > + data = kmalloc(4096, GFP_KERNEL);
> > + if (data && nouveau_acpi_get_bios_chunk(data, 0, 4096) >= 3)
> > bios->size = data[2] * 512;
> > + kfree(data);
> > if (!bios->size)
> > return;
>
> with these both patches applied my laptop boots and gui works fine.
> here's dmesg:
>
> (...)
> [8.751795] nouveau [ VBIOS][:01:00.0] ... appears to be valid
> [8.751798] nouveau [ VBIOS][:01:00.0] using image from ACPI
> [8.751895] nouveau [ VBIOS][:01:00.0] BIT signature found
> [8.751898] nouveau [ VBIOS][:01:00.0] version 70.08.45.00
> [8.752366] nouveau [ DEVINIT][:01:00.0] adaptor not initialised
> [8.752368] nouveau [ VBIOS][:01:00.0] running init tables
> [8.867660] nouveau [ MXM][:01:00.0] no VBIOS data, nothing to do
> [8.867690] nouveau [ PFB][:01:00.0] RAM type: DDR3
> [8.867692] nouveau [ PFB][:01:00.0] RAM size: 512 MiB
> [8.901523] vga_switcheroo: enabled
> [8.901979] [TTM] Zone kernel: Available graphics memory: 6104282 kiB
> [8.901980] [TTM] Zone dma32: Available graphics memory: 2097152 kiB
> [8.901982] [TTM] Initializing pool allocator
> [8.902014] [TTM] Initializing DMA pool allocator
> [8.902180] mtrr: type mismatch for c000,1000 old: write-back new:
> write-combining
> [8.902184] nouveau [ DRM] VRAM: 512 MiB
> [8.902185] nouveau [ DRM] GART: 512 MiB
> [8.902188] nouveau [ DRM] BIT BIOS found
> [8.902190] nouveau [ DRM] Bios version 70.08.45.00
> [8.902192] nouveau [ DRM] TMDS table version 2.0
> [8.902194] nouveau [ DRM] DCB version 4.0
> [8.902196] nouveau [ DRM] DCB outp 00: 02011300
> [8.902198] nouveau [ DRM] DCB conn 01: 0100
> [8.903540] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [8.903541] [drm] No driver support for vblank timestamp query.
> [8.903545] nouveau [ DRM] ACPI backlight
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sun, Oct 21, 2012 at 5:09 AM, Marcin Slusarz wrote: > > This looks like ACPI bug... I'm _shocked_ to hear that firmware would be fragile. Anyway, here's the #1 thing to keep in mind about firmware: - firmware is *always* buggy. It's that simple. Don't expect anything else. Firmware is written by people who have lost the will to live (why? Because they do firmware development for a living), and the only thing keeping them going is the drugs. And they're not the "fun" kind of drugs. The end result is predictable. In their drug-induced haze, they make a mess. So saying "ACPI is buggy" is like saying "water is wet". Deal with it. > Nouveau calls this method: [...] > > with Arg0 == 0, Arg1 == 3 and gets: > > ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond end of region > [VROM] (length 24) (20120913/exfldio-210) > ACPI Error: Method parse/execution failed [\_SB_.PCI0.PEGR.GFX0._ROM] (Node > 88033e47fe88), AE_AML_REGION_LIMIT (20120913/psparse-536) > > We can workaround it by aligning Arg1 to 4096 (I'm wondering what is the > minimal > value), but do we really have to? Yes, you really have to. You need to understand that ACPI has been tested with one thing, and one thing only: Windows. Clearly windows doesn't ask for some three-byte region. So it doesn't work. Big surprise. Untested code written by monkeys on crack - what did you expect? So don't do "clever" things. When it comes to firmware, you need to expect it to be buggy, and try to access it the way Windows accesses it. Now, whether Windows realy always does things with a 4kB-aligned access, or whether you just need to make sure that you're (say) 4-byte-aligned, I don't know. Maybe doing things four (or eight, or sixteen) bytes at a time will work. You can try. But if we know from past experience that a 4kB block-size will work, I'd suggest just saying "It's stupid, but stupid is good - we're working with firmware" Think of firmware the way you think of hardware: it's buggy and needs workarounds. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sun, Oct 21, 2012 at 07:38:58AM -0700, Linus Torvalds wrote: > On Sun, Oct 21, 2012 at 5:09 AM, Marcin Slusarz > wrote: > > > > This looks like ACPI bug... > > I'm _shocked_ to hear that firmware would be fragile. > > Anyway, here's the #1 thing to keep in mind about firmware: > > - firmware is *always* buggy. I know. But this bug is not about broken firmware. It's about Linux kernel ACPI implementation, which (I think) wrongly interprets ACPI script. Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sun, Oct 21, 2012 at 5:49 PM, Marcin Slusarz wrote: > > I know. But this bug is not about broken firmware. It's about Linux kernel > ACPI implementation, which (I think) wrongly interprets ACPI script. Hmm. Len, care to comment? Marcin quoted the AML and our arguments in an earlier thing. I don't read AML, so I was assuming it's the AML itself that was buggy, not our interpretation of it.. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39612] radeon blocks with new style fencing
https://bugzilla.kernel.org/show_bug.cgi?id=39612 --- Comment #4 from Linas 2012-10-21 19:31:38 --- Created an attachment (id=84201) --> (https://bugzilla.kernel.org/attachment.cgi?id=84201) Xorg log mieq Testing with 3.6.2, radeon.no_wb=1 is still needed, although it seems a bit better. You can get -with a little difficulty- to switch virtual terminals, so it is possible to SIGINT the xserver. Interestingly, although the first startx leads to a blank screen, a second startx runs the DE without being apparently affected. ?! Booting with radeon.no_wb=1 the DE shows directly the first time, as it should. In one failed instance, the Xorg log showed errors of «[mi] EQ overflowing.», «[mi] EQ overflow continuing. 100 events have been dropped.», «[mi] EQ overflow continuing. 200 events have been dropped.»... I am attaching this log. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39612] radeon blocks with new style fencing
https://bugzilla.kernel.org/show_bug.cgi?id=39612 --- Comment #5 from Linas 2012-10-21 19:34:45 --- Created an attachment (id=84211) --> (https://bugzilla.kernel.org/attachment.cgi?id=84211) Other Xorg log Another failed Xorg log, this time without overflowing errors. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
radeon: RFC speed cap detection on ppc64
The radeon driver does speed cap detection on the root PCI device for
the maximum speed with which the adapter can communicate. On ppc64
systems, however, the root device belongs to the Hypervisor, so the
current code would case a null pointer dereference.
I propose to look for the outmost bus with a parent node and get speed
caps from it, though I suppose the cleaner way would be to inspect all
devices along the way and choose the smallest speed cap.
Does anyone have suggestions for this?
Thanks
--
---
/home/lucaskt/work/devdrivers/kernel/linux/drivers/gpu/drm/drm_pci.c
2012-09-26 10:06:00.280549928 -0300
+++ drm_pci.c 2012-09-26 15:38:51.121786353 -0300
@@ -466,6 +466,19 @@
}
EXPORT_SYMBOL(drm_pci_exit);
+static struct pci_dev *drm_get_pcie_root_dev(struct pci_dev *dev)
+{
+ // Go up through all possible busses to get the info for the outmost bus
+ while (!pci_is_root_bus(dev->bus))
+ dev = dev->bus->parent->self;
+
+ // In POWER architectures there's no PCI root device, so it should
just read
+ // the caps from the device itself
+ if (dev->bus->self != NULL)
+ return dev->bus->self;
+ else
+ return dev;
+}
+
int drm_pcie_get_speed_cap_mask(struct drm_device *dev, u32 *mask)
{
struct pci_dev *root;
@@ -479,7 +492,7 @@
if (!pci_is_pcie(dev->pdev))
return -EINVAL;
- root = dev->pdev->bus->self;
+ root = drm_get_pcie_root_dev(dev->pdev);
pos = pci_pcie_cap(root);
if (!pos)
--
Lucas Kannebley Tavares
Software Engineer
IBM Linux Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On 10/19/12 23:25, Linus Torvalds wrote:
Added more appropriate people to this. Added both i915 and nouveau
people, since apparently that fine piece of hardware has both.
Guys, any ideas?
Paweł, could you perhaps get a photo of the oops and post it
somewhere? I'm assuming the oops happens early during boot and you
never get a usable machine with dmesg - but if you do, then please do
post the whole dmesg too.
Linus
Hi Linus,
You must have missed the oops that was attached to the mail:
http://www.spinics.net/lists/kernel/msg1420355.html
Paweł, could you try the attached patch please ?
Martin
>From ea15dc1cf87236da78e8e88ecc3864ffab006ae0 Mon Sep 17 00:00:00 2001
From: Martin Peres
Date: Sat, 20 Oct 2012 00:08:15 +0200
Subject: [PATCH] drm/nouveau/bios: improve error handling when reading the
vbios from ACPI
Reported-by: Pawel Sikora
Signed-off-by: Martin Peres
---
drivers/gpu/drm/nouveau/core/subdev/bios/base.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
index 2fbb6df..e31d8fc 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
@@ -188,8 +188,10 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
int cnt = 65536 / 4096;
int ret;
- if (!nouveau_acpi_rom_supported(pdev))
+ if (!nouveau_acpi_rom_supported(pdev)) {
+ bios->data = NULL;
return;
+ }
bios->data = kmalloc(65536, GFP_KERNEL);
bios->size = 0;
--
1.7.12.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On 20/10/2012 11:26, Heinz Diehl wrote:
On 20.10.2012, Linus Torvalds wrote:
Added more appropriate people to this. Added both i915 and nouveau
people, since apparently that fine piece of hardware has both.
Guys, any ideas?
Plese see https://lkml.org/lkml/2012/10/19/371 , this is the same
thing going on. Reverting
Ben Skeggs
drm/nouveau/bios: fix shadowing of ACPI ROMs larger than 64KiB
fixes the problem.
Can you test the attached patch too ? I rebased the previous one I sent
on top on 3.7-rc1 as I accidentally used an older version.
Martin
>From f09d58dc23a6e48ed56a1d9bf803f800f0c59e83 Mon Sep 17 00:00:00 2001
From: Martin Peres
Date: Sat, 20 Oct 2012 11:03:36 +0200
Subject: [PATCH] drm/nouveau/bios: improve error handling when reading the
vbios from ACPI
Reported-by: Pawel Sikora
Signed-off-by: Martin Peres
---
drivers/gpu/drm/nouveau/core/subdev/bios/base.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
index 619e7e0..519a3b3 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
@@ -188,8 +188,10 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
int ret, cnt, i;
u8 data[3];
- if (!nouveau_acpi_rom_supported(pdev))
+ if (!nouveau_acpi_rom_supported(pdev)) {
+ bios->data = NULL;
return;
+ }
bios->size = 0;
if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
--
1.7.12.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On 20.10.2012, Linus Torvalds wrote: > Added more appropriate people to this. Added both i915 and nouveau > people, since apparently that fine piece of hardware has both. > > Guys, any ideas? Plese see https://lkml.org/lkml/2012/10/19/371 , this is the same thing going on. Reverting Ben Skeggs drm/nouveau/bios: fix shadowing of ACPI ROMs larger than 64KiB fixes the problem. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On 20.10.2012, Martin Peres wrote: > Can you test the attached patch too ? I rebased the previous one I sent on > top on 3.7-rc1 as I accidentally used an older version. Yes, of course. Tried it. Unfortunately, the crash remains the same as reported. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On 20.10.2012, Marcin Slusarz wrote: > Try this one. It works, now I can boot again. However, nouveau seems to be dead now. The dmesg output with your patch on top of 3.7-rc1 is: [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 [3.687784] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1 [3.689960] nouveau [ DEVICE][:01:00.0] Chipset: GT218 (NVA8) [3.692471] nouveau [ DEVICE][:01:00.0] Family : NV50 [3.695716] nouveau [ VBIOS][:01:00.0] checking PRAMIN for image... [3.697087] nouveau [ VBIOS][:01:00.0] ... signature not found [3.698471] nouveau [ VBIOS][:01:00.0] checking PROM for image... [3.699838] nouveau [ VBIOS][:01:00.0] ... signature not found [3.701223] nouveau [ VBIOS][:01:00.0] checking ACPI for image... [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond end of region [VROM] (length 24) (20120913/exfldio-210) [3.704139] ACPI Error: Method parse/execution failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8), AE_AML_REGION_LIMIT (20120913/psparse-536) [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT [3.718776] nouveau [ VBIOS][:01:00.0] ... signature not found [3.721349] nouveau [ VBIOS][:01:00.0] checking PCIROM for image... [3.724111] nouveau :01:00.0: Invalid ROM contents [3.726663] nouveau [ VBIOS][:01:00.0] ... signature not found [3.729159] nouveau E[ VBIOS][:01:00.0] unable to locate usable image [3.731677] nouveau E[ DEVICE][:01:00.0] failed to create 0x1001, -22 [3.734231] nouveau E[ DRM] failed to create 0x8080, -22 [3.736097] nouveau: probe of :01:00.0 failed with error -22 [3.740523] dracut: Starting plymouth daemon And here's the same output with plain vanilla 3.6.2: [3.588791] [drm] nouveau :01:00.0: Detected an NV50 generation card (0x0a8800b1) [3.599783] vga_switcheroo: enabled [3.601303] [drm] nouveau :01:00.0: Checking PRAMIN for VBIOS [3.602817] [drm] nouveau :01:00.0: ... BIOS signature not found [3.604294] [drm] nouveau :01:00.0: Checking PROM for VBIOS [3.605822] [drm] nouveau :01:00.0: ... BIOS signature not found [3.607310] [drm] nouveau :01:00.0: Checking ACPI for VBIOS [3.856854] [drm] nouveau :01:00.0: ... appears to be valid [3.859409] [drm] nouveau :01:00.0: Using VBIOS from ACPI [3.861907] [drm] nouveau :01:00.0: BIT BIOS found [3.864369] [drm] nouveau :01:00.0: Bios version 70.18.5d.00 [3.866829] [drm] nouveau :01:00.0: TMDS table version 2.0 [3.869479] [drm] nouveau :01:00.0: MXM: no VBIOS data, nothing to do [3.870871] [drm] nouveau :01:00.0: DCB version 4.0 [3.872220] [drm] nouveau :01:00.0: DCB outp 00: 02014300 [3.873611] [drm] nouveau :01:00.0: DCB conn 00: 0040 [3.874994] [drm] nouveau :01:00.0: DCB conn 01: 00410146 [3.876367] [drm] nouveau :01:00.0: DCB conn 02: 1261 [3.877719] [drm] nouveau :01:00.0: DCB conn 03: 2330 [3.879043] [drm] nouveau :01:00.0: DCB conn 04: 0400 [3.880355] [drm] nouveau :01:00.0: DCB conn 05: 0560 [3.881662] [drm] nouveau :01:00.0: Adaptor not initialised, running VBIOS init tables. [3.882961] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0xDECD [3.936538] [drm] nouveau :01:00.0: 0xDE34: i2c wr fail: -6 [3.957932] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0xE378 [3.987046] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 0xEF4B [3.988396] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 0xEF64 [3.990741] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0xF04B [3.992020] [drm] nouveau :01:00.0: Parsing VBIOS init table at offset 0xF0B0 [4.018084] [TTM] Zone kernel: Available graphics memory: 1917766 kiB [4.019438] [TTM] Initializing pool allocator [4.020694] [TTM] Initializing DMA pool allocator [4.021914] [drm] nouveau :01:00.0: Detected 1024MiB VRAM (DDR3) [4.024515] [drm] nouveau :01:00.0: 512 MiB GART (aperture) [4.083748] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [4.084909] [drm] No driver support for vblank timestamp query. [4.085985] [drm] nouveau :01:00.0: ACPI backlight interface available, not registering our own [4.246449] [drm] nouveau :01:00.0: 3 available performance level(s) [4.247560] [drm] nouveau :01:00.0: 0: core 135MHz shader 270MHz memory 135MHz voltage 850mV [4.248707] [drm] nouveau :01:00.0: 1: core 405MHz shader 810MHz memory 405MHz voltage 850mV [4.249807] [drm] nouveau :01:00.0: 3: core 606MHz shader 1468MHz memory 667MHz voltage 1000mV [4.250946] [drm] nouveau :01:00.0: c: core 405MHz shader 810MHz memory 405MHz [4.
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sunday 21 of October 2012 00:19:48 Marcin Slusarz wrote:
> On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> > On 20.10.2012, Marcin Slusarz wrote:
> >
> > > Try this one.
> >
> > It works, now I can boot again. However, nouveau seems to be dead now.
> > The dmesg output with your patch on top of 3.7-rc1 is:
> >
> > [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on
> > minor 0
> > [3.687784] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1
> > [3.689960] nouveau [ DEVICE][:01:00.0] Chipset: GT218 (NVA8)
> > [3.692471] nouveau [ DEVICE][:01:00.0] Family : NV50
> > [3.695716] nouveau [ VBIOS][:01:00.0] checking PRAMIN for
> > image...
> > [3.697087] nouveau [ VBIOS][:01:00.0] ... signature not found
> > [3.698471] nouveau [ VBIOS][:01:00.0] checking PROM for image...
> > [3.699838] nouveau [ VBIOS][:01:00.0] ... signature not found
> > [3.701223] nouveau [ VBIOS][:01:00.0] checking ACPI for image...
> > [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond
> > end of region [VROM] (length 24) (20120913/exfldio-210)
> > [3.704139] ACPI Error: Method parse/execution
> > failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8),
> > AE_AML_REGION_LIMIT (20120913/psparse-536)
> > [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT
> > [3.718776] nouveau [ VBIOS][:01:00.0] ... signature not found
> > [3.721349] nouveau [ VBIOS][:01:00.0] checking PCIROM for
> > image...
> > [3.724111] nouveau :01:00.0: Invalid ROM contents
> > [3.726663] nouveau [ VBIOS][:01:00.0] ... signature not found
> > [3.729159] nouveau E[ VBIOS][:01:00.0] unable to locate usable
> > image
> > [3.731677] nouveau E[ DEVICE][:01:00.0] failed to create
> > 0x1001, -22
> > [3.734231] nouveau E[ DRM] failed to create 0x8080, -22
> > [3.736097] nouveau: probe of :01:00.0 failed with error -22
> > [3.740523] dracut: Starting plymouth daemon
>
> Hmm, maybe we can't fetch 3 bytes only...
>
> Let's check this:
>
> ---
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> index 824eea0..8bd71aa 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> @@ -192,14 +192,16 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
> {
> struct pci_dev *pdev = nv_device(bios)->pdev;
> int ret, cnt, i;
> - u8 data[3];
> + u8 *data;
>
> if (!nouveau_acpi_rom_supported(pdev))
> return;
>
> bios->size = 0;
> - if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
> + data = kmalloc(4096, GFP_KERNEL);
> + if (data && nouveau_acpi_get_bios_chunk(data, 0, 4096) >= 3)
> bios->size = data[2] * 512;
> + kfree(data);
> if (!bios->size)
> return;
with these both patches applied my laptop boots and gui works fine.
here's dmesg:
(...)
[8.751795] nouveau [ VBIOS][:01:00.0] ... appears to be valid
[8.751798] nouveau [ VBIOS][:01:00.0] using image from ACPI
[8.751895] nouveau [ VBIOS][:01:00.0] BIT signature found
[8.751898] nouveau [ VBIOS][:01:00.0] version 70.08.45.00
[8.752366] nouveau [ DEVINIT][:01:00.0] adaptor not initialised
[8.752368] nouveau [ VBIOS][:01:00.0] running init tables
[8.867660] nouveau [ MXM][:01:00.0] no VBIOS data, nothing to do
[8.867690] nouveau [ PFB][:01:00.0] RAM type: DDR3
[8.867692] nouveau [ PFB][:01:00.0] RAM size: 512 MiB
[8.901523] vga_switcheroo: enabled
[8.901979] [TTM] Zone kernel: Available graphics memory: 6104282 kiB
[8.901980] [TTM] Zone dma32: Available graphics memory: 2097152 kiB
[8.901982] [TTM] Initializing pool allocator
[8.902014] [TTM] Initializing DMA pool allocator
[8.902180] mtrr: type mismatch for c000,1000 old: write-back new:
write-combining
[8.902184] nouveau [ DRM] VRAM: 512 MiB
[8.902185] nouveau [ DRM] GART: 512 MiB
[8.902188] nouveau [ DRM] BIT BIOS found
[8.902190] nouveau [ DRM] Bios version 70.08.45.00
[8.902192] nouveau [ DRM] TMDS table version 2.0
[8.902194] nouveau [ DRM] DCB version 4.0
[8.902196] nouveau [ DRM] DCB outp 00: 02011300
[8.902198] nouveau [ DRM] DCB conn 01: 0100
[8.903540] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[8.903541] [drm] No driver support for vblank timestamp query.
[8.903545] nouveau [ DRM] ACPI backlight interface available, not
registering our own
[8.903938] nouveau [ DRM] 3 available performance level(s)
[8.903941] nouveau [ DRM] 0: core 50MHz shader 101MHz memory 135MHz
voltage 830mV
[8.903943] nouveau [ DRM] 1: c
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On 21.10.2012, Marcin Slusarz wrote: > On 3.6 kernel? (It doesn't exist on 3.7) > Note that it may be in other directory than "0". [root@wildsau linux-3.6.2]# cat .config | grep -i "nouveau" CONFIG_DRM_NOUVEAU=m CONFIG_DRM_NOUVEAU_BACKLIGHT=y CONFIG_DRM_NOUVEAU_DEBUG=y I grepped the whole disk, there's no vbios.rom at all. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On 21.10.2012, Paweł Sikora wrote: > with these both patches applied my laptop boots and gui works fine. The same here. The two patches together, applied to 3.7-rc1 let my machine boot again. Here's the relevant dmesg cut: [3.702671] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1 [3.704643] nouveau [ DEVICE][:01:00.0] Chipset: GT218 (NVA8) [3.707003] nouveau [ DEVICE][:01:00.0] Family : NV50 [3.711393] nouveau [ VBIOS][:01:00.0] checking PRAMIN for image... [3.712793] nouveau [ VBIOS][:01:00.0] ... signature not found [3.714147] nouveau [ VBIOS][:01:00.0] checking PROM for image... [3.715578] nouveau [ VBIOS][:01:00.0] ... signature not found [3.716969] nouveau [ VBIOS][:01:00.0] checking ACPI for image... [4.207512] nouveau [ VBIOS][:01:00.0] ... appears to be valid [4.209711] nouveau [ VBIOS][:01:00.0] using image from ACPI [4.212469] nouveau [ VBIOS][:01:00.0] BIT signature found [4.214855] nouveau [ VBIOS][:01:00.0] version 70.18.5d.00 [4.217554] nouveau [ DEVINIT][:01:00.0] adaptor not initialised [4.219922] nouveau [ VBIOS][:01:00.0] running init tables [4.342202] nouveau [ MXM][:01:00.0] no VBIOS data, nothing to do [4.343590] nouveau [ PFB][:01:00.0] RAM type: DDR3 [4.344916] nouveau [ PFB][:01:00.0] RAM size: 1024 MiB [4.991887] vga_switcheroo: enabled [4.993495] [TTM] Zone kernel: Available graphics memory: 1917720 kiB [4.994911] [TTM] Initializing pool allocator [4.996228] [TTM] Initializing DMA pool allocator [4.998915] nouveau [ DRM] VRAM: 1024 MiB [5.000251] nouveau [ DRM] GART: 512 MiB [5.001579] nouveau [ DRM] BIT BIOS found [5.002904] nouveau [ DRM] Bios version 70.18.5d.00 [5.004229] nouveau [ DRM] TMDS table version 2.0 [5.005545] nouveau [ DRM] DCB version 4.0 [5.006810] nouveau [ DRM] DCB outp 00: 02014300 [5.008115] nouveau [ DRM] DCB conn 00: 0040 [5.009441] nouveau [ DRM] DCB conn 01: 00410146 [5.010745] nouveau [ DRM] DCB conn 02: 1261 [5.012019] nouveau [ DRM] DCB conn 03: 2330 [5.013255] nouveau [ DRM] DCB conn 04: 0400 [5.014452] nouveau [ DRM] DCB conn 05: 0560 [5.052344] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [5.053486] [drm] No driver support for vblank timestamp query. [5.054590] nouveau [ DRM] ACPI backlight interface available,not registering our own [5.356822] nouveau [ DRM] 3 available performance level(s) [5.358682] nouveau [ DRM] 0: core 135MHz shader 270MHz memory 135MHz voltage 850mV [5.360442] nouveau [ DRM] 1: core 405MHz shader 810MHz memory 405MHz voltage 850mV [5.362215] nouveau [ DRM] 3: core 606MHz shader 1468MHz memory 667MHz voltage 1000mV [5.363998] nouveau [ DRM] c: core 405MHz shader 810MHz memory 405MHz [5.404143] nouveau [ DRM] MM: using COPY for buffer copies [5.481593] No connectors reported connected with modes [5.482667] [drm] Cannot find any crtc or sizes - going 1024x768 [5.517932] nouveau [ DRM] allocated 1024x768 fb: 0x7, bo 88013a6d3400 [5.519236] fb1: nouveaufb frame buffer device [5.520368] [drm] Initialized nouveau 1.1.0 20120801 for :01:00.0 on minor 1 [5.527378] dracut: Starting plymouth daemon ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On 21.10.2012, Marcin Slusarz wrote: > > > Please attach acpidump output. > > > > http://pluto.agmk.net/nv/acpidump.txt > > > > This looks like ACPI bug... I guess my acpidump didn't make it to the list. Anyway, here it is: http://www.fritha.org/acpidump.gz ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [3.0.y, 3.2.y, 3.4.y] Please add LVDS patch for the Zotac ZBOX SD ID13
Hi Ben and Greg, Please consider 9756fe38d10b drm/i915: no lvds quirk for Zotac ZDBOX SD ID12/ID13 for application to the 3.0.y, 3.2.y, and 3.4.y trees. It was applied upstream during the 3.6 merge window, so newer kernels don't need it. Alexander Kurtz writes, using a kernel closely based on 3.2.30[2]: > The Zotac ZBOX SD ID13 has an internal LVDS connector which (at least in > this model) isn't connected to anything. This leads to X adjusting the > maximum resolution to the resolution of the (nonexistent) LVDS display, > which is way too low. It also seems to confuse the Linux kernel when > choosing the resolution for the virtual terminals. > > The problem has been fixed upstream[0] and has also been reported in > Ubuntu[1], so fixing this bug upstream by including the patch in the > stable 3.2 branch might also be a good idea. > > Anyway, after dropping the attached patch into debian/patches/bugfix/x86 > and rebuilding the kernel, the problem was fixed here. Thoughts of all kinds welcome, as always. Thanks, Jonathan > [0] > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=9756fe38d10b2bf90c81dc4d2f17d5632e135364 > [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1064924 [2] http://bugs.debian.org/691122 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36522] Caught 16-bit read from uninitialized memory in drm_fb_helper_setcmap
https://bugzilla.kernel.org/show_bug.cgi?id=36522 --- Comment #10 from Christian Casteyde 2012-10-21 21:49:34 --- Update: Still present in 3.7-rc2 on Slackware 64 + xf86-video-ati-6.14.6 + libdrm-2.4.39-x86_64 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sun, 2012-10-21 at 00:19 +0200, Marcin Slusarz wrote:
> On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> > On 20.10.2012, Marcin Slusarz wrote:
> >
> > > Try this one.
> >
> > It works, now I can boot again. However, nouveau seems to be dead now.
> > The dmesg output with your patch on top of 3.7-rc1 is:
> >
> > [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on
> > minor 0
> > [3.687784] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1
> > [3.689960] nouveau [ DEVICE][:01:00.0] Chipset: GT218 (NVA8)
> > [3.692471] nouveau [ DEVICE][:01:00.0] Family : NV50
> > [3.695716] nouveau [ VBIOS][:01:00.0] checking PRAMIN for
> > image...
> > [3.697087] nouveau [ VBIOS][:01:00.0] ... signature not found
> > [3.698471] nouveau [ VBIOS][:01:00.0] checking PROM for image...
> > [3.699838] nouveau [ VBIOS][:01:00.0] ... signature not found
> > [3.701223] nouveau [ VBIOS][:01:00.0] checking ACPI for image...
> > [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond
> > end of region [VROM] (length 24) (20120913/exfldio-210)
> > [3.704139] ACPI Error: Method parse/execution
> > failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8),
> > AE_AML_REGION_LIMIT (20120913/psparse-536)
> > [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT
> > [3.718776] nouveau [ VBIOS][:01:00.0] ... signature not found
> > [3.721349] nouveau [ VBIOS][:01:00.0] checking PCIROM for
> > image...
> > [3.724111] nouveau :01:00.0: Invalid ROM contents
> > [3.726663] nouveau [ VBIOS][:01:00.0] ... signature not found
> > [3.729159] nouveau E[ VBIOS][:01:00.0] unable to locate usable
> > image
> > [3.731677] nouveau E[ DEVICE][:01:00.0] failed to create
> > 0x1001, -22
> > [3.734231] nouveau E[ DRM] failed to create 0x8080, -22
> > [3.736097] nouveau: probe of :01:00.0 failed with error -22
> > [3.740523] dracut: Starting plymouth daemon
>
> Hmm, maybe we can't fetch 3 bytes only...
Yeah, I noticed this issue myself on a machine here while backporting
the patch to another (older) kernel. I assumed (wrongly, apparently)
that there was just a bug in the older kernel's ACPI implementation that
had been fixed upstream already (I didn't see it on the same machine
with the current kernel)... So, I didn't send the patch.
I'll queue it up with a -fixes batch later today.
Sorry about the trouble,
Ben.
>
> Let's check this:
>
> ---
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> index 824eea0..8bd71aa 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> @@ -192,14 +192,16 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
> {
> struct pci_dev *pdev = nv_device(bios)->pdev;
> int ret, cnt, i;
> - u8 data[3];
> + u8 *data;
>
> if (!nouveau_acpi_rom_supported(pdev))
> return;
>
> bios->size = 0;
> - if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
> + data = kmalloc(4096, GFP_KERNEL);
> + if (data && nouveau_acpi_get_bios_chunk(data, 0, 4096) >= 3)
> bios->size = data[2] * 512;
> + kfree(data);
> if (!bios->size)
> return;
>
> ---
>
> Please attach acpidump output.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)
https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #3 from Alexandre Demers --- So, I went further and I split commit 62444b in 3 patches. On for the register values, one for the stop function and one for the resume function. I applied the first and the second patches for now and it seems to work well. I suspended my computer, resumed and everything is going normal (for now at least). I'll test it a bit more, but the problem seems to be somewhere in the resume function. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sunday 21 October 2012 16:49:08 Marcin Slusarz wrote:
> On Sun, Oct 21, 2012 at 07:38:58AM -0700, Linus Torvalds wrote:
> > On Sun, Oct 21, 2012 at 5:09 AM, Marcin Slusarz
> >
> > wrote:
> > > This looks like ACPI bug...
> >
> > I'm shocked to hear that firmware would be fragile.
> >
> > Anyway, here's the #1 thing to keep in mind about firmware:
> >
> > - firmware is always buggy.
>
> I know. But this bug is not about broken firmware. It's about Linux kernel
> ACPI implementation, which (I think) wrongly interprets ACPI script.
The ACPI implementation is fine, it is just the fw engineers that suck. I see I
have not cc'd the linux-vger ml when replying to a previous mail. I'll paste
it below:
Since commit 9a334cd "drm/nouveau/bios: fix shadowing of ACPI ROMs larger than
64KiB" chunks are not always read in multiples of 4KiB anymore (less is
possible). That is the only obvious thing I can think of atm (besides the
kmalloc(0) bug for which Martin submitted a patch in the previous mail).
Do you still still have an Asus laptop with the same BIOS as in
https://bugzilla.kernel.org/show_bug.cgi?id=19702? (if yes, then the acpidump
from that bug still applies).
This is the ACPI _ROM method that is being called:
Method (_ROM, 2, NotSerialized) // _ROM: Read-Only Memory
{
Add (Arg0, RBUF, Local0)
ShiftLeft (Arg1, 0x03, Local1) // times 8, bytes to bits?
Name (VBUF, Buffer (Arg1) {})
OperationRegion (VROM, SystemMemory, Local0, Local1)
Field (VROM, ByteAcc, NoLock, Preserve)
{
ROMI, 65536
}
Store (ROMI, VBUF)
Return (VBUF)
}
Arg0 is the offset (0 when first reading the size), Arg1 is the number of read
bytes (3). Note the use of Local1 in OperationRegion. The meaning there is
bytes, but a multiple of the requested bytes is passed. So if we request 4096
bytes, we end up with a VROM of size 32KiB. ROMI is 65536 bits (or 8192
bytes), hence reading 4096 does not give errors. But reading only 3 bytes will
fail. Martin, I saw your second patch (https://lkml.org/lkml/2012/10/20/150)
which takes care of the first case, but it skips the case where the ROM is of
an odd size (does that even happen, something like 64KiB+1 bytes? No idea.)
Addition: Conclusion: this means that the request must have a length must be
at least 1 KiB or it will fail with the ACPI error that you have seen before.
This AML snippet suck.
Regards,
Peter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
