nouveau on NV04 calling illegal method 02fc under fbcon
Hi, Trying a new kernel on old [NV04] system I get tons of nouveau :01:00.0: gr: intr 0001 [NOTIFY] nsource 0040 [ILLEGAL_MTHD] nstatus 4000 [PROTECTION_FAULT] ch 0 [DRM] subc 3 class 004a mthd 02fc data 0003 errors when operating on console. As I updated from 4.3 kernel, a bisect does not feel like the best start. What is that 02fc method which fbcon is probably triggering as hardware-acceleration on nouveau side. Thanks, Bruno Below, a grep for nouveau on kernel log: Nov 24 18:27:27 zeus kernel: Kernel command line: BOOT_IMAGE=5.3.12 ro root=802 slub_debug=FZP nouveau.runpm=1 nouveau.debug=debug console=ttyS0,115200 nouveau.agpmode=0 Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: NVIDIA NV04 (20044001) Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: trying PRAMIN... Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: 0260: NPDE signature (9b030041) unknown Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: : type 00, 32768 bytes Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: scored 4 Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: trying PROM... Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: : ROM signature () unknown Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: image 0 invalid Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: scored 0 Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: trying ACPI... Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: using image from PRAMIN Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: 0260: NPDE signature (9b030041) unknown Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: 0260: NPDE signature (9b030041) unknown Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: BMP version 1.1 Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: version 02.04.19.00.00 Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: DCB table not found Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: i2c: ccb 00: type 00 drive 3f sense 3e share ff auxch cb Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: DCB table not found Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: i2c: ccb 01: type 00 drive 37 sense 36 share ff auxch cb Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: DCB table not found Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: DCB table not found Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: disp: head-0: ctor Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: disp: head-1: ctor Nov 24 18:27:27 zeus kernel: nouveau: DRM-master::0080: init running... Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: putting AGP V2 device into 0x mode Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: tmr: unknown input clock freq Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: tmr: input frequency : 0Hz Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: tmr: numerator : 0001 Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: tmr: denominator : 0001 Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: tmr: timer frequency : 0Hz Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: tmr: time low: 87dbe4df Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: tmr: time high : Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: fb: 16 MiB SDRAM Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: clk: --: Nov 24 18:27:27 zeus kernel: nouveau: DRM-master::0080: init children... Nov 24 18:27:27 zeus kernel: nouveau: DRM-master::0080: init completed in 80915us Nov 24 18:27:27 zeus kernel: nouveau: DRM-master::8009: init running... Nov 24 18:27:27 zeus kernel: nouveau: DRM-master::8009: init children... Nov 24 18:27:27 zeus kernel: nouveau: DRM-master::8009: init completed in 6315us Nov 24 18:27:27 zeus kernel: nouveau: DRM-master::800d: init running... Nov 24 18:27:27 zeus kernel: nouveau: DRM-master::800d: init children... Nov 24 18:27:27 zeus kernel: nouveau: DRM-master::800d: init completed in 6319us Nov 24 18:27:27 zeus kernel: nouveau: DRM-master::: init running... Nov 24 18:27:27 zeus kernel: nouveau: DRM-master::: init children... Nov 24 18:27:27 zeus kernel: nouveau: DRM-master::: init completed in 6317us Nov 24 18:27:27 zeus kernel: nouveau: DRM::0080: init running... Nov 24 18:27:27 zeus kernel: nouveau: DRM::0080: init children... Nov 24 18:27:27 zeus kernel: nouveau: DRM::0080: init completed in 5713us Nov 24 18:27:27 zeus kernel: nouveau: DRM::8009: init running... Nov 24 18:27:27 zeus kernel: nouveau: DRM::8009: init children... Nov 24 18:27:27 zeus kernel: nouveau: DRM::8009: init completed in 5664us Nov 24 18:27:27 zeus kernel: nouveau: DRM::800d: init running... Nov 24 18:27
Re: nouveau on NV04 calling illegal method 02fc under fbcon
Hi Daniel, On Mon, 25 Nov 2019 09:18:41 +0100 Daniel Vetter wrote: > On Mon, Nov 25, 2019 at 9:08 AM Bruno Prémont wrote: > > Trying a new kernel on old [NV04] system I get tons of > > nouveau :01:00.0: gr: intr 0001 [NOTIFY] nsource 0040 > > [ILLEGAL_MTHD] nstatus 4000 [PROTECTION_FAULT] ch 0 > > [DRM] subc 3 class 004a mthd 02fc data 0003 > > errors when operating on console. > > > > As I updated from 4.3 kernel, a bisect does not feel like the best start. > > The bigger your upgrade, the more efficient bisecting actually is. The > difference between one kernel (usually 12-13 bisects) and 20 kernels > is just 4-5 bisects more. Well with the time it takes to compile the kernel (and worse the Kconfig changing quite a lot between the endpoints) it's not fun at all. Thus I will first try with reverting below few commits. > > What is that 02fc method which fbcon is probably triggering as > > hardware-acceleration on nouveau side. > > Booting with nouveau.nofbaccel=0 (that should be the default, I guess > you changed it) should help confirm that's it's indeed fbcon causing > this stuff. I will try out when I am back next to that machine. If it's fbcon acceleration (which I assume as output to fbcon causes new errors), probably one of the few commits to drivers/gpu/drm/nouveau/nv04_fbcon.c would be the cause: 1167c6bc51880cb74a3b1a02286fc25392684281 drm/nouveau: allocate device object for every client 9dec9280523157da820f923e18dd6a7bf99fead7 drm/nouveau/fbcon: make use of drm_fb_helper.dev 28668f43b8e421634e1623f72a879812288dd06b drm/nouveau/fbcon: fix font width not divisible by 8 f045f459d925138fe7d6193a8c86406bda7e49da drm/nouveau/fbcon: fix out-of-bounds memory accesses 4dc28134a8c124aa01b441e1e5b8b54312edc5dd drm/nouveau: rename nouveau_drm.h to nouveau_drv.h At first glance I would suspect one of: 28668f43b8e421634e1623f72a879812288dd06b f045f459d925138fe7d6193a8c86406bda7e49da Bruno > I think at least, not a nouveau expert. > -Daniel > > > > Thanks, > > Bruno > > > > > > > > Below, a grep for nouveau on kernel log: > > > > Nov 24 18:27:27 zeus kernel: Kernel command line: BOOT_IMAGE=5.3.12 ro > > root=802 slub_debug=FZP nouveau.runpm=1 nouveau.debug=debug > > console=ttyS0,115200 nouveau.agpmode=0 > > Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: NVIDIA NV04 (20044001) > > Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: trying PRAMIN... > > Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: 0260: NPDE > > signature (9b030041) unknown > > Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: : type 00, > > 32768 bytes > > Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: scored 4 > > Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: trying PROM... > > Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: : ROM > > signature () unknown > > Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: image 0 invalid > > Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: scored 0 > > Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: trying ACPI... > > Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: using image from > > PRAMIN > > Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: 0260: NPDE > > signature (9b030041) unknown > > Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: 0260: NPDE > > signature (9b030041) unknown > > Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: BMP version 1.1 > > Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: version > > 02.04.19.00.00 > > Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: DCB table not found > > Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: i2c: ccb 00: type 00 > > drive 3f sense 3e share ff auxch cb > > Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: DCB table not found > > Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: i2c: ccb 01: type 00 > > drive 37 sense 36 share ff auxch cb > > Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: DCB table not found > > Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: bios: DCB table not found > > Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: disp: head-0: ctor > > Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: disp: head-1: ctor > > Nov 24 18:27:27 zeus kernel: nouveau: DRM-master::0080: init > > running... > > Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: putting AGP V2 device > > into 0x mode > > Nov 24 18:27:27 zeus kernel: nouveau :01:00.0: tmr: unknown inpu
Re: [PATCH v2 11/14] HID: picoLCD: constify fb ops
Hi Jani,
On Fri, 29 Nov 2019 12:29:41 Jani Nikula wrote:
> Now that the fbops member of struct fb_info is const, we can start
> making the ops const as well.
>
> v2: fix typo (Christophe de Dinechin)
Fine with me.
I don't think going through drm-misc would trigger any conflict, but
adding Jiri to CC for the case there was any preference.
Acked-by: Bruno Prémont
> Cc: Bruno Prémont
> Cc: linux-in...@vger.kernel.org
> Reviewed-by: Daniel Vetter
> Signed-off-by: Jani Nikula
> ---
> drivers/hid/hid-picolcd_fb.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/hid/hid-picolcd_fb.c b/drivers/hid/hid-picolcd_fb.c
> index e162a668fb7e..a549c42e8c90 100644
> --- a/drivers/hid/hid-picolcd_fb.c
> +++ b/drivers/hid/hid-picolcd_fb.c
> @@ -417,8 +417,7 @@ static int picolcd_set_par(struct fb_info *info)
> return 0;
> }
>
> -/* Note this can't be const because of struct fb_info definition */
> -static struct fb_ops picolcdfb_ops = {
> +static const struct fb_ops picolcdfb_ops = {
> .owner= THIS_MODULE,
> .fb_destroy = picolcd_fb_destroy,
> .fb_read = fb_sys_read,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/17] hid/picolcd: Remove flag FBINFO_FLAG_DEFAULT from fbdev driver
On Mon, 10 Jul 2023 14:50:14 +0200 Thomas Zimmermann wrote: > The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct > fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do > not set it. > > Flags should signal differences from the default values. After cleaning > up all occurences of FBINFO_FLAG_DEFAULT, the token can be removed. > > Signed-off-by: Thomas Zimmermann > Cc: "Bruno Prémont" > Cc: Jiri Kosina > Cc: Benjamin Tissoires Acked-by: Bruno Prémont Cheers, Bruno > --- > drivers/hid/hid-picolcd_fb.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/hid/hid-picolcd_fb.c b/drivers/hid/hid-picolcd_fb.c > index dabcd054dad9..d726aaafb146 100644 > --- a/drivers/hid/hid-picolcd_fb.c > +++ b/drivers/hid/hid-picolcd_fb.c > @@ -527,7 +527,6 @@ int picolcd_init_framebuffer(struct picolcd_data *data) > info->var = picolcdfb_var; > info->fix = picolcdfb_fix; > info->fix.smem_len = PICOLCDFB_SIZE*8; > - info->flags = FBINFO_FLAG_DEFAULT; > > fbdata = info->par; > spin_lock_init(&fbdata->lock);
Deadlock in 4.6 caused by 4eebd5a4e726 ("apple-gmux: lock iGP IO to protect from vgaarb changes")
Hi Lucas,
On Fri, 27 May 2016 14:23:02 +0200 Lukas Wunner wrote:
> Hi Bruno,
>
> Wilfried Klaebe has reported a deadlock in 4.6 which he bisected to
> my commit 704ab614ec12 ("drm/i915: Defer probe if gmux is present but
> its driver isn't"), but which is ultimately caused by your commit
> 4eebd5a4e726 ("apple-gmux: lock iGP IO to protect from vgaarb changes").
>
> What's happening is that your commit calls vga_tryget() in apple-gmux,
> which succeeds. When Xorg is launched, it opens /dev/vga_arbiter and
> calls vga_get(), which deadlocks. See the attachments to this bugzilla
> entry, in particular the stacktrace at the end of "kern.log / dmesg of
> non-working Linux 4.6.0":
> https://bugzilla.kernel.org/show_bug.cgi?id=88861#c11
> https://bugzilla.kernel.org/attachment.cgi?id=217541
Looks like here the two GPUs are visible and the right one is being
selected.
So your patch to allow including ISA devices in vga arbitration would
not change anything here.
Is it known at what time the lockup happens?
Deadlock in 4.6 caused by 4eebd5a4e726 ("apple-gmux: lock iGP IO to protect from vgaarb changes")
Hi Lucas,
On Mon, 30 May 2016 12:24:46 +0200 Lukas Wunner wrote:
> On Mon, May 30, 2016 at 11:07:53AM +0200, Bruno Prémont wrote:
> > On Fri, 27 May 2016 14:23:02 +0200 Lukas Wunner wrote:
> > > Wilfried Klaebe has reported a deadlock in 4.6 which he bisected to
> > > my commit 704ab614ec12 ("drm/i915: Defer probe if gmux is present but
> > > its driver isn't"), but which is ultimately caused by your commit
> > > 4eebd5a4e726 ("apple-gmux: lock iGP IO to protect from vgaarb changes").
> > >
> > > What's happening is that your commit calls vga_tryget() in apple-gmux,
> > > which succeeds. When Xorg is launched, it opens /dev/vga_arbiter and
> > > calls vga_get(), which deadlocks. See the attachments to this bugzilla
> > > entry, in particular the stacktrace at the end of "kern.log / dmesg of
> > > non-working Linux 4.6.0":
> > > https://bugzilla.kernel.org/show_bug.cgi?id=88861#c11
> > > https://bugzilla.kernel.org/attachment.cgi?id=217541
> >
> > Looks like here the two GPUs are visible and the right one is being
> > selected.
> > So your patch to allow including ISA devices in vga arbitration would
> > not change anything here.
> >
> > Is it known at what time the lockup happens?
> > From the kernel trace the lockup only happens during write() and not
> > already at open time. Thus the command written to /dev/vga_arbiter would
> > be helpful for proper understanding.
> > From kernel side code I think it's a call related to radeon and not
> > intel in Xorg that calls out to vga_arbiter, but please provide
> > more details (either strace&/backtrace on Xorg or kernel with pr_debug
> > active for vgaargb and corresponding kernel log).
>
> When Xorg starts up, it calls xf86VGAarbiterLock() a couple of times
> from InitOutput():
> https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/common/xf86Init.c#n569
>
> This calls pci_device_vgaarb_lock():
> https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/common/xf86VGAarbiter.c#n88
>
> And this writes to /dev/vga_arbiter:
> https://cgit.freedesktop.org/xorg/lib/libpciaccess/tree/src/common_vgaarb.c#n287
>
> Adding Tiago Vignatti to cc: who wrote much of this code.
Ok, and the device chose for the lock is probably the radeon one, thus
the lock taken by vgaarb conflicts with the one libpciaccess wants to
take for radeon driver.
If it was the intel one the kernel should not block as the the one to
be locked by userspace matches the one locked by kernel.
> > From the bug report, comment #11 I don't understand this part:
> > I boot Linux directly via rEFInd. I got the radeon xorg drivers
> > installed, but neither intel nor fbdev or kms.
> >
> > Does this mean that neither Intel KMS nor Radeon KMS are able to
> > initialize, nor simplefb's fbdev?
> > The kernel log though reports proper startup of radeon (KMS) and i915
> > (KMS) so only userspace gets caught...
> > So details on the userspace stack (xf86-video-intel and libdrm versions)
> > would be helpful as well.
>
> The kernel modules apple-gmux, i915 and radeon are present and loaded,
> but the user space Xorg driver for i915 is not installed, only radeon.
>
> But we (one the kernel side) cannot force people to have specific
> userland drivers installed to avoid deadlocks in the kernel.
Ok, that matches above.
Sure we should not block userspace indefinitely.
On userspace a try-lock instead of lock command would be an option
tough.
It seems that commit 9f5bd30818c42c6c36a51f93b4df75a2ea2bd85e might
also have made the issue worse (as the lock is becoming
effectively uninterruptible with that commit while it was not so before
(no idea if Xorg did receive signals to escape the impossible locking
attempt)
> > > For some reason the deadlock only occurs if apple-gmux loads
> > > before i915, so it seems there's a race condition in your commit.
> > > My commit ensures that this is the case, because i915 cannot
> > > probe the panel's EDID without gmux. (The panel is switched to
> > > the radeon GPU.) Notably, your commit message says that: "It is
> > > expected to load/probe gmux prior to graphics drivers." However
> > > your commit does not take any precautions to actually ensure
> > > that. What's more, now that apple-gmux *does* load before i915,
> > > your commit breaks.
> >
> > I think here userspace and kernel-side parts are getting mixed-up.
> >
> > From the failing kernel log, both i915 and radeon are loaded long
> > before the lock happens (with vgaarb being loaded yet earlier).
> >
> > The only one having trouble is Xorg (would it be possible to get a
> > backtrace of Xorg to know what code
> > called/triggered /dev/vga_arbiter and what it intends to do?).
> >
> > > I'm not really familiar with vgaarb, but grepping through the
> > > kernel tree I can find only 2 drivers which use it, i915 and
> > > vfio. In both cases, the kernel only briefly acquires a lock to
> > > write to VGA registers, and immediately releases the lock
> > > afterwards. So it looks to me like t
[PATCH 1/1] apple-gmux: Add initial documentation
On Mon, 4 Jan 2016 17:52:06 +0100 Lukas Wunner wrote: > Document what I've learned so far about the gmux so that we can > collaboratively reverse-engineer its remaining unknown bits > without everyone having to start from scratch. > > The DOC sections are bound together in the gpu.tmpl DocBook > under a new vga_switcheroo "Handlers" chapter. Eventually > this should be amended with documentation about the four other > handlers that exist so far (nouveau v1 DSM, nouveau Optimus DSM, > radeon ATPX, amdgpu ATPX). > > Requires kernel-doc with asciidoc support. > > The EFI variable was reverse-engineered by Bruno Bierbaumer > and Andreas Heider . > > Some of the remaining open questions: > > * How are vblank intervals synchronized on retinas to achieve seamless > switching? Is the DP mux capable of this? It's not mentioned in the > data sheets. Or is it done at the OS level, i.e. do we have to > synchronize vblank intervals between DRM drivers? There's a signal > coming from the panel connector and going into gmux, could this be > the vblank signal as received by the panel to properly time the > switch? > > * On retinas there's an I2C bus between gmux and the connector of the > right I/O board, apparently leading to the Parade PS8401A HDMI > repeater. What is this for, is it controlled via gmux registers? > Data sheet: > http://www.paradetech.com/products/jitter-cleaning-repeaters/ps8401/ > > * On retinas there's an I2C bus between gmux and the LED driver. > Pre-retinas connected the LED driver to SMBUS. Are there additional > gmux registers on retinas to control it? > > * The MacPro6,1 2013 also has a gmux, the same Renesas R4F2113 as the > retina MacBook Pro. The Mac Pro doesn't have a built-in display, > so what is its purpose? Power control of the dual FirePro GPUs? > Switching of the external DP/Thunderbolt ports? The iFixit teardown > clearly shows one TI HD3SS212 DisplayPort mux on the logic board next > to one of the three Thunderbolt controllers. However six muxes would > be necessary to switch all six ports between GPUs. The mux is probably > necessary for one of the display configurations allowed by Apple, > but which one? > https://www.ifixit.com/Teardown/Mac+Pro+Late+2013+Teardown/20778 > https://d3nevzfk7ii3be.cloudfront.net/igi/fELBTnt31QhnDsqq.huge > https://support.apple.com/en-us/HT202801 > > * Registers we haven't decoded yet: > 0x700 32 Bit configmap? > 0x708 32 Bit power sequence? > 0x712 8 Bit status of clock from panel on retinas? > 0x713 8 Bit dito? > 0x724 16 Bit backlight, raw value? > 0x760 32 Bit backlight > 0x764 32 Bit backlight > 0x768 8 Bit backlight > 0x76a 16 Bit backlight > 0x76c 16 Bit backlight > 0x76e 16 Bit backlight > 0x77fedp/dp/hdmi probe? retina only. Missing is also precise knowledge as to what the gmux depends on.
[Patch] x86, ia64, efifb: Move boot_vga fixup from pci to vgaarb
On Tue, 27 May 2014 Bjorn Helgaas wrote:
> On Wed, May 14, 2014 at 10:43:39PM +0200, Bruno Pr?mont wrote:
> > With commit b4aa0163056b6c70029b6e8619ce07c274351f42 Matthew Garret
>
> I think there's an emerging convention to use reference commits as
> <12-char-SHA1> ("subject"), i.e.,
>
> b4aa0163056b ("efifb: Implement vga_default_device() (v2)")
>
> for this case. Also, s/Garret/Garrett/.
Adjusted
> > introduced a efifb vga_default_device() so that EFI systems that do not
> > load shadow VBIOS or setup VGA get proper value for boot_vga PCI sysfs
> > attribute on the corresponding PCI device.
> >
> > Xorg is refusing to autodetect devices when boot_vga=0 which is the case
> > on some EFI system (e.g. MacBookAir2,1). Xorg detects the GPU and finds
> > the dri device but then bails out with "no devices detected".
> >
> > With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete
> > while having native drivers for the GPU also makes selecting
> > sysfb/efifb optional.
> >
> > Remove the efifb implementation of vga_default_device() and initialize
> > vgaarb's vga_default_device() with the PCI GPU that matches boot
> > screen_info in pci_fixup_video() [x86 and ia64 pci_fixup_video merged
> > into common function in vgaarb.c].
>
> I think it would be good to split this into two patches:
>
> 1) Merge the x86 and ia64 pci_fixup_video() implementations. This should
> have no functional change at all.
>
> 2) Whatever else you need to actually fix the bug. This will be much
> smaller, and the actual bug fix will be easier to see.
>
> It would also be nice to have a URL for a bugzilla or mailing list report
> of the problem, where there might be dmesg and/or Xorg logs.
>
> This sounds like it might be applicable for the stable kernels. If so, you
> probably should order these so the small bug-fix comes first (even though
> this may mean applying the same bugfix for x86 and ia64), and the merge
> second. That way the fix can be applied to the stable kernels without the
> merge.
Split up patches come in reply to this mail
> > Other architectures with PCI GPU might need a similar fixup.
> >
> > Note: If CONFIG_VGA_ARB is unset vga_default_device() is only available
> > as a stub that returns NULL, making this adjustment insufficient.
> > In addition, with the merge of x86/ia64 fixup code, this would
> > also result in disabled fixup.
> > Unsetting CONFIG_VGA_ARB requires CONFIG_EXPERT=y though.
>
> I'm not quite sure what this means, or if this is hint that something is
> still wrong even with this patch. Do you mean that if CONFIG_VGA_ARB is
> unset, something still doesn't work?
>
> Maybe this will become obvious to me when you split up the patch.
This means that if someone unsets CONFIG_VGA_ARB (he need to set CONFIG_EXPERT
to do so) the fixup will not happen at all.
Without fixup the systems that need to set the IORESOURCE_ROM_SHADOW
flag will not have it, and boot_vga pci device attribute will be 0
more often as well.
Moving the unified function somewhere else than vgaarb.c would fix the new
IORESOURCE_ROM_SHADOW fixup dependency on VGA_ARB, though not prevent the
issue I try to fix as vga_default_device() always returns NULL without VGA_ARB.
One possible location would be drivers/pci/quirks.c.
Bruno
> > Signed-off-by: Bruno Pr?mont
> > ---
> > This is ported to changes in pci/fixup.c that landed in 3.15-rcs.
> >
> > Is this fine to go in, if so who will take it?
> >
> > I got no feedback on my last respin (on top of 3.14 a couple of weeks ago,
> > which added moving the ia64 pci boot_vga fixup).
> > I've been running this revision for a week or so on 3.15-rc kernels here
> > (mostly EFI-enabled system, the mentioned MBA as wells as non-Apple systems
> > where the patch was not required).
[PATCH 2/2] x86, ia64: Merge common vga fixup code
The fixup code for PCI VGA devices in ia64 and x86 is mostly identical.
Merge it into a single function called from both sides.
The common code is moved to vgaarb.c which makes in dependant on
CONFIG_VGA_ARB.
Signed-off-by: Bruno Pr?mont
---
arch/ia64/pci/fixup.c| 77 ++--
arch/x86/pci/fixup.c | 76 +--
drivers/gpu/vga/vgaarb.c | 75 ++
include/linux/vgaarb.h | 37 +++
4 files changed, 116 insertions(+), 149 deletions(-)
diff --git a/arch/ia64/pci/fixup.c b/arch/ia64/pci/fixup.c
index 9ed5bef..5df22f9 100644
--- a/arch/ia64/pci/fixup.c
+++ b/arch/ia64/pci/fixup.c
@@ -9,85 +9,14 @@
#include
-/*
- * Fixup to mark boot BIOS video selected by BIOS before it changes
- *
- * From information provided by "Jon Smirl"
- *
- * The standard boot ROM sequence for an x86 machine uses the BIOS
- * to select an initial video card for boot display. This boot video
- * card will have it's BIOS copied to C in system RAM.
- * IORESOURCE_ROM_SHADOW is used to associate the boot video
- * card with this copy. On laptops this copy has to be used since
- * the main ROM may be compressed or combined with another image.
- * See pci_map_rom() for use of this flag. Before marking the device
- * with IORESOURCE_ROM_SHADOW check if a vga_default_device is already set
- * by either arch cde or vga-arbitration, if so only apply the fixup to this
- * already determined primary video card.
- */
-
-static void pci_fixup_video(struct pci_dev *pdev)
+static void pci_ia64_fixup_video(struct pci_dev *pdev)
{
- struct pci_dev *bridge;
- struct pci_bus *bus;
- u16 config;
-
if ((strcmp(ia64_platform_name, "dig") != 0)
&& (strcmp(ia64_platform_name, "hpzx1") != 0))
return;
/* Maybe, this machine supports legacy memory map. */
- if (!vga_default_device()) {
- resource_size_t start, end;
- int i;
-
- /* Does firmware framebuffer belong to us? */
- for (i=0; i < DEVICE_COUNT_RESOURCE; i++) {
- if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM))
- continue;
-
- start = pci_resource_start(pdev, i);
- end = pci_resource_end(pdev, i);
-
- if (!start || !end)
- continue;
-
- if (screen_info.lfb_base >= start &&
- (screen_info.lfb_base + screen_info.lfb_size) <
end)
- vga_set_default_device(pdev);
- }
- }
-
- /* Is VGA routed to us? */
- bus = pdev->bus;
- while (bus) {
- bridge = bus->self;
-
- /*
-* From information provided by
-* "David Miller"
-* The bridge control register is valid for PCI header
-* type BRIDGE, or CARDBUS. Host to PCI controllers use
-* PCI header type NORMAL.
-*/
- if (bridge
- &&((bridge->hdr_type == PCI_HEADER_TYPE_BRIDGE)
- ||(bridge->hdr_type == PCI_HEADER_TYPE_CARDBUS))) {
- pci_read_config_word(bridge, PCI_BRIDGE_CONTROL,
- &config);
- if (!(config & PCI_BRIDGE_CTL_VGA))
- return;
- }
- bus = bus->parent;
- }
- if (!vga_default_device() || pdev == vga_default_device()) {
- pci_read_config_word(pdev, PCI_COMMAND, &config);
- if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
- pdev->resource[PCI_ROM_RESOURCE].flags |=
IORESOURCE_ROM_SHADOW;
- dev_printk(KERN_DEBUG, &pdev->dev, "Boot video
device\n");
- vga_set_default_device(pdev);
- }
- }
+ pci_fixup_video(pdev);
}
DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_ANY_ID, PCI_ANY_ID,
- PCI_CLASS_DISPLAY_VGA, 8, pci_fixup_video);
+ PCI_CLASS_DISPLAY_VGA, 8, pci_ia64_fixup_video);
diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index 7246cf2..b599847 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -302,81 +302,7 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_MCH_PB1,pcie_r
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_MCH_PC,
pcie_rootport_aspm_quirk);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_MCH_PC1,
pcie_rootport_aspm_quirk);
-/*
- * Fixup to mark boot BIOS video selected by BIOS before it changes
- *
- * From information provided by "Jon Smirl"
- *
- * The standard boot ROM sequence for an x86 mac
[PATCH 1/2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()
With commit b4aa0163056b ("efifb: Implement vga_default_device() (v2)")
Matthew Garrett introduced a efifb vga_default_device() so that EFI
systems that do not load shadow VBIOS or setup VGA get proper value for
boot_vga PCI sysfs attribute on the corresponding PCI device.
Xorg is refusing to detect devices when boot_vga=0 which is the case on
some EFI system (e.g. MacBookAir2,1). Xorg detects the GPU and finds
the dri device but then bails out with "no devices detected".
Note: When vga_default_device() is set boot_vga PCI sysfs attribute
reflects its state. When unset this attribute is 1 whenever
IORESOURCE_ROM_SHADOW flag is set.
With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete
while having native drivers for the GPU also makes selecting
sysfb/efifb optional.
Remove the efifb implementation of vga_default_device() and initialize
vgaarb's vga_default_device() with the PCI GPU that matches boot
screen_info in pci_fixup_video().
Signed-off-by: Bruno Pr?mont
---
arch/ia64/pci/fixup.c | 21 +
arch/x86/include/asm/vga.h | 6 --
arch/x86/pci/fixup.c| 21 +
drivers/video/fbdev/efifb.c | 38 --
4 files changed, 42 insertions(+), 44 deletions(-)
diff --git a/arch/ia64/pci/fixup.c b/arch/ia64/pci/fixup.c
index eee069a..9ed5bef 100644
--- a/arch/ia64/pci/fixup.c
+++ b/arch/ia64/pci/fixup.c
@@ -37,6 +37,27 @@ static void pci_fixup_video(struct pci_dev *pdev)
return;
/* Maybe, this machine supports legacy memory map. */
+ if (!vga_default_device()) {
+ resource_size_t start, end;
+ int i;
+
+ /* Does firmware framebuffer belong to us? */
+ for (i=0; i < DEVICE_COUNT_RESOURCE; i++) {
+ if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM))
+ continue;
+
+ start = pci_resource_start(pdev, i);
+ end = pci_resource_end(pdev, i);
+
+ if (!start || !end)
+ continue;
+
+ if (screen_info.lfb_base >= start &&
+ (screen_info.lfb_base + screen_info.lfb_size) <
end)
+ vga_set_default_device(pdev);
+ }
+ }
+
/* Is VGA routed to us? */
bus = pdev->bus;
while (bus) {
diff --git a/arch/x86/include/asm/vga.h b/arch/x86/include/asm/vga.h
index 44282fb..c4b9dc2 100644
--- a/arch/x86/include/asm/vga.h
+++ b/arch/x86/include/asm/vga.h
@@ -17,10 +17,4 @@
#define vga_readb(x) (*(x))
#define vga_writeb(x, y) (*(y) = (x))
-#ifdef CONFIG_FB_EFI
-#define __ARCH_HAS_VGA_DEFAULT_DEVICE
-extern struct pci_dev *vga_default_device(void);
-extern void vga_set_default_device(struct pci_dev *pdev);
-#endif
-
#endif /* _ASM_X86_VGA_H */
diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index 94ae9ae..7246cf2 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -325,6 +325,27 @@ static void pci_fixup_video(struct pci_dev *pdev)
struct pci_bus *bus;
u16 config;
+ if (!vga_default_device()) {
+ resource_size_t start, end;
+ int i;
+
+ /* Does firmware framebuffer belong to us? */
+ for (i=0; i < DEVICE_COUNT_RESOURCE; i++) {
+ if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM))
+ continue;
+
+ start = pci_resource_start(pdev, i);
+ end = pci_resource_end(pdev, i);
+
+ if (!start || !end)
+ continue;
+
+ if (screen_info.lfb_base >= start &&
+ (screen_info.lfb_base + screen_info.lfb_size) <
end)
+ vga_set_default_device(pdev);
+ }
+ }
+
/* Is VGA routed to us? */
bus = pdev->bus;
while (bus) {
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index ae9618f..a033180 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -19,8 +19,6 @@
static bool request_mem_succeeded = false;
-static struct pci_dev *default_vga;
-
static struct fb_var_screeninfo efifb_defined = {
.activate = FB_ACTIVATE_NOW,
.height = -1,
@@ -84,18 +82,6 @@ static struct fb_ops efifb_ops = {
.fb_imageblit = cfb_imageblit,
};
-struct pci_dev *vga_default_device(void)
-{
- return default_vga;
-}
-
-EXPORT_SYMBOL_GPL(vga_default_device);
-
-void vga_set_default_device(struct pci_dev *pdev)
-{
- default_vga = pdev;
-}
-
static int efifb_setup(char *options)
{
char *this_opt;
@@ -126,30 +112,6 @@ static int efifb_setup(char *options)
}
}
- for_each_pci_dev(dev) {
- int i;
-
-
[PATCH 1/2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()
On Tue, 17 Jun 2014 16:35:42 -0600 Bjorn Helgaas wrote:
> On Mon, Jun 02, 2014 at 08:19:26PM +0200, Bruno Pr?mont wrote:
> > With commit b4aa0163056b ("efifb: Implement vga_default_device() (v2)")
> > Matthew Garrett introduced a efifb vga_default_device() so that EFI
> > systems that do not load shadow VBIOS or setup VGA get proper value for
> > boot_vga PCI sysfs attribute on the corresponding PCI device.
> >
> > Xorg is refusing to detect devices when boot_vga=0 which is the case on
> > some EFI system (e.g. MacBookAir2,1). Xorg detects the GPU and finds
> > the dri device but then bails out with "no devices detected".
> >
> > Note: When vga_default_device() is set boot_vga PCI sysfs attribute
> > reflects its state. When unset this attribute is 1 whenever
> > IORESOURCE_ROM_SHADOW flag is set.
> >
> > With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete
> > while having native drivers for the GPU also makes selecting
> > sysfb/efifb optional.
> >
> > Remove the efifb implementation of vga_default_device() and initialize
> > vgaarb's vga_default_device() with the PCI GPU that matches boot
> > screen_info in pci_fixup_video().
> >
> > Signed-off-by: Bruno Pr?mont
> > ---
> > arch/ia64/pci/fixup.c | 21 +
> > arch/x86/include/asm/vga.h | 6 --
> > arch/x86/pci/fixup.c| 21 +
> > drivers/video/fbdev/efifb.c | 38 --
> > 4 files changed, 42 insertions(+), 44 deletions(-)
>
> Something went wrong here. It seems like the [2/2] patch should have
> been [1/2], and this one should be [2/2]. And this one modifies both
> arch/ia64/pci/fixup.c and arch/x86/pci/fixup.c, but the other patch
> mostly combines them, so I don't see how this one applies.
I ordered both patches the other way around from your explicit ordering
proposal following the stable kernel suggestion following it.
My patch 1/2 fixes the encountered issue and is the one that may go
stable while my patch 2/2 performs unification of common code.
The unification will need to be placed somewhere else than in vgaarb.c
if one wants to keep current fixup working with CONFIG_VGA_ARB=n.
> And there were unrelated (trivial) changes to these files, so they
> need to be rebased to v3.16-rc1. I'd take care of the rebase, but
> I don't understand the other stuff I mentioned.
Ok
Bruno
> Bjorn
>
> > diff --git a/arch/ia64/pci/fixup.c b/arch/ia64/pci/fixup.c
> > index eee069a..9ed5bef 100644
> > --- a/arch/ia64/pci/fixup.c
> > +++ b/arch/ia64/pci/fixup.c
> > @@ -37,6 +37,27 @@ static void pci_fixup_video(struct pci_dev *pdev)
> > return;
> > /* Maybe, this machine supports legacy memory map. */
> >
> > + if (!vga_default_device()) {
> > + resource_size_t start, end;
> > + int i;
> > +
> > + /* Does firmware framebuffer belong to us? */
> > + for (i=0; i < DEVICE_COUNT_RESOURCE; i++) {
> > + if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM))
> > + continue;
> > +
> > + start = pci_resource_start(pdev, i);
> > + end = pci_resource_end(pdev, i);
> > +
> > + if (!start || !end)
> > + continue;
> > +
> > + if (screen_info.lfb_base >= start &&
> > + (screen_info.lfb_base + screen_info.lfb_size) <
> > end)
> > + vga_set_default_device(pdev);
> > + }
> > + }
> > +
> > /* Is VGA routed to us? */
> > bus = pdev->bus;
> > while (bus) {
> > diff --git a/arch/x86/include/asm/vga.h b/arch/x86/include/asm/vga.h
> > index 44282fb..c4b9dc2 100644
> > --- a/arch/x86/include/asm/vga.h
> > +++ b/arch/x86/include/asm/vga.h
> > @@ -17,10 +17,4 @@
> > #define vga_readb(x) (*(x))
> > #define vga_writeb(x, y) (*(y) = (x))
> >
> > -#ifdef CONFIG_FB_EFI
> > -#define __ARCH_HAS_VGA_DEFAULT_DEVICE
> > -extern struct pci_dev *vga_default_device(void);
> > -extern void vga_set_default_device(struct pci_dev *pdev);
> > -#endif
> > -
> > #endif /* _ASM_X86_VGA_H */
> > diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
> > index 94ae9ae..7246cf2 100644
> > --- a/arch/x86/pci/fixup.c
> > +++ b/arch/x86/pci/fixup.c
> > @@ -325,6 +325,27 @@ static void pci_fixup_video(struct pci_dev *pdev)
> > struct pci_bus *bus;
> > u16 config;
> >
> > + if (!vga_default_device()) {
> > + resource_size_t start, end;
> > + int i;
> > +
> > + /* Does firmware framebuffer belong to us? */
> > + for (i=0; i < DEVICE_COUNT_RESOURCE; i++) {
> > + if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM))
> > + continue;
> > +
> > + start = pci_resource_start(pdev, i);
> > + end = pci_resource_end(pdev, i);
> > +
> > + if (!start || !end)
> > +
[PATCH 1/2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()
On Mon, 02 June 2014 Bruno Pr?mont wrote:
> With commit b4aa0163056b ("efifb: Implement vga_default_device() (v2)")
> Matthew Garrett introduced a efifb vga_default_device() so that EFI
> systems that do not load shadow VBIOS or setup VGA get proper value for
> boot_vga PCI sysfs attribute on the corresponding PCI device.
>
> Xorg is refusing to detect devices when boot_vga=0 which is the case on
> some EFI system (e.g. MacBookAir2,1). Xorg detects the GPU and finds
> the dri device but then bails out with "no devices detected".
>
> Note: When vga_default_device() is set boot_vga PCI sysfs attribute
> reflects its state. When unset this attribute is 1 whenever
> IORESOURCE_ROM_SHADOW flag is set.
>
> With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete
> while having native drivers for the GPU also makes selecting
> sysfb/efifb optional.
>
> Remove the efifb implementation of vga_default_device() and initialize
> vgaarb's vga_default_device() with the PCI GPU that matches boot
> screen_info in pci_fixup_video().
Quite a few people trip over this issue, apparently concentrated on
Apple Macs (EFI) with Nvidia graphics.
It has shown up in at least two bugzilla reports (as side-issue):
https://bugs.freedesktop.org/show_bug.cgi?id=58556#c16
https://bugs.freedesktop.org/show_bug.cgi?id=76732#c34
My initial report and discussion on freenode, #nouveau:
http://people.freedesktop.org/~cbrill/dri-log/?channel=nouveau&date=2013-11-23
followed by initial patch proposal:
http://permalink.gmane.org/gmane.comp.video.dri.devel/95943
[PATCH 1/2 v2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()
With commit b4aa0163056b ("efifb: Implement vga_default_device() (v2)")
Matthew Garrett introduced a efifb vga_default_device() so that EFI
systems that do not load shadow VBIOS or setup VGA get proper value for
boot_vga PCI sysfs attribute on the corresponding PCI device.
Xorg is refusing to detect devices when boot_vga=0 which is the case on
some EFI system (e.g. MacBookAir2,1). Xorg detects the GPU and finds
the dri device but then bails out with "no devices detected".
Note: When vga_default_device() is set boot_vga PCI sysfs attribute
reflects its state. When unset this attribute is 1 whenever
IORESOURCE_ROM_SHADOW flag is set.
With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete
while having native drivers for the GPU also makes selecting
sysfb/efifb optional.
Remove the efifb implementation of vga_default_device() and initialize
vgaarb's vga_default_device() with the PCI GPU that matches boot
screen_info in pci_fixup_video().
Tested-by: Anibal Francisco Martinez Cortina
Cc: Matthew Garrett
Cc: stable at vger.kernel.org
Signed-off-by: Bruno Pr?mont
---
Changes since v1:
Added Tested-by, Cc
arch/ia64/pci/fixup.c | 21 +
arch/x86/include/asm/vga.h | 6 --
arch/x86/pci/fixup.c| 21 +
drivers/video/fbdev/efifb.c | 38 --
4 files changed, 42 insertions(+), 44 deletions(-)
diff --git a/arch/ia64/pci/fixup.c b/arch/ia64/pci/fixup.c
index eee069a..9ed5bef 100644
--- a/arch/ia64/pci/fixup.c
+++ b/arch/ia64/pci/fixup.c
@@ -37,6 +37,27 @@ static void pci_fixup_video(struct pci_dev *pdev)
return;
/* Maybe, this machine supports legacy memory map. */
+ if (!vga_default_device()) {
+ resource_size_t start, end;
+ int i;
+
+ /* Does firmware framebuffer belong to us? */
+ for (i=0; i < DEVICE_COUNT_RESOURCE; i++) {
+ if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM))
+ continue;
+
+ start = pci_resource_start(pdev, i);
+ end = pci_resource_end(pdev, i);
+
+ if (!start || !end)
+ continue;
+
+ if (screen_info.lfb_base >= start &&
+ (screen_info.lfb_base + screen_info.lfb_size) <
end)
+ vga_set_default_device(pdev);
+ }
+ }
+
/* Is VGA routed to us? */
bus = pdev->bus;
while (bus) {
diff --git a/arch/x86/include/asm/vga.h b/arch/x86/include/asm/vga.h
index 44282fb..c4b9dc2 100644
--- a/arch/x86/include/asm/vga.h
+++ b/arch/x86/include/asm/vga.h
@@ -17,10 +17,4 @@
#define vga_readb(x) (*(x))
#define vga_writeb(x, y) (*(y) = (x))
-#ifdef CONFIG_FB_EFI
-#define __ARCH_HAS_VGA_DEFAULT_DEVICE
-extern struct pci_dev *vga_default_device(void);
-extern void vga_set_default_device(struct pci_dev *pdev);
-#endif
-
#endif /* _ASM_X86_VGA_H */
diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index 94ae9ae..7246cf2 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -325,6 +325,27 @@ static void pci_fixup_video(struct pci_dev *pdev)
struct pci_bus *bus;
u16 config;
+ if (!vga_default_device()) {
+ resource_size_t start, end;
+ int i;
+
+ /* Does firmware framebuffer belong to us? */
+ for (i=0; i < DEVICE_COUNT_RESOURCE; i++) {
+ if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM))
+ continue;
+
+ start = pci_resource_start(pdev, i);
+ end = pci_resource_end(pdev, i);
+
+ if (!start || !end)
+ continue;
+
+ if (screen_info.lfb_base >= start &&
+ (screen_info.lfb_base + screen_info.lfb_size) <
end)
+ vga_set_default_device(pdev);
+ }
+ }
+
/* Is VGA routed to us? */
bus = pdev->bus;
while (bus) {
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index ae9618f..a033180 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -19,8 +19,6 @@
static bool request_mem_succeeded = false;
-static struct pci_dev *default_vga;
-
static struct fb_var_screeninfo efifb_defined = {
.activate = FB_ACTIVATE_NOW,
.height = -1,
@@ -84,18 +82,6 @@ static struct fb_ops efifb_ops = {
.fb_imageblit = cfb_imageblit,
};
-struct pci_dev *vga_default_device(void)
-{
- return default_vga;
-}
-
-EXPORT_SYMBOL_GPL(vga_default_device);
-
-void vga_set_default_device(struct pci_dev *pdev)
-{
- default_vga = pdev;
-}
-
static int efifb_setup(char *options)
{
char *this_opt;
@@ -126,3
[PATCH 2/2 v2] x86, ia64: Merge common vga fixup code
The fixup code for PCI VGA devices in ia64 and x86 is mostly identical.
Merge it into a single function called from both sides.
The common code is moved to vgaarb.c which makes in dependant on
CONFIG_VGA_ARB.
Tested-by: Anibal Francisco Martinez Cortina
Cc: Matthew Garrett
Signed-off-by: Bruno Pr?mont
---
Changes since v1:
Added Tested-by, Cc
arch/ia64/pci/fixup.c| 77 ++--
arch/x86/pci/fixup.c | 76 +--
drivers/gpu/vga/vgaarb.c | 75 ++
include/linux/vgaarb.h | 37 +++
4 files changed, 116 insertions(+), 149 deletions(-)
diff --git a/arch/ia64/pci/fixup.c b/arch/ia64/pci/fixup.c
index 9ed5bef..5df22f9 100644
--- a/arch/ia64/pci/fixup.c
+++ b/arch/ia64/pci/fixup.c
@@ -9,85 +9,14 @@
#include
-/*
- * Fixup to mark boot BIOS video selected by BIOS before it changes
- *
- * From information provided by "Jon Smirl"
- *
- * The standard boot ROM sequence for an x86 machine uses the BIOS
- * to select an initial video card for boot display. This boot video
- * card will have it's BIOS copied to C in system RAM.
- * IORESOURCE_ROM_SHADOW is used to associate the boot video
- * card with this copy. On laptops this copy has to be used since
- * the main ROM may be compressed or combined with another image.
- * See pci_map_rom() for use of this flag. Before marking the device
- * with IORESOURCE_ROM_SHADOW check if a vga_default_device is already set
- * by either arch cde or vga-arbitration, if so only apply the fixup to this
- * already determined primary video card.
- */
-
-static void pci_fixup_video(struct pci_dev *pdev)
+static void pci_ia64_fixup_video(struct pci_dev *pdev)
{
- struct pci_dev *bridge;
- struct pci_bus *bus;
- u16 config;
-
if ((strcmp(ia64_platform_name, "dig") != 0)
&& (strcmp(ia64_platform_name, "hpzx1") != 0))
return;
/* Maybe, this machine supports legacy memory map. */
- if (!vga_default_device()) {
- resource_size_t start, end;
- int i;
-
- /* Does firmware framebuffer belong to us? */
- for (i=0; i < DEVICE_COUNT_RESOURCE; i++) {
- if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM))
- continue;
-
- start = pci_resource_start(pdev, i);
- end = pci_resource_end(pdev, i);
-
- if (!start || !end)
- continue;
-
- if (screen_info.lfb_base >= start &&
- (screen_info.lfb_base + screen_info.lfb_size) <
end)
- vga_set_default_device(pdev);
- }
- }
-
- /* Is VGA routed to us? */
- bus = pdev->bus;
- while (bus) {
- bridge = bus->self;
-
- /*
-* From information provided by
-* "David Miller"
-* The bridge control register is valid for PCI header
-* type BRIDGE, or CARDBUS. Host to PCI controllers use
-* PCI header type NORMAL.
-*/
- if (bridge
- &&((bridge->hdr_type == PCI_HEADER_TYPE_BRIDGE)
- ||(bridge->hdr_type == PCI_HEADER_TYPE_CARDBUS))) {
- pci_read_config_word(bridge, PCI_BRIDGE_CONTROL,
- &config);
- if (!(config & PCI_BRIDGE_CTL_VGA))
- return;
- }
- bus = bus->parent;
- }
- if (!vga_default_device() || pdev == vga_default_device()) {
- pci_read_config_word(pdev, PCI_COMMAND, &config);
- if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
- pdev->resource[PCI_ROM_RESOURCE].flags |=
IORESOURCE_ROM_SHADOW;
- dev_printk(KERN_DEBUG, &pdev->dev, "Boot video
device\n");
- vga_set_default_device(pdev);
- }
- }
+ pci_fixup_video(pdev);
}
DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_ANY_ID, PCI_ANY_ID,
- PCI_CLASS_DISPLAY_VGA, 8, pci_fixup_video);
+ PCI_CLASS_DISPLAY_VGA, 8, pci_ia64_fixup_video);
diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index 7246cf2..b599847 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -302,81 +302,7 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_MCH_PB1,pcie_r
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_MCH_PC,
pcie_rootport_aspm_quirk);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_MCH_PC1,
pcie_rootport_aspm_quirk);
-/*
- * Fixup to mark boot BIOS video selected by BIOS before it ch
Re: [PATCH 1/3] kexec: get rid of late printk
On Sun, 08 September 2013 Daniel Vetter wrote: > On Sun, Sep 8, 2013 at 2:10 PM, Markus Trippelsdorf > wrote: > > kexec calls: > > printk(KERN_EMERG "Starting new kernel\n"); > > late before calling machine_shutdown(). > > However at this point the underlying fb device may have already been > > shutdown. This causes the kernel to hang. > > Fix by simply getting rid of the printk call. > > > > Signed-off-by: Markus Trippelsdorf > > Shouldn't this be taken care of with the suspend/resume_console calls? > At least that's my understanding how it works in the suspend/hibernate > code, maybe kexec needs similar treatment ... Is it suspend/resume_console? Shouldn't the fbcon be short-circuited or disabled once there is no more underlying fb? Serial console, if present, as well as netconsole if network device is still alive should continue working I would say. Bruno > -Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2 v2] vgaarb: Don't default exclusively to first video device with mem+io
Bjorn, What is missing to get these two patches pushed to Linus? Bruno On Thu, 28 Aug 2014 22:47:50 +0200 Bruno Pr?mont wrote: > On Tue, 26 August 2014 Andreas Noever wrote: > > On Sun, Aug 24, 2014 at 11:09 PM, Bruno Pr?mont wrote: > > > With commit 20cde694027e boot video device detection was moved from > > > efifb to x86 and ia64 pci/fixup.c. > > > > > > For dual-GPU Apple computers above change represents a regression as > > > code in efifb did forcefully override vga_default_device while the > > > merge did not (vgaarb happens prior to PCI fixup). > > > > > > To improve on initial device selection by vgaarb (it cannot know if > > > PCI device not behind bridges see/decode legacy VGA I/O or not), move > > > the screen_info based check from pci_video_fixup to vgaarb's init > > > function and use it to refine/override decision taken while adding > > > the individual PCI VGA devices. > > > This way PCI fixup has no reason to adjust vga_default_device > > > anymore but can depend on its value for flagging shadowed VBIOS. > > > > > > This has the nice benefit of removing duplicated code but does > > > introduce a #if defined() block in vgaarb. > > > Not all architectures have screen_info and would cause compile to > > > fail without it. > > > > > > Reported-By: Andreas Noever > > > CC: Matthew Garrett > > > CC: stable at vger.kernel.org # v3.5+ > > > Signed-off-by: Bruno Pr?mont > > > --- > > > Andreas, does this work properly for you, including the improvement > > > on i915 complaint about VBIOS going from KERN_ERR to KERN_INFO? > > Yep, thanks! > > > > > > > > Other arches using PCI and vgaarb that have screen_info may want > > > to be added to the #if defined() block or even introduce a new > > > CONFIG_HAVE_SCREEN_INFO or similar... > > Bjorn, can you queue these two patches, probably going through -next > for a week and passing them to Linus for -rc4, adding Andreas's Tested-by > to Patch 1/2 v2? > > Thanks, > Bruno
Stupid NVIDIA 3D vgaarb.c patch
On Mon, 22 September 2014 Linus Torvalds wrote: > Adding proper people and mailing lists.. > > The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by > BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is > appropriate, but hopefully somebody does. The fact that it makes > things work certainly argues fairly convincingly for it, but I want > some backup here. > > Dave, BenH? > > Christopher(?), can you please also specify which laptop etc. And the > patch itself seems to have come from somebody else, unless you're > Lekensteyn. So we'd want to get the provenance of that too. More a question to Christopher, but what criteria is preventing the use of the NVIDIA GPU under this condition? As far as I've seen on my (single-GPU) systems X requires the GPU to have boot_vga=1 sysfs attribute to accept autoconfiguration (though with two GPUs and optimus/switcheroo interaction between the GPUs may change the picture). I've been looking at the open, nouveau side of things only. If NVIDIA closed driver has some other requirement, I don't know. But as here the intention seems to be to use exclusively the NVIDIA GPU just leaving the IGD along it should require explicit X configuration which then does not care about boot_vga. A more detailed description of what prevents operation with GPU not being added to vgaarb would certainly help understanding what happens, what is expected and where things differ. Bruno > Linus > > On Mon, Sep 22, 2014 at 1:28 PM, C Bergstr?m > wrote: > > Hi Linus, > > > > I don't know who the original author is and I can have one of the distro > > graphics friends review it, but I need this patch below to get NVIDIA > > drivers to work (without using any Intel graphics) on my laptop > > http://pastebin.com/wpmFi38k > > > > Sorry - I know this is not the proper way to submit a patch, but it's > > trivial and I'm not a kernel dev. > > > > Thanks > > > > ./C
i915, HDMI/DP audio with multiple monitors
Hi, I have a system with multiple monitors and would like to send notification sounds to the monitor on which corresponding window is visible. For a workstation and a tiny computer things look different: - workstation (Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz): 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06) 00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller [8086:0c0c] (rev 06) 00:1b.0 Audio device [0403]: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller [8086:8c20] (rev 04) Here alsa show me two cards: - HDA Intel PCH (Realtek ALC671) - HDA Intel HDMI (Intel Generic) List of PLAYBACK Hardware Devices card 0: HDMI [HDA Intel HDMI], device 3: Generic Digital [Generic Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: PCH [HDA Intel PCH], device 0: ALC671 Analog [ALC671 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 - tiny computer (Intel(R) Core(TM) i5-6500T CPU @ 2.50GHz): 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 [8086:1912] (rev 06) 00:1f.3 Audio device [0403]: Intel Corporation Sunrise Point-H HD Audio [8086:a170] (rev 31) Here alsa shows a single card: - HDA Intel PCH (Realtek ALC671) List of PLAYBACK Hardware Devices card 0: PCH [HDA Intel PCH], device 0: ALC671 Analog [ALC671 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 3: Generic Digital [Generic Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 How can I determine/set to which monitor the sound should go, and preferably send different sounds to both monitors at same time? Cheers, Bruno ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915, HDMI/DP audio with multiple monitors
On Wed, 12 Sep 2018 20:06:43 +0200 Takashi Iwai wrote: > On Wed, 12 Sep 2018 19:46:58 +0200, > Ville Syrjälä wrote: > > > > On Tue, Sep 11, 2018 at 03:50:13PM +0200, Bruno Prémont wrote: > > > Hi, > > > > > > I have a system with multiple monitors and would like to send > > > notification sounds to the monitor on which corresponding > > > window is visible. > > > > > > For a workstation and a tiny computer things look different: > > > - workstation (Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz): > > > 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 > > > v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev > > > 06) > > > 00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen > > > Core Processor HD Audio Controller [8086:0c0c] (rev 06) > > > 00:1b.0 Audio device [0403]: Intel Corporation 8 Series/C220 Series > > > Chipset High Definition Audio Controller [8086:8c20] (rev 04) > > > > > > Here alsa show me two cards: > > > - HDA Intel PCH (Realtek ALC671) > > > - HDA Intel HDMI (Intel Generic) > > > > > > List of PLAYBACK Hardware Devices > > > card 0: HDMI [HDA Intel HDMI], device 3: Generic Digital [Generic > > > Digital] > > >Subdevices: 1/1 > > >Subdevice #0: subdevice #0 > > Is a proper kernel config (CONFIG_SND_HDA_CODEC_HDMI) enabled? It was missing and adding it helps a lot. Would there be a way to auto-select it when corresponding DRM driver is selected? Kind of select SND_HDA_CODEC_HDMI if SND_HDA or at least mention it in description, maybe as conditional comment is done for HDA codecs. > The device name looks strange as if it's not properly bound with the > HDMI codec driver. With SND_HDA_CODEC_HDMI enabled I get better results on the tiny computer (not checked on workstation yet): List of PLAYBACK Hardware Devices card 0: PCH [HDA Intel PCH], device 0: ALC671 Analog [ALC671 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 7: HDMI 1 [HDMI 1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 8: HDMI 2 [HDMI 2] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 9: HDMI 3 [HDMI 3] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 10: HDMI 4 [HDMI 4] Subdevices: 1/1 Subdevice #0: subdevice #0 Shown by aplay -L as: ... hdmi:CARD=PCH,DEV=0 HDA Intel PCH, HDMI 0 HDMI Audio Output hdmi:CARD=PCH,DEV=1 HDA Intel PCH, HDMI 1 HDMI Audio Output hdmi:CARD=PCH,DEV=2 HDA Intel PCH, HDMI 2 HDMI Audio Output hdmi:CARD=PCH,DEV=3 HDA Intel PCH, HDMI 3 HDMI Audio Output hdmi:CARD=PCH,DEV=4 HDA Intel PCH, HDMI 4 HDMI Audio Output Alsamixer shows me 5 S/PDIFs (S/PDIF, S/PDIF 1, ..., S/PDIF 4) which is not that helpful. Why don't alsamixer and aplay -L at least use the same naming scheme? If the naming there would match output naming as show by xrandr (or /sys/class/drm/... it would be even better! xrandr: HDMI-1 disconnected (normal left inverted right x axis y axis) DP-1 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 1439mm x 809mm HDMI-2 disconnected (normal left inverted right x axis y axis) DP-2 disconnected (normal left inverted right x axis y axis) HDMI-3 connected 3840x2160+3840+0 (normal left inverted right x axis y axis) 1872mm x 1053mm DP-3 disconnected (normal left inverted right x axis y axis) /sys/class/drm/: card0-DP-1 -> ../../devices/pci:00/:00:02.0/drm/card0/card0-DP-1 card0-DP-2 -> ../../devices/pci:00/:00:02.0/drm/card0/card0-DP-2 card0-DP-3 -> ../../devices/pci:00/:00:02.0/drm/card0/card0-DP-3 card0-HDMI-A-1 -> ../../devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-1 card0-HDMI-A-2 -> ../../devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-2 card0-HDMI-A-3 -> ../../devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-3 Testing each output with aplay I could determine that hw:0,7 (currently) matches DP-1 (as reported by xrandr) and hw:0,8 matches HDMI-3 (as reported by xrandr). Though while testing often the first sound played never reaches the monitor's speakers, only a second run shortly after the first reaches speakers. (played sound is rather short: aplay -D hw:0,7 /usr/share/sounds/purple/receive.wav same with slightly longer login.wav) Cheers, Bruno ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Nouveau failing during probe followed by GPF on 3.13-rc2
Hi, With 3.13-rc1 and 3.13-rc2 kernel crashes/BUGs while loading nouveau: [ 657.654915] ACPI Warning: \_SB_.PCI0.IXVE.IGPU._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20131115/nsarguments-95) [ 657.655099] ACPI Warning: \_SB_.PCI0.IXVE.IGPU._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20131115/nsarguments-95) [ 657.655270] checking generic (8001 64) vs hw (8000 1000) [ 657.655273] fb: conflicting fb hw usage nouveaufb vs simple - removing generic driver [ 657.655383] Console: switching to colour dummy device 80x25 [ 657.655632] nouveau :02:00.0: enabling device (0006 -> 0007) [ 657.657149] ACPI: PCI Interrupt Link [LGPU] enabled at IRQ 16 [ 657.657456] [drm] hdmi device not found 2 0 1 [ 657.657954] nouveau [ DEVICE][:02:00.0] BOOT0 : 0x0ac800b1 [ 657.657958] nouveau [ DEVICE][:02:00.0] Chipset: MCP79/MCP7A (NVAC) [ 657.657960] nouveau [ DEVICE][:02:00.0] Family : NV50 [ 657.665274] nouveau [ VBIOS][:02:00.0] checking PRAMIN for image... [ 657.722478] nouveau [ VBIOS][:02:00.0] ... appears to be valid [ 657.722481] nouveau [ VBIOS][:02:00.0] using image from PRAMIN [ 657.722624] nouveau [ VBIOS][:02:00.0] BIT signature found [ 657.722627] nouveau [ VBIOS][:02:00.0] version 62.79.47.00.01 [ 657.745324] nouveau :02:00.0: irq 42 for MSI/MSI-X [ 657.745360] nouveau [ PMC][:02:00.0] MSI interrupts enabled [ 657.745437] nouveau [ PFB][:02:00.0] RAM type: stolen system memory [ 657.745441] nouveau [ PFB][:02:00.0] RAM size: 256 MiB [ 657.745444] nouveau [ PFB][:02:00.0]ZCOMP: 0 tags [ 657.800072] nouveau [ PTHERM][:02:00.0] FAN control: none / external [ 657.800083] nouveau [ PTHERM][:02:00.0] fan management: automatic [ 657.800086] nouveau [ PTHERM][:02:00.0] internal sensor: yes [ 657.800105] nouveau [ CLK][:02:00.0] 03: core 100 MHz shader 200 MHz [ 657.800111] nouveau [ CLK][:02:00.0] 05: core 150 MHz shader 300 MHz [ 657.800116] nouveau [ CLK][:02:00.0] 0e: core 300 MHz shader 600 MHz [ 657.800121] nouveau [ CLK][:02:00.0] 0f: core 350 MHz shader 800 MHz [ 657.800135] nouveau E[ CLK][:02:00.0] 17 freq unknown [ 657.800137] nouveau E[ CLK][:02:00.0] init failed, -22 [ 657.800140] nouveau E[ DRM] failed to create 0x8080, -22 [ 657.802123] general protection fault: [#1] SMP [ 657.802130] Modules linked in: nouveau(+) ttm drm_kms_helper [ 657.802140] CPU: 0 PID: 2999 Comm: modprobe Not tainted 3.13.0-rc2-air+ #5 [ 657.802144] Hardware name: Apple Inc. MacBookAir2,1/Mac-F42D88C8, BIOS MBA21.88Z.0075.B03.0811141325 11/14/08 [ 657.802150] task: 88007f161520 ti: 88007defe000 task.ti: 88007defe000 [ 657.802154] RIP: 0010:[] [] device_del+0x10/0x1b0 [ 657.802165] RSP: 0018:88007deff9f8 EFLAGS: 00010292 [ 657.802168] RAX: RBX: 6b6b6b6b6b6b6b6b RCX: 81a6f237 [ 657.802173] RDX: 81876dea RSI: 81a6e811 RDI: 6b6b6b6b6b6b6b6b [ 657.802177] RBP: 88007deffa18 R08: 6b6b6b6b R09: [ 657.802181] R10: 880078801d00 R11: 002e R12: 6b6b6b6b6b6b6b6b [ 657.802185] R13: 88007f5720f8 R14: a010e7a0 R15: ffea [ 657.802189] FS: 7f3c23d75700() GS:88007b00() knlGS: [ 657.802194] CS: 0010 DS: ES: CR0: 8005003b [ 657.802198] CR2: 7f27436e40f0 CR3: 7db4e000 CR4: 07f0 [ 657.802201] Stack: [ 657.802204] 8134fd0b 6b6b6b6b6b6b6b6b 88007f572060 88007f5720f8 [ 657.802211] 88007deffa38 813d2ca1 88007d938058 88007da01ca8 [ 657.802217] 88007deffa58 813bdd6a 88007f572060 88007da01ca8 [ 657.802224] Call Trace: [ 657.802231] [] ? acpi_pci_irq_disable+0x3c/0x49 [ 657.802237] [] device_unregister+0x11/0x20 [ 657.802243] [] drm_sysfs_device_remove+0x1a/0x30 [ 657.802249] [] drm_unplug_minor+0x1d/0x40 [ 657.802255] [] drm_put_minor+0x3d/0x50 [ 657.802260] [] drm_dev_free+0x18/0x80 [ 657.802265] [] drm_get_pci_dev+0xaf/0x150 [ 657.802272] [] ? pcibios_set_master+0x5e/0x90 [ 657.802315] [] nouveau_drm_probe+0x24a/0x290 [nouveau] [ 657.802321] [] pci_device_probe+0x9c/0xf0 [ 657.802328] [] driver_probe_device+0x76/0x240 [ 657.802333] [] __driver_attach+0x9b/0xa0 [ 657.802339] [] ? driver_probe_device+0x240/0x240 [ 657.802345] [] bus_for_each_dev+0x55/0x90 [ 657.802350] [] driver_attach+0x19/0x20 [ 657.802355] [] bus_add_driver+0x10c/0x210 [ 657.802360] [] ? 0xa0132fff [ 657.802365] [] driver_register+0x5f/0xf0 [ 657.802370] [] ? 0xa0132fff [ 657.802375] [] __pci_register_driver+0x47/0x50 [ 657.802381] [] drm_pci_init+0x115/0x130 [ 657.802386] [] ? 0xa0132fff [ 657.802390] [] ? 0xa0132fff [ 657.
Nouveau failing during probe followed by GPF on 3.13-rc2
Hi Ilia, On Wed, 4 Dec 2013 06:15:30 -0500 Ilia Mirkin wrote: > On Wed, Dec 4, 2013 at 6:01 AM, Bruno Pr?mont wrote: > > With 3.13-rc1 and 3.13-rc2 kernel crashes/BUGs while loading nouveau: > > [ 657.654915] ACPI Warning: \_SB_.PCI0.IXVE.IGPU._DSM: Argument #4 type > > mismatch - Found [Integer], ACPI requires [Package] > > (20131115/nsarguments-95) > > [ 657.655099] ACPI Warning: \_SB_.PCI0.IXVE.IGPU._DSM: Argument #4 type > > mismatch - Found [Buffer], ACPI requires [Package] (20131115/nsarguments-95) > > [ 657.655270] checking generic (8001 64) vs hw (8000 1000) > > [ 657.655273] fb: conflicting fb hw usage nouveaufb vs simple - removing > > generic driver > > [ 657.655383] Console: switching to colour dummy device 80x25 > > [ 657.655632] nouveau :02:00.0: enabling device (0006 -> 0007) > > [ 657.657149] ACPI: PCI Interrupt Link [LGPU] enabled at IRQ 16 > > [ 657.657456] [drm] hdmi device not found 2 0 1 > > [ 657.657954] nouveau [ DEVICE][:02:00.0] BOOT0 : 0x0ac800b1 > > [ 657.657958] nouveau [ DEVICE][:02:00.0] Chipset: MCP79/MCP7A (NVAC) > > [ 657.657960] nouveau [ DEVICE][:02:00.0] Family : NV50 > > [ 657.665274] nouveau [ VBIOS][:02:00.0] checking PRAMIN for > > image... > > [ 657.722478] nouveau [ VBIOS][:02:00.0] ... appears to be valid > > [ 657.722481] nouveau [ VBIOS][:02:00.0] using image from PRAMIN > > [ 657.722624] nouveau [ VBIOS][:02:00.0] BIT signature found > > [ 657.722627] nouveau [ VBIOS][:02:00.0] version 62.79.47.00.01 > > [ 657.745324] nouveau :02:00.0: irq 42 for MSI/MSI-X > > [ 657.745360] nouveau [ PMC][:02:00.0] MSI interrupts enabled > > [ 657.745437] nouveau [ PFB][:02:00.0] RAM type: stolen system > > memory > > [ 657.745441] nouveau [ PFB][:02:00.0] RAM size: 256 MiB > > [ 657.745444] nouveau [ PFB][:02:00.0]ZCOMP: 0 tags > > [ 657.800072] nouveau [ PTHERM][:02:00.0] FAN control: none / > > external > > [ 657.800083] nouveau [ PTHERM][:02:00.0] fan management: automatic > > [ 657.800086] nouveau [ PTHERM][:02:00.0] internal sensor: yes > > [ 657.800105] nouveau [ CLK][:02:00.0] 03: core 100 MHz shader > > 200 MHz > > [ 657.800111] nouveau [ CLK][:02:00.0] 05: core 150 MHz shader > > 300 MHz > > [ 657.800116] nouveau [ CLK][:02:00.0] 0e: core 300 MHz shader > > 600 MHz > > [ 657.800121] nouveau [ CLK][:02:00.0] 0f: core 350 MHz shader > > 800 MHz > > [ 657.800135] nouveau E[ CLK][:02:00.0] 17 freq unknown > > [ 657.800137] nouveau E[ CLK][:02:00.0] init failed, -22 > > There are some patches in > http://cgit.freedesktop.org/nouveau/linux-2.6/log/?h=drm-nouveau-next > that should help with that, specifically: > > http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?h=drm-nouveau-next&id=a7e4201f0f7d47e03b851f06f8987856e8d33083 Yes, that one prevents the "freq unknown" error! It should probably be pushed to dave/linus for rc3. With it applied nouveau loads successfully. > > [ 657.800140] nouveau E[ DRM] failed to create 0x8080, -22 > > [ 657.802123] general protection fault: [#1] SMP > > [ 657.802130] Modules linked in: nouveau(+) ttm drm_kms_helper > > [ 657.802140] CPU: 0 PID: 2999 Comm: modprobe Not tainted 3.13.0-rc2-air+ > > #5 > > [ 657.802144] Hardware name: Apple Inc. MacBookAir2,1/Mac-F42D88C8, BIOS > > MBA21.88Z.0075.B03.0811141325 11/14/08 > > [ 657.802150] task: 88007f161520 ti: 88007defe000 task.ti: > > 88007defe000 > > [ 657.802154] RIP: 0010:[] [] > > device_del+0x10/0x1b0 > > [ 657.802165] RSP: 0018:88007deff9f8 EFLAGS: 00010292 > > [ 657.802168] RAX: RBX: 6b6b6b6b6b6b6b6b RCX: > > 81a6f237 > > [ 657.802173] RDX: 81876dea RSI: 81a6e811 RDI: > > 6b6b6b6b6b6b6b6b > > [ 657.802177] RBP: 88007deffa18 R08: 6b6b6b6b R09: > > > > [ 657.802181] R10: 880078801d00 R11: 002e R12: > > 6b6b6b6b6b6b6b6b > > [ 657.802185] R13: 88007f5720f8 R14: a010e7a0 R15: > > ffea > > [ 657.802189] FS: 7f3c23d75700() GS:88007b00() > > knlGS: > > [ 657.802194] CS: 0010 DS: ES: CR0: 8005003b > > [ 657.802198] CR2: 7f27436e40f0 CR3: 7db4e000 CR4: > > 07f0 > > [ 657.802201] Stack: > > [ 657.802204] 8134fd0b 6b6b6b6b6b6b6b6b 88007f572060 > > 88007f5720f8 > > [ 657.802211] 88007deffa38 813d2ca1 88007d938058 > > 88007da01ca8 > > [ 657.802217] 88007deffa58 813bdd6a 88007f572060 > > 88007da01ca8 > > [ 657.802224] Call Trace: > > [ 657.802231] [] ? acpi_pci_irq_disable+0x3c/0x49 > > [ 657.802237] [] device_unregister+0x11/0x20 > > [ 657.802243] [] drm_sysfs_device_remove+0x1a/0x30 > > [ 657.802249] [] drm_unplug_minor+0x1d/0x40 > > [ 657.80225
[PATCH v2] drm: don't double-free on driver load error
Hi Ilia, On Thu, 5 Dec 2013 09:42:49 -0500 Ilia Mirkin wrote: > All instances of drm_dev_register are followed by drm_dev_free on > failure. Don't free dev->control/render/primary on failure, as they will > be freed by drm_dev_free since commit 8f6599da8e (drm: delay minor > destruction to drm_dev_free()). Instead unplug them. This patch prevents the reported GPF for 3.13-rc2 on my MBA2,1 with GeForce 9400M. So Reported-and-tested-by: Bruno Pr?mont Resulting dmesg is: ... [ 34.179136] ACPI Warning: \_SB_.PCI0.IXVE.IGPU._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20131115/nsarguments-95) [ 34.179315] ACPI Warning: \_SB_.PCI0.IXVE.IGPU._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20131115/nsarguments-95) [ 34.179478] checking generic (8001 64) vs hw (8000 1000) [ 34.179481] fb: conflicting fb hw usage nouveaufb vs EFI VGA - removing generic driver [ 34.179587] Console: switching to colour dummy device 80x25 [ 34.179841] nouveau :02:00.0: enabling device (0006 -> 0007) [ 34.181330] ACPI: PCI Interrupt Link [LGPU] enabled at IRQ 16 [ 34.181549] [drm] hdmi device not found 2 0 1 [ 34.182041] nouveau [ DEVICE][:02:00.0] BOOT0 : 0x0ac800b1 [ 34.182044] nouveau [ DEVICE][:02:00.0] Chipset: MCP79/MCP7A (NVAC) [ 34.182047] nouveau [ DEVICE][:02:00.0] Family : NV50 [ 34.189313] nouveau [ VBIOS][:02:00.0] checking PRAMIN for image... [ 34.247351] nouveau [ VBIOS][:02:00.0] ... appears to be valid [ 34.247355] nouveau [ VBIOS][:02:00.0] using image from PRAMIN [ 34.247521] nouveau [ VBIOS][:02:00.0] BIT signature found [ 34.247525] nouveau [ VBIOS][:02:00.0] version 62.79.47.00.01 [ 34.269748] nouveau :02:00.0: irq 42 for MSI/MSI-X [ 34.269816] nouveau [ PMC][:02:00.0] MSI interrupts enabled [ 34.269956] nouveau [ PFB][:02:00.0] RAM type: stolen system memory [ 34.269963] nouveau [ PFB][:02:00.0] RAM size: 256 MiB [ 34.269969] nouveau [ PFB][:02:00.0]ZCOMP: 0 tags [ 34.328924] nouveau [ PTHERM][:02:00.0] FAN control: none / external [ 34.328935] nouveau [ PTHERM][:02:00.0] fan management: automatic [ 34.328939] nouveau [ PTHERM][:02:00.0] internal sensor: yes [ 34.328949] nouveau [ CLK][:02:00.0] 03: core 100 MHz shader 200 MHz [ 34.328954] nouveau [ CLK][:02:00.0] 05: core 150 MHz shader 300 MHz [ 34.328959] nouveau [ CLK][:02:00.0] 0e: core 300 MHz shader 600 MHz [ 34.328964] nouveau [ CLK][:02:00.0] 0f: core 350 MHz shader 800 MHz [ 34.328978] nouveau E[ CLK][:02:00.0] 17 freq unknown [ 34.328980] nouveau E[ CLK][:02:00.0] init failed, -22 [ 34.328983] nouveau E[ DRM] failed to create 0x8080, -22 [ 34.331106] nouveau: probe of :02:00.0 failed with error -22 (the probe failure being fixed by commit mentioned earlier in this thread) Thanks for the fix, Bruno > Reported-by: Bruno Pr?mont > Signed-off-by: Ilia Mirkin > --- > > v2: use drm_unplug_minor instead of just removing the puts, as suggested by > David Herrman. > > drivers/gpu/drm/drm_stub.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c > index f53d524..66dd3a0 100644 > --- a/drivers/gpu/drm/drm_stub.c > +++ b/drivers/gpu/drm/drm_stub.c > @@ -566,11 +566,11 @@ err_unload: > if (dev->driver->unload) > dev->driver->unload(dev); > err_primary_node: > - drm_put_minor(dev->primary); > + drm_unplug_minor(dev->primary); > err_render_node: > - drm_put_minor(dev->render); > + drm_unplug_minor(dev->render); > err_control_node: > - drm_put_minor(dev->control); > + drm_unplug_minor(dev->control); > err_agp: > if (dev->driver->bus->agp_destroy) > dev->driver->bus->agp_destroy(dev);
[RFC patch v2] x86: Improve boot_vga/vga_default_device() for EFI
[replaced Matthew's RedHat email with a recently used one]
> > On Sat, Nov 30, 2013 at 2:52 PM, Bruno Pr?mont wrote:
> >> With commit b4aa0163056b6c70029b6e8619ce07c274351f42 Matthew Garret
> >> introduced a efifb vga_default_device() so that EFI systems that do not
> >> load shadow VBIOS or setup VGA get proper value for boot_vga PCI sysfs
> >> attribute on the corresponding PCI device.
On Mon, 9 December 2013 Bjorn Helgaas wrote
> I like the fact that this gets back to a single vga_default_device()
> implementation. But of course Matthew could easily have done this to
> begin with, so I would defer to his judgment about this.
>
> I also like the fact that you do this in pci_fixup_video(), where
> we're already doing similar stuff. The ia64 version should be changed
> the same way (or better yet, consolidated) unless there's some reason
> they need to be different. There is a little "dig" and "hpzx1" gunk
> in the ia64 version that could be factored out into some sort of
> __weak architecture function.
There is also the difference in looking up the PCI devices that might need
fixup. For x86 the fixups apply only to VGA class, for IA64 on the other
hand the VGA class filter is within pci_fixup_video().
Additionally vga_default_device seems ignored by IA64 as it only sets
IORESOURCE_ROM_SHADOW resource flag.
Though this probably means that IA64's pci_fixup_video() has been less
maintained than x86 variant.
The only sensible place I see for factoring this out is to move the logic
to drivers/gpu/vga/vga_arb.c which is providing vga_default_device() and
just call it from respective arch's pci_fixup_video().
> >> Xorg is refusing to detect devices when boot_vga=0 which is the case
> >> on some EFI system (e.g. MacBookAir2,1). Xorg detects the GPU and finds
> >> the dri device but then bails out with "no devices detected".
> >>
> >> With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete
> >> while having native drivers for the GPU also makes selecting sysfb/efifb
> >> optional.
> >>
> >> Remove the efifb implementation of vga_default_device() and initialize
> >> vgaarb's vga_default_device() with the PCI GPU that matches boot
> >> screen_info in x86's pci_fixup_video().
> >>
> >> Notes:
> >> - Other architectures with PCI GPU might need a similar fixup.
> >> - If CONFIG_VGA_ARB is unset vga_default_device() is only available
> >> as a stub that returns NULL, making this adjustment insufficient.
> >> Unsetting CONFIG_VGA_ARB requires CONFIG_EXPERT=y though.
> >>
> >> Signed-off-by: Bruno Pr?mont
> >> ---
> >> arch/x86/include/asm/vga.h | 6 --
> >> arch/x86/pci/fixup.c | 21 +
> >> drivers/video/efifb.c | 38 --
> >> 3 files changed, 21 insertions(+), 44 deletions(-)
> >>
> >> diff --git a/arch/x86/include/asm/vga.h b/arch/x86/include/asm/vga.h
> >> index 44282fb..c4b9dc2 100644
> >> --- a/arch/x86/include/asm/vga.h
> >> +++ b/arch/x86/include/asm/vga.h
> >> @@ -17,10 +17,4 @@
> >> #define vga_readb(x) (*(x))
> >> #define vga_writeb(x, y) (*(y) = (x))
> >>
> >> -#ifdef CONFIG_FB_EFI
> >> -#define __ARCH_HAS_VGA_DEFAULT_DEVICE
> >> -extern struct pci_dev *vga_default_device(void);
> >> -extern void vga_set_default_device(struct pci_dev *pdev);
> >> -#endif
> >> -
> >> #endif /* _ASM_X86_VGA_H */
> >> diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
> >> index f5809fa..440343e 100644
> >> --- a/arch/x86/pci/fixup.c
> >> +++ b/arch/x86/pci/fixup.c
> >> @@ -6,6 +6,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include
> >> #include
> >>
> >> @@ -323,6 +324,26 @@ static void pci_fixup_video(struct pci_dev *pdev)
> >> struct pci_bus *bus;
> >> u16 config;
> >>
> >> + if (!vga_default_device()) {
> >> + resource_size_t start, end;
> >> + int i;
> >> +
> >> + for (i=0; i < DEVICE_COUNT_RESOURCE; i++) {
> >> + if (!(pci_resource_flags(pdev, i) &
> >> IORESOURCE_MEM))
> >> + continue;
> >> +
> >> + start = pci_resource_start(pdev, i);
> >> + end = pci_resource_end(pdev, i);
> >> +
> >> + if (!start || !end)
> >> + continue;
> >> +
> >> + if (screen_info.lfb_base >= start &&
> >> + (screen_info.lfb_base +
> >> screen_info.lfb_size) < end)
On Wed, 18 December 2013 David Herrmann wrote:
> On Wed, Dec 18, 2013 at 4:38 PM, David Herrmann wrote:
> > pci_resource_end() returns the address of the end, not the length, so
> > we have a double off-by-one error here, don't we?
> > Shouldn't this be:
> >(screen_info.lfb_base +
> > screen_info.lfb_size) <= end + 1)
No problem for folding this into the patch, though in case it was useful
for bisecting it might still be preferable to make it a diffe
Re: [PATCH 11/32] hid/picolcd_fb: Set FBINFO_VIRTFB flag
On Thu, 16 Nov 2023 11:27:55 +0100 Javier Martinez Canillas wrote: > Thomas Zimmermann writes: > > > The picolcd_fb driver operates on system memory. Mark the framebuffer > > accordingly. Helpers operating on the framebuffer memory will test > > for the presence of this flag. > > > > Signed-off-by: Thomas Zimmermann > > Cc: "Bruno Prémont" > > Cc: Jiri Kosina > > Cc: Benjamin Tissoires > > Cc: linux-in...@vger.kernel.org > > --- > > drivers/hid/hid-picolcd_fb.c | 1 + > > 1 file changed, 1 insertion(+) > > > > Reviewed-by: Javier Martinez Canillas Acked-by: Bruno Prémont
Re: [PATCH 15/18] HID: picoLCD: Constify lcd_ops
On Sun, 14 Apr 2024 18:36:13 +0200 Krzysztof Kozlowski wrote:
> 'struct lcd_ops' is not modified by core backlight code, so it can be
> made const for increased code safety.
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Bruno Prémont
> ---
>
> Depends on the first patch in the series.
> ---
> drivers/hid/hid-picolcd_lcd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-picolcd_lcd.c b/drivers/hid/hid-picolcd_lcd.c
> index 0c4b76de8ae5..061a33ba7b1d 100644
> --- a/drivers/hid/hid-picolcd_lcd.c
> +++ b/drivers/hid/hid-picolcd_lcd.c
> @@ -46,7 +46,7 @@ static int picolcd_check_lcd_fb(struct lcd_device *ldev,
> struct fb_info *fb)
> return fb && fb == picolcd_fbinfo((struct picolcd_data
> *)lcd_get_data(ldev));
> }
>
> -static struct lcd_ops picolcd_lcdops = {
> +static const struct lcd_ops picolcd_lcdops = {
> .get_contrast = picolcd_get_contrast,
> .set_contrast = picolcd_set_contrast,
> .check_fb = picolcd_check_lcd_fb,
>
Re: How to find out modeline without attaching actual device?
Hi Paul, On Sun, 12 August 2012 Paul Menzel wrote: > Dear Linux folks, > > regarding modelines problems with some TVs [1] and EDID quirks, Ian sent > nice patches for [2], is there a way to test what modeline the DRM > subsystem would choose without actually attaching the device? > > The problem is, the TV is at a different place and I rarely have access > to it. So it would be great if I could just use some kind of simulator > and pass the EDID to it, what connector it is on (though this should not > matter) and I get the calculated modeline as a result. > > This should be enough since I already know what modeline works. I think you can, by plugging a monitor of your choice and injecting the EDID you want to test with drm_kms_helper's edid_firmware parameter. It will then load the EDID from /lib/firmware/ instead of asking the monitor. Select CONFIG_DRM_LOAD_EDID_FIRMWARE, then when loading drm_kms_helper.ko set edid_firmware=VGA1:edid/myedid.bin module option to load EDID from /lib/firmware/edid/myedid.bin. See also Documentation/EDID/HOWTO.txt Bruno > Thanks, > > Paul > > > [1] https://bugs.freedesktop.org/show_bug.cgi?id=26294 > [2] http://lists.freedesktop.org/archives/dri-devel/2012-August/026264.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
drm/nouveau: NULL pointer deref in drm_handle_vblank() on rebind
I can easily trigger a crash in nouveau interrupt handler by unbinding and rebinding the GPU. The command used: echo $pci_device > nouveau/unbind && \ sleep 5 && \ echo $pci_device > nouveau/bind Kernel is 3.4.0 with modular drm/nouveau. GPU is NVidia nForce IGP (NV11) Unbinding seems to work fine, display switching back to VGA text mode. Rebinding the GPU slightly later causes the below trace: Bruno (analysis following below trace) [ 1432.012832] Console: switching to colour VGA+ 80x25 [ 1432.014796] drm: unregistered panic notifier [ 1432.014905] [drm] nouveau :02:00.0: Setting dpms mode 3 on vga encoder (output 0) [ 1432.026324] [drm] nouveau :02:00.0: 0xAFD8: Parsing digital output script table [ 1432.026611] [drm] nouveau :02:00.0: Restoring VGA fonts [ 1432.028353] [TTM] Finalizing pool allocator [ 1432.029325] [TTM] Zone kernel: Used memory at exit: 0 kiB [ 1437.066950] [drm] nouveau :02:00.0: Detected an NV10 generation card (0x01a000b1) [ 1437.068909] [drm] nouveau :02:00.0: Checking PRAMIN for VBIOS [ 1437.103400] [drm] nouveau :02:00.0: ... BIOS checksum invalid [ 1437.103459] [drm] nouveau :02:00.0: Checking PROM for VBIOS [ 1437.103638] [drm] nouveau :02:00.0: ... BIOS checksum invalid [ 1437.103694] [drm] nouveau :02:00.0: Checking ACPI for VBIOS [ 1437.103859] [drm] nouveau :02:00.0: ... BIOS checksum invalid [ 1437.103915] [drm] nouveau :02:00.0: Checking PCIROM for VBIOS [ 1437.105143] [drm] nouveau :02:00.0: ... appears to be valid [ 1437.105217] [drm] nouveau :02:00.0: Using VBIOS from PCIROM [ 1437.105507] [drm] nouveau :02:00.0: BMP BIOS found [ 1437.105562] [drm] nouveau :02:00.0: BMP version 5.20 [ 1437.105624] [drm] nouveau :02:00.0: Bios version 03.1a.01.03 [ 1437.107663] [drm] nouveau :02:00.0: MXM: no VBIOS data, nothing to do [ 1437.109053] [drm] nouveau :02:00.0: Parsing VBIOS init table 0 at offset 0xA850 [ 1437.109120] [drm] nouveau :02:00.0: Parsing VBIOS init table 1 at offset 0xADC5 [ 1437.109197] [drm] nouveau :02:00.0: Parsing VBIOS init table 2 at offset 0xA851 [ 1437.109268] [drm] nouveau :02:00.0: Parsing VBIOS init table 3 at offset 0xADC4 [ 1437.109337] [drm] nouveau :02:00.0: Parsing VBIOS init table 4 at offset 0xA875 [ 1437.109405] [drm] nouveau :02:00.0: Parsing VBIOS init table 5 at offset 0xA931 [ 1437.109494] [drm] nouveau :02:00.0: Parsing VBIOS init table 6 at offset 0xA876 [ 1437.109572] [drm] nouveau :02:00.0: Parsing VBIOS init table 7 at offset 0xA8CC [ 1437.109985] [TTM] Zone kernel: Available graphics memory: 240004 kiB [ 1437.110079] [TTM] Initializing pool allocator [ 1437.110177] [drm] nouveau :02:00.0: Detected 32MiB VRAM (unknown type) [ 1437.110424] agpgart-nvidia :00:00.0: AGP 2.0 bridge [ 1437.110566] agpgart-nvidia :00:00.0: putting AGP V2 device into 4x mode [ 1437.110717] nouveau :02:00.0: putting AGP V2 device into 4x mode [ 1437.110783] agpgart-nvidia :00:00.0: AGP 2.0 bridge [ 1437.110865] agpgart-nvidia :00:00.0: putting AGP V2 device into 4x mode [ 1437.111010] nouveau :02:00.0: putting AGP V2 device into 4x mode [ 1437.111070] [drm] nouveau :02:00.0: 32 MiB GART (aperture) [ 1437.111233] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.111298] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.111363] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.111427] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.111489] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.111551] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.111613] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.111676] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.111737] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.111800] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.111862] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.111924] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.111986] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.112048] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.112110] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.112172] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.112233] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.112296] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.112357] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.112420] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.112577] [drm] nouveau :02:00.0: Saving VGA fonts [ 1437.175978] BUG: unable to handle kernel NULL pointer dereference at (null) [ 1437.176134] IP: [] drm_handle_vblank+0x3c/0x1d0 [ 1437.176314] *pde = [ 1
2.6.39-rc6, nouveau: unload trips on freed memory (SLUB poison)
With 2.6.39-rc6 I'm hitting the following (relevant part from objdump of drm_mm.o at bottom). Some part of node passed to drm_mm_remove_node() is being use after free and hits SLUB poison. Bruno [ 328.447498] drm: unregistered panic notifier [ 328.447648] [drm] nouveau :02:00.0: 0xAFD8: Parsing digital output script table [ 328.448642] [drm] nouveau :02:00.0: Restoring VGA fonts [ 328.450949] [drm:drm_mm_takedown] *ERROR* Memory manager not clean. Delaying takedown [ 328.451141] BUG: unable to handle kernel paging request at 6b6b6b6f [ 328.451275] IP: [] drm_mm_remove_node+0x5a/0xc0 [ 328.451391] *pde = [ 328.451479] Oops: 0002 [#1] previous Oops was complaint about CAP_SYS_ADMIN versus CAP_SYSLOG [ 328.451566] last sysfs file: /sys/devices/platform/w83627hf.656/temp3_input [ 328.451625] Modules linked in: nouveau(-) ttm drm_kms_helper video nfs lockd nfs_acl sunrpc snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm pcspkr snd_timer snd snd_page_alloc [ 328.452361] [ 328.452410] Pid: 1740, comm: rmmod Tainted: GW 2.6.39-rc6-jupiter-1-g443badf-dirty #11 NVIDIA Corporation. nFORCE-MCP/MS-6373 [ 328.452594] EIP: 0060:[] EFLAGS: 00010202 CPU: 0 [ 328.452650] EIP is at drm_mm_remove_node+0x5a/0xc0 [ 328.452703] EAX: da4dd240 EBX: dcf44be0 ECX: dcf44bd0 EDX: dcf44bd8 [ 328.452759] ESI: 6b6b6b6b EDI: 6b6b6b6b EBP: dd64fdb8 ESP: dd64fdac [ 328.452815] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 [ 328.452870] Process rmmod (pid: 1740, ti=dd64e000 task=dd7fe120 task.ti=dd64e000) [ 328.452931] Stack: [ 328.452978] da4dd240 dcf44bd0 da4dd150 dd64fdc8 c124d417 dbebfb04 dd64fdd4 [ 328.453360] deb9f281 0090 dd64fde0 deb99853 dbebfad0 dd64fdf0 deb99b5e dbf00148 [ 328.453717] dbebfad0 dd64fe18 deb9beed def5e632 4d98 [ 328.454099] Call Trace: [ 328.454153] [] drm_mm_put_block+0x17/0x50 [ 328.454223] [] ttm_bo_man_put_node+0x11/0x20 [ttm] [ 328.454283] [] ttm_bo_mem_put+0x23/0x30 [ttm] [ 328.454364] [] ttm_bo_cleanup_memtype_use+0x2e/0x60 [ttm] [ 328.454425] [] ttm_bo_release+0x17d/0x1b0 [ttm] [ 328.454516] [] ? nouveau_gpuobj_takedown+0x92/0x100 [nouveau] [ 328.454578] [] ? ttm_bo_create+0xf0/0xf0 [ttm] [ 328.454639] [] kref_put+0x2c/0x60 [ 328.454697] [] ttm_bo_unref+0x18/0x20 [ttm] [ 328.454762] [] nouveau_mem_vram_fini+0x37/0xa0 [nouveau] [ 328.454829] [] nouveau_unload+0xd5/0x150 [nouveau] [ 328.454888] [] drm_put_dev+0xb3/0x1c0 [ 328.454953] [] nouveau_pci_remove+0x10/0x20 [nouveau] [ 328.455010] [] pci_device_remove+0x3f/0xf0 [ 328.455070] [] __device_release_driver+0x4b/0xa0 [ 328.455126] [] driver_detach+0x77/0x80 [ 328.455181] [] bus_remove_driver+0x5b/0xa0 [ 328.455236] [] driver_unregister+0x46/0x80 [ 328.455314] [] ? sysfs_remove_file+0xf/0x20 [ 328.455369] [] pci_unregister_driver+0x2a/0x70 [ 328.455438] [] drm_pci_exit+0x7f/0x90 [ 328.455506] [] nouveau_exit+0x1b/0x22 [nouveau] [ 328.455564] [] sys_delete_module+0x19b/0x1f0 [ 328.455622] [] ? do_munmap+0x212/0x2f0 [ 328.455678] [] sysenter_do_call+0x12/0x26 [ 328.455731] Code: 8b 70 08 8b 58 0c 89 5e 04 89 33 c7 40 08 00 01 10 00 c7 40 0c 00 02 20 00 0f b6 5a 10 f6 c3 01 74 57 8b 7a 08 8b 72 0c 8d 5a 08 [ 328.457446] 77 04 89 3e 8b 31 89 5e 04 89 72 08 89 4a 0c 89 19 8b 08 8b [ 328.458342] EIP: [] drm_mm_remove_node+0x5a/0xc0 SS:ESP 0068:dd64fdac [ 328.458481] CR2: 6b6b6b6f [ 328.459085] ---[ end trace cb7019e5756bd7f0 ]--- [ 502.313511] = [ 502.313597] BUG kmalloc-96: Poison overwritten [ 502.313650] - [ 502.313653] [ 502.313774] INFO: 0xdcf44bd0-0xdcf44bd7. First byte 0xd0 instead of 0x6b [ 502.313832] INFO: Slab 0xddfce880 objects=36 used=26 fp=0xdcf44bd0 flags=0x40c0 [ 502.313895] INFO: Object 0xdcf44bd0 @offset=3024 fp=0xdcf44e00 [ 502.313897] [ 502.313995] Bytes b4 0xdcf44bc0: cc cc cc cc d0 4b f4 dc 5a 5a 5a 5a 5a 5a 5a 5a K [ 502.314708] Object 0xdcf44bd0: d0 4b f4 dc d0 4b f4 dc 6b 6b 6b 6b 6b 6b 6b 6b KK [ 502.315417] Object 0xdcf44be0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 502.316134] Object 0xdcf44bf0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 502.316852] Object 0xdcf44c00: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 502.317570] Object 0xdcf44c10: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 502.318286] Object 0xdcf44c20: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkk [ 502.319014] Redzone 0xdcf44c30: bb bb bb bb [ 502.319724] Padding 0xdcf44c38: 5a 5a 5a 5a 5a 5a 5a 5a [ 502.320004] Pid: 1750, comm: agetty Tainted: G D W 2.6.39-r
Re: 2.6.39-rc6, nouveau: unload trips on freed memory (SLUB poison)
On Thu, 05 May 2011 Bruno Prémont wrote: > With 2.6.39-rc6 I'm hitting the following (relevant part from objdump of > drm_mm.o at bottom). > Some part of node passed to drm_mm_remove_node() is being use after free > and hits SLUB poison. > > Bruno > > > [ 328.447498] drm: unregistered panic notifier > [ 328.447648] [drm] nouveau :02:00.0: 0xAFD8: Parsing digital output > script table > [ 328.448642] [drm] nouveau :02:00.0: Restoring VGA fonts > [ 328.450949] [drm:drm_mm_takedown] *ERROR* Memory manager not clean. > Delaying takedown Here is the trace to the erroring drm_mm_takedown() call: [ 95.486464] [drm:drm_mm_takedown] *ERROR* Memory manager not clean. Delaying takedown [ 95.486585] [ cut here ] [ 95.486640] kernel BUG at /usr/src/linux-2.6/drivers/gpu/drm/drm_mm.c:628! [ 95.486697] invalid opcode: [#1] [ 95.486805] last sysfs file: /sys/devices/platform/w83627hf.656/temp3_input [ 95.486862] Modules linked in: nouveau(-) fbcon tileblit font ttm bitblit softcursor drm_kms_helper drm fb fbdev i2c_algo_bit cfbcopyarea video cfbimgblt cfbfillrect nfs lockd nfs_acl sunrpc snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd snd_page_alloc pcspkr [ 95.488061] [ 95.488121] Pid: 1714, comm: rmmod Tainted: GW 2.6.39-rc6-jupiter-1-g443badf-dirty #13 NVIDIA Corporation. nFORCE-MCP/MS-6373 [ 95.488306] EIP: 0060:[] EFLAGS: 00010292 CPU: 0 [ 95.488397] EIP is at drm_mm_takedown+0x7c/0x80 [drm] [ 95.488451] EAX: 005f EBX: da148620 ECX: fed5 EDX: [ 95.488508] ESI: da148620 EDI: 0090 EBP: dbc47e18 ESP: dbc47e04 [ 95.488563] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 [ 95.488631] Process rmmod (pid: 1714, ti=dbc46000 task=dd446470 task.ti=dbc46000) [ 95.488693] Stack: [ 95.488740] deb62a24 deb5c8ab da148620 da0001e8 0090 dbc47e28 dec5934b da000148 [ 95.489099] da0001d8 dbc47e44 dec550eb dbc47e44 def998cb da204820 da00 da00 [ 95.489469] dbc47e64 def6dc51 deb5c280 da000148 da204830 da204820 dd5270c0 dd5271d8 [ 95.489839] Call Trace: [ 95.489907] [] ttm_bo_man_takedown+0x2b/0x50 [ttm] [ 95.489968] [] ttm_bo_clean_mm+0x5b/0xa0 [ttm] [ 95.490063] [] ? nv10_fb_takedown+0x2b/0x50 [nouveau] [ 95.490130] [] nouveau_unload+0xa1/0x150 [nouveau] [ 95.490198] [] drm_put_dev+0xb3/0x1c0 [drm] [ 95.490263] [] nouveau_pci_remove+0x10/0x20 [nouveau] [ 95.490325] [] pci_device_remove+0x3f/0xf0 [ 95.490384] [] __device_release_driver+0x4b/0xa0 [ 95.490424] [] driver_detach+0x77/0x80 [ 95.490424] [] bus_remove_driver+0x5b/0xa0 [ 95.490424] [] driver_unregister+0x46/0x80 [ 95.490424] [] ? sysfs_remove_file+0xf/0x20 [ 95.490424] [] pci_unregister_driver+0x2a/0x70 [ 95.490424] [] drm_pci_exit+0x7f/0x90 [drm] [ 95.490424] [] nouveau_exit+0x1b/0x22 [nouveau] [ 95.490424] [] sys_delete_module+0x19b/0x1f0 [ 95.490424] [] ? do_munmap+0x212/0x2f0 [ 95.490424] [] sysenter_do_call+0x12/0x26 [ 95.490424] Code: 75 d5 85 c9 75 0d 83 c4 08 5b 5e 5f c9 c3 8b 4e 30 eb ef 0f 0b eb fe c7 44 24 04 ab c8 b5 de c7 04 24 24 2a b6 de e8 75 bc 81 e2 <0f> 0b eb fe 55 89 e5 56 53 8b 58 1c ff 4b 48 0f b6 50 10 f6 c2 [ 95.490424] EIP: [] drm_mm_takedown+0x7c/0x80 [drm] SS:ESP 0068:dbc47e04 [ 95.494410] ---[ end trace ea6b63472f535569 ]--- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: intelfb refuses to load
Hi, Looks like you are using the wrong intel driver. For intel modesetting you need CONFIG_DRM=y CONFIG_DRM_KMS_HELPER=y # CONFIG_DRM_TDFX is not set # CONFIG_DRM_R128 is not set # CONFIG_DRM_RADEON is not set # CONFIG_DRM_I810 is not set # CONFIG_DRM_I830 is not set CONFIG_DRM_I915=y # CONFIG_DRM_I915_KMS is not set # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set # CONFIG_DRM_VIA is not set # CONFIG_DRM_SAVAGE is not set # CONFIG_FB_I810 is not set That will give you inteldrmfb. ^^^ Not sure what dependency is missing in your config that DRM_I915 does not show up... (it might be CONFIG_AGP_INTEL) intelfb (CONFIG_FB_I810) is obsolete and only supports a pretty limited part of intel GPU features, modesetting only for VGA output (and not sure it works at all with recent GPUs). Bruno On Sat, 11 December 2010 Pavel Machek wrote: > Hi! > > I'm trying to fix up my kernel setup so that X is happy... currently > it fails to start with: > > FATAL: Could not load /lib/modules/2.6.37-rc5+/modules.dep: No such > file or directory > (EE) intel(0): No kernel modesetting driver detected. > (EE) Screen(s) found, but none have a usable configuration. > > So far I have: > > CONFIG_DRM=y > # CONFIG_DRM_TDFX is not set > # CONFIG_DRM_R128 is not set > # CONFIG_DRM_RADEON is not set > # CONFIG_DRM_I810 is not set > # CONFIG_DRM_MGA is not set > # CONFIG_DRM_SIS is not set > # CONFIG_DRM_VIA is not set > # CONFIG_DRM_SAVAGE is not set > # CONFIG_STUB_POULSBO is not set > CONFIG_VGASTATE=y > CONFIG_VIDEO_OUTPUT_CONTROL=y > CONFIG_FB=y > CONFIG_FB_I810=y > # CONFIG_FB_I810_GTF is not set > # CONFIG_FB_LE80578 is not set > CONFIG_FB_INTEL=y > CONFIG_FB_INTEL_DEBUG=y > CONFIG_FB_INTEL_I2C=y > # CONFIG_FB_MATROX is not set > > And on the command line: > > BOOT_IMAGE=(hd0,2)/l/linux-good/arch/i386/boot/bzImage root=/dev/sda4 > resume=/dev/sda1 psmouse.psmouse_proto=imps psmouse_proto=imps > psmouse.proto=imps vga=791 init=/tmp/swsusp-init > acpi_sleep=s3_bios,s3_mode no_console_suspend i915.modeset=1 > video=intelfb:mode=1024x768 fbcon=scrollback:64k > > ...but intelfb fails with: > > [drm] Initialized drm 1.1.0 20060810 > intelfb: intelfb_init > intelfb: Framebuffer driver for Intel(R) > 830M/845G/852GM/855GM/865G/915G/915GM/945G/945GM/945GME/965G/965GM > chipsets > intelfb: Version 0.9.6 > intelfb: intelfb_setup > intelfb: options: mode=1024x768 > intelfb: intelfb_pci_register > intelfb :00:02.0: power state changed by ACPI to D0 > intelfb :00:02.0: power state changed by ACPI to D0 > intelfb :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 > intelfb: fb aperture: 0xd000/0x1000, MMIO region: > 0xee10/0x8 > intelfb: Cannot reserve FB region. > intelfb: cleanup > > Any hints? If I'm doing some trivial mistake, perhaps "cannot reserve > FB region" message could be improved? > Pavel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: s2ram slow (radeon) / failing (usb)
On Sun, 02 May 2010 Alan Stern wrote: > On Sun, 2 May 2010, Bruno [UTF-8] Prémont wrote: > > On a IEI Kino 690S1 I'm having a hard time to get s2ram running. > > It freezes during device suspend (unless I rmmod everything USB > > related) - usb fails even in pm_test case 'devices'. > > > > When the system is able to suspend it takes an eternity (more than 3 > > minutes to wake-up, the radeon apparently being responsible for quite > > a big share of that slowness. > > > > > > During resume early it looks like every PCI access needs about a second, > > and there are a few cases where during lots of seconds nothing seems to > > happen and the first event following is related to radeon. > > > > The kernel used is todays Linus's tree at commit > > be1066bbcd443a65df312fdecea7e4959adedb45 > > with Dave's drm-linus and drm-radeon-testing applied on top. > > > > Note, I've not been able to suspend to RAM properly recently (last one > > that worked correctly but resumed without graphics was some-when during > > 2.6.2x, before KMS) > > Since then the system would either fail suspend or resume. > > > > Manual changes I applied in order to find out some context information: > > - add a few debugging printk's to ata/ahci as that was the last entry > > on serial console for freezing suspends (that one succeeded but > > following step never completed, from suspend_prepare that would have > > been USB => unload usb before suspend) > > - strip "if EMBEDED" from CONFIG_SERIAL_8250_PNP and disabled it so serial > > console would continue working as long as possible and output suspend > > progress (resume output happens only very late) > > > > Is there some additional information I could gather in order do help > > improving s2ram on this system? > > - get it to suspend with usb loaded (ohci + ehci) > > - get it to resume a reasonable speed > > There's no way to fix the USB problem without knowing what goes wrong. > Let's see how far you get before the system freezes on a kernel with > CONFIG_USB_DEBUG enabled. Am I missing something? I've enabled CONFIG_USB_DEBUG but don't see any additional module parameter nor anything extra to toggle and I don't get more output than without it. Device suspend (pm_test = device) works well when there is no USB device connected, but with USB keyboard I get the freeze (though the keyboard is still usable, e.g. CAPS key works and I can issue SYSRQ commands). When I issue sysreq-t, I find the following suspicious entry: [ 669.112505] usbhid_resume D 88007a085fd8 0 1145 2 0x [ 669.112505] 88007a085e20 0046 88007a085fd8 88007c536820 [ 669.112505] 88007a085fd8 88007a085fd8 000129c0 000129c0 [ 669.112505] 88007c536820 88007cf3f040 88007a085fd8 88007a085fd8 [ 669.112505] Call Trace: [ 669.112505] [] refrigerator+0x95/0xf0 [ 669.112505] [] worker_thread+0xc6/0x1e0 [ 669.112505] [] ? autoremove_wake_function+0x0/0x40 [ 669.112505] [] ? worker_thread+0x0/0x1e0 [ 669.112505] [] kthread+0x8e/0xa0 [ 669.112505] [] kernel_thread_helper+0x4/0x10 [ 669.112505] [] ? kthread+0x0/0xa0 [ 669.112505] [] ? kernel_thread_helper+0x0/0x10 Except for that one there are a few async/* tasks waiting. Thanks, Bruno ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: s2ram slow (radeon) / failing (usb)
On Sun, 02 May 2010 "Rafael J. Wysocki" wrote: > On Sunday 02 May 2010, Bruno Prémont wrote: > > On Sun, 02 May 2010 Alan Stern wrote: > > > On Sun, 2 May 2010, Bruno [UTF-8] Prémont wrote: > > > > On a IEI Kino 690S1 I'm having a hard time to get s2ram running. > > > > It freezes during device suspend (unless I rmmod everything USB > > > > related) - usb fails even in pm_test case 'devices'. > > > > > > > > When the system is able to suspend it takes an eternity (more than 3 > > > > minutes to wake-up, the radeon apparently being responsible for quite > > > > a big share of that slowness. > > > > > > > > > > > > During resume early it looks like every PCI access needs about a second, > > > > and there are a few cases where during lots of seconds nothing seems to > > > > happen and the first event following is related to radeon. > > > > > > > > The kernel used is todays Linus's tree at commit > > > > be1066bbcd443a65df312fdecea7e4959adedb45 > > > > with Dave's drm-linus and drm-radeon-testing applied on top. > > > > > > > > Note, I've not been able to suspend to RAM properly recently (last one > > > > that worked correctly but resumed without graphics was some-when during > > > > 2.6.2x, before KMS) > > > > Since then the system would either fail suspend or resume. > > > > > > > > Manual changes I applied in order to find out some context information: > > > > - add a few debugging printk's to ata/ahci as that was the last entry > > > > on serial console for freezing suspends (that one succeeded but > > > > following step never completed, from suspend_prepare that would have > > > > been USB => unload usb before suspend) > > > > - strip "if EMBEDED" from CONFIG_SERIAL_8250_PNP and disabled it so > > > > serial > > > > console would continue working as long as possible and output suspend > > > > progress (resume output happens only very late) > > > > > > > > Is there some additional information I could gather in order do help > > > > improving s2ram on this system? > > > > - get it to suspend with usb loaded (ohci + ehci) > > > > - get it to resume a reasonable speed > > > > > > There's no way to fix the USB problem without knowing what goes wrong. > > > Let's see how far you get before the system freezes on a kernel with > > > CONFIG_USB_DEBUG enabled. > > > > Am I missing something? > > > > I've enabled CONFIG_USB_DEBUG but don't see any additional module parameter > > nor anything extra to toggle and I don't get more output than without it. > > > > Device suspend (pm_test = device) works well when there is no USB device > > connected, but with USB keyboard I get the freeze (though the keyboard > > is still usable, e.g. CAPS key works and I can issue SYSRQ commands). > > > > When I issue sysreq-t, I find the following suspicious entry: > > [ 669.112505] usbhid_resume D 88007a085fd8 0 1145 2 > > 0x > > [ 669.112505] 88007a085e20 0046 88007a085fd8 > > 88007c536820 > > [ 669.112505] 88007a085fd8 88007a085fd8 000129c0 > > 000129c0 > > [ 669.112505] 88007c536820 88007cf3f040 88007a085fd8 > > 88007a085fd8 > > [ 669.112505] Call Trace: > > [ 669.112505] [] refrigerator+0x95/0xf0 > > [ 669.112505] [] worker_thread+0xc6/0x1e0 > > [ 669.112505] [] ? autoremove_wake_function+0x0/0x40 > > [ 669.112505] [] ? worker_thread+0x0/0x1e0 > > [ 669.112505] [] kthread+0x8e/0xa0 > > [ 669.112505] [] kernel_thread_helper+0x4/0x10 > > [ 669.112505] [] ? kthread+0x0/0xa0 > > [ 669.112505] [] ? kernel_thread_helper+0x0/0x10 > > > > Except for that one there are a few async/* tasks waiting. > > It looks like the freezer fails on your system. > > How much time did you wait for the failig "pm_test = device" to recover? I've given it at least 5 minutes, but didn't check exactly. Is there a (big) timeout that could happen, if so how long is it? Thanks, Bruno Those async threads looked like: [ 669.112505] async/15 D 0 2213 2 0x [ 669.112505] 8800797dbc80 0046 8800797dbfd8 88007aff8820 [ 669.112505] 8800797dbfd8 8800797dbfd8 000129c0
Re: s2ram slow (radeon) / failing (usb)
On Sun, 2 May 2010 17:59:17 -0400 (EDT) Alan Stern wrote: > On Sun, 2 May 2010, Bruno [UTF-8] Prémont wrote: > > > > There's no way to fix the USB problem without knowing what goes > > > wrong. Let's see how far you get before the system freezes on a > > > kernel with CONFIG_USB_DEBUG enabled. > > > > Am I missing something? > > > > I've enabled CONFIG_USB_DEBUG but don't see any additional module > > parameter nor anything extra to toggle and I don't get more output > > than without it. > > Depends what you mean by "output". The kernel generates more log > messages, but they may not get sent to your console. You need to > make sure the console's log level is set high enough to see debugging > messages. For example: > > echo 9 >/proc/sys/kernel/printk > > or type Alt-SysRq-9. I've been doing `dmesg -n 8` (9 is rejected as invalid) so it should send out everything. It looked like there was some more output during boot-up, but nothing during suspend, at least up to the freezing point. Bruno ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: s2ram slow resume - radeon versus no_console_suspend?
On Sun, 02 May 2010 Bruno Prémont wrote: > On a IEI Kino 690S1 I'm having a hard time to get s2ram running. > > When the system is able to suspend it takes an eternity (more than 3 > minutes to wake-up, the radeon apparently being responsible for quite > a big share of that slowness. > > > During resume early it looks like every PCI access needs about a second, > and there are a few cases where during lots of seconds nothing seems to > happen and the first event following is related to radeon. This slowness only happens when I run the kernel with no_console_suspend parameter (e.g. to debug some suspend/resume issue). This probably means that in this case radeon's PCI config recorded during suspend and restored during early resume is all but appropriate... Currently drm/radeon does not suspend when no_console_suspend is provided, even so when the kernel logging does not happen on tty0 & co. e.g. I would expect that a kernel run with no_console_suspend console=ttyS0 would just skip suspending serial port ttyS0 and not also skip suspending KMS framebuffer as it currently does. In most framebuffer devices I see usage of acquire_console_sem() and release_console_sem() but except for kernel/printk.c and drivers/serial/ code nothing is considering console_suspend_enabled. Currently I'm not sure what code path prevents suspend of KMS (at least for radeon) when no_console_suspend has been passed, this code path should probably have a conditional just as serial to take no_console_suspend only if it's running kernel's console itself. Thanks, Bruno ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
How to find out modeline without attaching actual device?
Hi Paul, On Sun, 12 August 2012 Paul Menzel wrote: > Dear Linux folks, > > regarding modelines problems with some TVs [1] and EDID quirks, Ian sent > nice patches for [2], is there a way to test what modeline the DRM > subsystem would choose without actually attaching the device? > > The problem is, the TV is at a different place and I rarely have access > to it. So it would be great if I could just use some kind of simulator > and pass the EDID to it, what connector it is on (though this should not > matter) and I get the calculated modeline as a result. > > This should be enough since I already know what modeline works. I think you can, by plugging a monitor of your choice and injecting the EDID you want to test with drm_kms_helper's edid_firmware parameter. It will then load the EDID from /lib/firmware/ instead of asking the monitor. Select CONFIG_DRM_LOAD_EDID_FIRMWARE, then when loading drm_kms_helper.ko set edid_firmware=VGA1:edid/myedid.bin module option to load EDID from /lib/firmware/edid/myedid.bin. See also Documentation/EDID/HOWTO.txt Bruno > Thanks, > > Paul > > > [1] https://bugs.freedesktop.org/show_bug.cgi?id=26294 > [2] http://lists.freedesktop.org/archives/dri-devel/2012-August/026264.html
2.6.39-rc6, nouveau: unload trips on freed memory (SLUB poison)
With 2.6.39-rc6 I'm hitting the following (relevant part from objdump of drm_mm.o at bottom). Some part of node passed to drm_mm_remove_node() is being use after free and hits SLUB poison. Bruno [ 328.447498] drm: unregistered panic notifier [ 328.447648] [drm] nouveau :02:00.0: 0xAFD8: Parsing digital output script table [ 328.448642] [drm] nouveau :02:00.0: Restoring VGA fonts [ 328.450949] [drm:drm_mm_takedown] *ERROR* Memory manager not clean. Delaying takedown [ 328.451141] BUG: unable to handle kernel paging request at 6b6b6b6f [ 328.451275] IP: [] drm_mm_remove_node+0x5a/0xc0 [ 328.451391] *pde = [ 328.451479] Oops: 0002 [#1] previous Oops was complaint about CAP_SYS_ADMIN versus CAP_SYSLOG [ 328.451566] last sysfs file: /sys/devices/platform/w83627hf.656/temp3_input [ 328.451625] Modules linked in: nouveau(-) ttm drm_kms_helper video nfs lockd nfs_acl sunrpc snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm pcspkr snd_timer snd snd_page_alloc [ 328.452361] [ 328.452410] Pid: 1740, comm: rmmod Tainted: GW 2.6.39-rc6-jupiter-1-g443badf-dirty #11 NVIDIA Corporation. nFORCE-MCP/MS-6373 [ 328.452594] EIP: 0060:[] EFLAGS: 00010202 CPU: 0 [ 328.452650] EIP is at drm_mm_remove_node+0x5a/0xc0 [ 328.452703] EAX: da4dd240 EBX: dcf44be0 ECX: dcf44bd0 EDX: dcf44bd8 [ 328.452759] ESI: 6b6b6b6b EDI: 6b6b6b6b EBP: dd64fdb8 ESP: dd64fdac [ 328.452815] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 [ 328.452870] Process rmmod (pid: 1740, ti=dd64e000 task=dd7fe120 task.ti=dd64e000) [ 328.452931] Stack: [ 328.452978] da4dd240 dcf44bd0 da4dd150 dd64fdc8 c124d417 dbebfb04 dd64fdd4 [ 328.453360] deb9f281 0090 dd64fde0 deb99853 dbebfad0 dd64fdf0 deb99b5e dbf00148 [ 328.453717] dbebfad0 dd64fe18 deb9beed def5e632 4d98 [ 328.454099] Call Trace: [ 328.454153] [] drm_mm_put_block+0x17/0x50 [ 328.454223] [] ttm_bo_man_put_node+0x11/0x20 [ttm] [ 328.454283] [] ttm_bo_mem_put+0x23/0x30 [ttm] [ 328.454364] [] ttm_bo_cleanup_memtype_use+0x2e/0x60 [ttm] [ 328.454425] [] ttm_bo_release+0x17d/0x1b0 [ttm] [ 328.454516] [] ? nouveau_gpuobj_takedown+0x92/0x100 [nouveau] [ 328.454578] [] ? ttm_bo_create+0xf0/0xf0 [ttm] [ 328.454639] [] kref_put+0x2c/0x60 [ 328.454697] [] ttm_bo_unref+0x18/0x20 [ttm] [ 328.454762] [] nouveau_mem_vram_fini+0x37/0xa0 [nouveau] [ 328.454829] [] nouveau_unload+0xd5/0x150 [nouveau] [ 328.454888] [] drm_put_dev+0xb3/0x1c0 [ 328.454953] [] nouveau_pci_remove+0x10/0x20 [nouveau] [ 328.455010] [] pci_device_remove+0x3f/0xf0 [ 328.455070] [] __device_release_driver+0x4b/0xa0 [ 328.455126] [] driver_detach+0x77/0x80 [ 328.455181] [] bus_remove_driver+0x5b/0xa0 [ 328.455236] [] driver_unregister+0x46/0x80 [ 328.455314] [] ? sysfs_remove_file+0xf/0x20 [ 328.455369] [] pci_unregister_driver+0x2a/0x70 [ 328.455438] [] drm_pci_exit+0x7f/0x90 [ 328.455506] [] nouveau_exit+0x1b/0x22 [nouveau] [ 328.455564] [] sys_delete_module+0x19b/0x1f0 [ 328.455622] [] ? do_munmap+0x212/0x2f0 [ 328.455678] [] sysenter_do_call+0x12/0x26 [ 328.455731] Code: 8b 70 08 8b 58 0c 89 5e 04 89 33 c7 40 08 00 01 10 00 c7 40 0c 00 02 20 00 0f b6 5a 10 f6 c3 01 74 57 8b 7a 08 8b 72 0c 8d 5a 08 [ 328.457446] 77 04 89 3e 8b 31 89 5e 04 89 72 08 89 4a 0c 89 19 8b 08 8b [ 328.458342] EIP: [] drm_mm_remove_node+0x5a/0xc0 SS:ESP 0068:dd64fdac [ 328.458481] CR2: 6b6b6b6f [ 328.459085] ---[ end trace cb7019e5756bd7f0 ]--- [ 502.313511] = [ 502.313597] BUG kmalloc-96: Poison overwritten [ 502.313650] - [ 502.313653] [ 502.313774] INFO: 0xdcf44bd0-0xdcf44bd7. First byte 0xd0 instead of 0x6b [ 502.313832] INFO: Slab 0xddfce880 objects=36 used=26 fp=0xdcf44bd0 flags=0x40c0 [ 502.313895] INFO: Object 0xdcf44bd0 @offset=3024 fp=0xdcf44e00 [ 502.313897] [ 502.313995] Bytes b4 0xdcf44bc0: cc cc cc cc d0 4b f4 dc 5a 5a 5a 5a 5a 5a 5a 5a K [ 502.314708] Object 0xdcf44bd0: d0 4b f4 dc d0 4b f4 dc 6b 6b 6b 6b 6b 6b 6b 6b KK [ 502.315417] Object 0xdcf44be0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 502.316134] Object 0xdcf44bf0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 502.316852] Object 0xdcf44c00: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 502.317570] Object 0xdcf44c10: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 502.318286] Object 0xdcf44c20: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkk [ 502.319014] Redzone 0xdcf44c30: bb bb bb bb [ 502.319724] Padding 0xdcf44c38: 5a 5a 5a 5a 5a 5a 5a 5a [ 502.320004] Pid: 1750, comm: agetty Tainted: G D W 2.6.39-r
2.6.39-rc6, nouveau: unload trips on freed memory (SLUB poison)
On Thu, 05 May 2011 Bruno Pr?mont wrote: > With 2.6.39-rc6 I'm hitting the following (relevant part from objdump of > drm_mm.o at bottom). > Some part of node passed to drm_mm_remove_node() is being use after free > and hits SLUB poison. > > Bruno > > > [ 328.447498] drm: unregistered panic notifier > [ 328.447648] [drm] nouveau :02:00.0: 0xAFD8: Parsing digital output > script table > [ 328.448642] [drm] nouveau :02:00.0: Restoring VGA fonts > [ 328.450949] [drm:drm_mm_takedown] *ERROR* Memory manager not clean. > Delaying takedown Here is the trace to the erroring drm_mm_takedown() call: [ 95.486464] [drm:drm_mm_takedown] *ERROR* Memory manager not clean. Delaying takedown [ 95.486585] [ cut here ] [ 95.486640] kernel BUG at /usr/src/linux-2.6/drivers/gpu/drm/drm_mm.c:628! [ 95.486697] invalid opcode: [#1] [ 95.486805] last sysfs file: /sys/devices/platform/w83627hf.656/temp3_input [ 95.486862] Modules linked in: nouveau(-) fbcon tileblit font ttm bitblit softcursor drm_kms_helper drm fb fbdev i2c_algo_bit cfbcopyarea video cfbimgblt cfbfillrect nfs lockd nfs_acl sunrpc snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd snd_page_alloc pcspkr [ 95.488061] [ 95.488121] Pid: 1714, comm: rmmod Tainted: GW 2.6.39-rc6-jupiter-1-g443badf-dirty #13 NVIDIA Corporation. nFORCE-MCP/MS-6373 [ 95.488306] EIP: 0060:[] EFLAGS: 00010292 CPU: 0 [ 95.488397] EIP is at drm_mm_takedown+0x7c/0x80 [drm] [ 95.488451] EAX: 005f EBX: da148620 ECX: fed5 EDX: [ 95.488508] ESI: da148620 EDI: 0090 EBP: dbc47e18 ESP: dbc47e04 [ 95.488563] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 [ 95.488631] Process rmmod (pid: 1714, ti=dbc46000 task=dd446470 task.ti=dbc46000) [ 95.488693] Stack: [ 95.488740] deb62a24 deb5c8ab da148620 da0001e8 0090 dbc47e28 dec5934b da000148 [ 95.489099] da0001d8 dbc47e44 dec550eb dbc47e44 def998cb da204820 da00 da00 [ 95.489469] dbc47e64 def6dc51 deb5c280 da000148 da204830 da204820 dd5270c0 dd5271d8 [ 95.489839] Call Trace: [ 95.489907] [] ttm_bo_man_takedown+0x2b/0x50 [ttm] [ 95.489968] [] ttm_bo_clean_mm+0x5b/0xa0 [ttm] [ 95.490063] [] ? nv10_fb_takedown+0x2b/0x50 [nouveau] [ 95.490130] [] nouveau_unload+0xa1/0x150 [nouveau] [ 95.490198] [] drm_put_dev+0xb3/0x1c0 [drm] [ 95.490263] [] nouveau_pci_remove+0x10/0x20 [nouveau] [ 95.490325] [] pci_device_remove+0x3f/0xf0 [ 95.490384] [] __device_release_driver+0x4b/0xa0 [ 95.490424] [] driver_detach+0x77/0x80 [ 95.490424] [] bus_remove_driver+0x5b/0xa0 [ 95.490424] [] driver_unregister+0x46/0x80 [ 95.490424] [] ? sysfs_remove_file+0xf/0x20 [ 95.490424] [] pci_unregister_driver+0x2a/0x70 [ 95.490424] [] drm_pci_exit+0x7f/0x90 [drm] [ 95.490424] [] nouveau_exit+0x1b/0x22 [nouveau] [ 95.490424] [] sys_delete_module+0x19b/0x1f0 [ 95.490424] [] ? do_munmap+0x212/0x2f0 [ 95.490424] [] sysenter_do_call+0x12/0x26 [ 95.490424] Code: 75 d5 85 c9 75 0d 83 c4 08 5b 5e 5f c9 c3 8b 4e 30 eb ef 0f 0b eb fe c7 44 24 04 ab c8 b5 de c7 04 24 24 2a b6 de e8 75 bc 81 e2 <0f> 0b eb fe 55 89 e5 56 53 8b 58 1c ff 4b 48 0f b6 50 10 f6 c2 [ 95.490424] EIP: [] drm_mm_takedown+0x7c/0x80 [drm] SS:ESP 0068:dbc47e04 [ 95.494410] ---[ end trace ea6b63472f535569 ]---
s2ram slow (radeon) / failing (usb)
Hi, On a IEI Kino 690S1 I'm having a hard time to get s2ram running. It freezes during device suspend (unless I rmmod everything USB related) - usb fails even in pm_test case 'devices'. When the system is able to suspend it takes an eternity (more than 3 minutes to wake-up, the radeon apparently being responsible for quite a big share of that slowness. During resume early it looks like every PCI access needs about a second, and there are a few cases where during lots of seconds nothing seems to happen and the first event following is related to radeon. The kernel used is todays Linus's tree at commit be1066bbcd443a65df312fdecea7e4959adedb45 with Dave's drm-linus and drm-radeon-testing applied on top. Note, I've not been able to suspend to RAM properly recently (last one that worked correctly but resumed without graphics was some-when during 2.6.2x, before KMS) Since then the system would either fail suspend or resume. Manual changes I applied in order to find out some context information: - add a few debugging printk's to ata/ahci as that was the last entry on serial console for freezing suspends (that one succeeded but following step never completed, from suspend_prepare that would have been USB => unload usb before suspend) - strip "if EMBEDED" from CONFIG_SERIAL_8250_PNP and disabled it so serial console would continue working as long as possible and output suspend progress (resume output happens only very late) Is there some additional information I could gather in order do help improving s2ram on this system? - get it to suspend with usb loaded (ohci + ehci) - get it to resume a reasonable speed Thanks, Bruno List of modules when suspend&resume works (slowly): Module Size Used by snd_atiixp 14095 0 snd_ac97_codec118013 1 snd_atiixp ac97_bus1274 1 snd_ac97_codec snd_pcm71003 2 snd_atiixp,snd_ac97_codec snd_timer 19369 1 snd_pcm snd51992 4 snd_atiixp,snd_ac97_codec,snd_pcm,snd_timer soundcore974 1 snd snd_page_alloc 7797 2 snd_atiixp,snd_pcm sg 18667 0 pata_atiixp 4189 0 tg3 125844 0 lspci: 00:00.0 Host bridge [0600]: ATI Technologies Inc RS690 Host Bridge [1002:7910] 00:01.0 PCI bridge [0604]: ATI Technologies Inc RS690 PCI to PCI Bridge (Internal gfx) [1002:7912] 00:04.0 PCI bridge [0604]: ATI Technologies Inc Device [1002:7914] 00:05.0 PCI bridge [0604]: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Port 1) [1002:7915] 00:06.0 PCI bridge [0604]: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Port 2) [1002:7916] 00:12.0 SATA controller [0106]: ATI Technologies Inc SB600 Non-Raid-5 SATA [1002:4380] 00:13.0 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI0) [1002:4387] 00:13.1 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI1) [1002:4388] 00:13.2 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI2) [1002:4389] 00:13.3 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI3) [1002:438a] 00:13.4 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI4) [1002:438b] 00:13.5 USB Controller [0c03]: ATI Technologies Inc SB600 USB Controller (EHCI) [1002:4386] 00:14.0 SMBus [0c05]: ATI Technologies Inc SBx00 SMBus Controller [1002:4385] (rev 13) 00:14.1 IDE interface [0101]: ATI Technologies Inc SB600 IDE [1002:438c] 00:14.3 ISA bridge [0601]: ATI Technologies Inc SB600 PCI to LPC Bridge [1002:438d] 00:14.4 PCI bridge [0604]: ATI Technologies Inc SBx00 PCI to PCI Bridge [1002:4384] 00:14.5 Multimedia audio controller [0401]: ATI Technologies Inc SB600 AC97 Audio [1002:4382] 00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100] 00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101] 00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102] 00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103] 01:05.0 VGA compatible controller [0300]: ATI Technologies Inc RS690 [Radeon X1200 Series] [1002:791e] 02:00.0 Ethernet controller [0200]: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express [14e4:1693] (rev 02) 03:00.0 Ethernet controller [0200]: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express [14e4:1693] (rev 02) PM related config options: CONFIG_PM=y CONFIG_PM_DEBUG=y CONFIG_CAN_PM_TRACE=y CONFIG_PM_SLEEP_SMP=y CONFIG_PM_SLEEP=y CONFIG_PM_RUNTIME=y CONFIG_X86_PM_TIMER=y USB related config options: CONFIG_V4L_USB_DRIVERS=y CONFIG_USB_VIDEO_CLASS=m CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y CONFIG_USB_PWC=m CONFIG_USB_PWC_INPUT_EVDEV=y CONFIG_SND_USB=y CONFIG_USB_HID=y CONFIG_USB_SUPPORT=y CONFIG_USB_ARCH_HAS_HCD=y CONF
s2ram slow (radeon) / failing (usb)
On Sun, 02 May 2010 Alan Stern wrote: > On Sun, 2 May 2010, Bruno [UTF-8] Pr?mont wrote: > > On a IEI Kino 690S1 I'm having a hard time to get s2ram running. > > It freezes during device suspend (unless I rmmod everything USB > > related) - usb fails even in pm_test case 'devices'. > > > > When the system is able to suspend it takes an eternity (more than 3 > > minutes to wake-up, the radeon apparently being responsible for quite > > a big share of that slowness. > > > > > > During resume early it looks like every PCI access needs about a second, > > and there are a few cases where during lots of seconds nothing seems to > > happen and the first event following is related to radeon. > > > > The kernel used is todays Linus's tree at commit > > be1066bbcd443a65df312fdecea7e4959adedb45 > > with Dave's drm-linus and drm-radeon-testing applied on top. > > > > Note, I've not been able to suspend to RAM properly recently (last one > > that worked correctly but resumed without graphics was some-when during > > 2.6.2x, before KMS) > > Since then the system would either fail suspend or resume. > > > > Manual changes I applied in order to find out some context information: > > - add a few debugging printk's to ata/ahci as that was the last entry > > on serial console for freezing suspends (that one succeeded but > > following step never completed, from suspend_prepare that would have > > been USB => unload usb before suspend) > > - strip "if EMBEDED" from CONFIG_SERIAL_8250_PNP and disabled it so serial > > console would continue working as long as possible and output suspend > > progress (resume output happens only very late) > > > > Is there some additional information I could gather in order do help > > improving s2ram on this system? > > - get it to suspend with usb loaded (ohci + ehci) > > - get it to resume a reasonable speed > > There's no way to fix the USB problem without knowing what goes wrong. > Let's see how far you get before the system freezes on a kernel with > CONFIG_USB_DEBUG enabled. Am I missing something? I've enabled CONFIG_USB_DEBUG but don't see any additional module parameter nor anything extra to toggle and I don't get more output than without it. Device suspend (pm_test = device) works well when there is no USB device connected, but with USB keyboard I get the freeze (though the keyboard is still usable, e.g. CAPS key works and I can issue SYSRQ commands). When I issue sysreq-t, I find the following suspicious entry: [ 669.112505] usbhid_resume D 88007a085fd8 0 1145 2 0x [ 669.112505] 88007a085e20 0046 88007a085fd8 88007c536820 [ 669.112505] 88007a085fd8 88007a085fd8 000129c0 000129c0 [ 669.112505] 88007c536820 88007cf3f040 88007a085fd8 88007a085fd8 [ 669.112505] Call Trace: [ 669.112505] [] refrigerator+0x95/0xf0 [ 669.112505] [] worker_thread+0xc6/0x1e0 [ 669.112505] [] ? autoremove_wake_function+0x0/0x40 [ 669.112505] [] ? worker_thread+0x0/0x1e0 [ 669.112505] [] kthread+0x8e/0xa0 [ 669.112505] [] kernel_thread_helper+0x4/0x10 [ 669.112505] [] ? kthread+0x0/0xa0 [ 669.112505] [] ? kernel_thread_helper+0x0/0x10 Except for that one there are a few async/* tasks waiting. Thanks, Bruno
s2ram slow (radeon) / failing (usb)
On Sun, 02 May 2010 "Rafael J. Wysocki" wrote: > On Sunday 02 May 2010, Bruno Pr?mont wrote: > > On Sun, 02 May 2010 Alan Stern wrote: > > > On Sun, 2 May 2010, Bruno [UTF-8] Pr?mont wrote: > > > > On a IEI Kino 690S1 I'm having a hard time to get s2ram running. > > > > It freezes during device suspend (unless I rmmod everything USB > > > > related) - usb fails even in pm_test case 'devices'. > > > > > > > > When the system is able to suspend it takes an eternity (more than 3 > > > > minutes to wake-up, the radeon apparently being responsible for quite > > > > a big share of that slowness. > > > > > > > > > > > > During resume early it looks like every PCI access needs about a second, > > > > and there are a few cases where during lots of seconds nothing seems to > > > > happen and the first event following is related to radeon. > > > > > > > > The kernel used is todays Linus's tree at commit > > > > be1066bbcd443a65df312fdecea7e4959adedb45 > > > > with Dave's drm-linus and drm-radeon-testing applied on top. > > > > > > > > Note, I've not been able to suspend to RAM properly recently (last one > > > > that worked correctly but resumed without graphics was some-when during > > > > 2.6.2x, before KMS) > > > > Since then the system would either fail suspend or resume. > > > > > > > > Manual changes I applied in order to find out some context information: > > > > - add a few debugging printk's to ata/ahci as that was the last entry > > > > on serial console for freezing suspends (that one succeeded but > > > > following step never completed, from suspend_prepare that would have > > > > been USB => unload usb before suspend) > > > > - strip "if EMBEDED" from CONFIG_SERIAL_8250_PNP and disabled it so > > > > serial > > > > console would continue working as long as possible and output suspend > > > > progress (resume output happens only very late) > > > > > > > > Is there some additional information I could gather in order do help > > > > improving s2ram on this system? > > > > - get it to suspend with usb loaded (ohci + ehci) > > > > - get it to resume a reasonable speed > > > > > > There's no way to fix the USB problem without knowing what goes wrong. > > > Let's see how far you get before the system freezes on a kernel with > > > CONFIG_USB_DEBUG enabled. > > > > Am I missing something? > > > > I've enabled CONFIG_USB_DEBUG but don't see any additional module parameter > > nor anything extra to toggle and I don't get more output than without it. > > > > Device suspend (pm_test = device) works well when there is no USB device > > connected, but with USB keyboard I get the freeze (though the keyboard > > is still usable, e.g. CAPS key works and I can issue SYSRQ commands). > > > > When I issue sysreq-t, I find the following suspicious entry: > > [ 669.112505] usbhid_resume D 88007a085fd8 0 1145 2 > > 0x > > [ 669.112505] 88007a085e20 0046 88007a085fd8 > > 88007c536820 > > [ 669.112505] 88007a085fd8 88007a085fd8 000129c0 > > 000129c0 > > [ 669.112505] 88007c536820 88007cf3f040 88007a085fd8 > > 88007a085fd8 > > [ 669.112505] Call Trace: > > [ 669.112505] [] refrigerator+0x95/0xf0 > > [ 669.112505] [] worker_thread+0xc6/0x1e0 > > [ 669.112505] [] ? autoremove_wake_function+0x0/0x40 > > [ 669.112505] [] ? worker_thread+0x0/0x1e0 > > [ 669.112505] [] kthread+0x8e/0xa0 > > [ 669.112505] [] kernel_thread_helper+0x4/0x10 > > [ 669.112505] [] ? kthread+0x0/0xa0 > > [ 669.112505] [] ? kernel_thread_helper+0x0/0x10 > > > > Except for that one there are a few async/* tasks waiting. > > It looks like the freezer fails on your system. > > How much time did you wait for the failig "pm_test = device" to recover? I've given it at least 5 minutes, but didn't check exactly. Is there a (big) timeout that could happen, if so how long is it? Thanks, Bruno Those async threads looked like: [ 669.112505] async/15 D 0 2213 2 0x [ 669.112505] 8800797dbc80 0046 8800797dbfd8 88007aff8820 [ 669.112505] 8800797dbfd8 8800797dbfd8 000129c0 000129c0 [ 669.112505] 88007aff8820 88007cdf3040 0002 0113 [ 669.112505] Call Trace: [ 669.112505] [] schedule_timeout+0x19d/0x230 [ 669.112505] [] ? acpi_pci_irq_lookup+0x42/0x1b1 [ 669.112505] [] ? acpi_pci_irq_disable+0x74/0x7d [ 669.112505] [] wait_for_common+0xe1/0x170 [ 669.112505] [] ? default_wake_function+0x0/0x10 [ 669.112505] [] ? dpm_wait_fn+0x0/0x40 [ 669.112505] [] wait_for_completion+0x18/0x20 [ 669.112505] [] dpm_wait_fn+0x2f/0x40 [ 669.112505] [] device_for_each_child+0x48/0x70 [ 669.112505] [] __device_suspend+0x38/0x1e0 [ 669.112505] [] async_suspend+0x24/0x60 [ 669.112505] [] async_thread+0x112/0x280 [ 669.112505] [] ? default_wake_function+0x0/0x10 [ 669.112505] [] ? async_thread+0x0/0
s2ram slow (radeon) / failing (usb)
On Sun, 2 May 2010 17:59:17 -0400 (EDT) Alan Stern wrote: > On Sun, 2 May 2010, Bruno [UTF-8] Pr?mont wrote: > > > > There's no way to fix the USB problem without knowing what goes > > > wrong. Let's see how far you get before the system freezes on a > > > kernel with CONFIG_USB_DEBUG enabled. > > > > Am I missing something? > > > > I've enabled CONFIG_USB_DEBUG but don't see any additional module > > parameter nor anything extra to toggle and I don't get more output > > than without it. > > Depends what you mean by "output". The kernel generates more log > messages, but they may not get sent to your console. You need to > make sure the console's log level is set high enough to see debugging > messages. For example: > > echo 9 >/proc/sys/kernel/printk > > or type Alt-SysRq-9. I've been doing `dmesg -n 8` (9 is rejected as invalid) so it should send out everything. It looked like there was some more output during boot-up, but nothing during suspend, at least up to the freezing point. Bruno
s2ram slow resume - radeon versus no_console_suspend?
On Sun, 02 May 2010 Bruno Pr?mont wrote: > On a IEI Kino 690S1 I'm having a hard time to get s2ram running. > > When the system is able to suspend it takes an eternity (more than 3 > minutes to wake-up, the radeon apparently being responsible for quite > a big share of that slowness. > > > During resume early it looks like every PCI access needs about a second, > and there are a few cases where during lots of seconds nothing seems to > happen and the first event following is related to radeon. This slowness only happens when I run the kernel with no_console_suspend parameter (e.g. to debug some suspend/resume issue). This probably means that in this case radeon's PCI config recorded during suspend and restored during early resume is all but appropriate... Currently drm/radeon does not suspend when no_console_suspend is provided, even so when the kernel logging does not happen on tty0 & co. e.g. I would expect that a kernel run with no_console_suspend console=ttyS0 would just skip suspending serial port ttyS0 and not also skip suspending KMS framebuffer as it currently does. In most framebuffer devices I see usage of acquire_console_sem() and release_console_sem() but except for kernel/printk.c and drivers/serial/ code nothing is considering console_suspend_enabled. Currently I'm not sure what code path prevents suspend of KMS (at least for radeon) when no_console_suspend has been passed, this code path should probably have a conditional just as serial to take no_console_suspend only if it's running kernel's console itself. Thanks, Bruno
intelfb refuses to load
Hi, Looks like you are using the wrong intel driver. For intel modesetting you need CONFIG_DRM=y CONFIG_DRM_KMS_HELPER=y # CONFIG_DRM_TDFX is not set # CONFIG_DRM_R128 is not set # CONFIG_DRM_RADEON is not set # CONFIG_DRM_I810 is not set # CONFIG_DRM_I830 is not set CONFIG_DRM_I915=y # CONFIG_DRM_I915_KMS is not set # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set # CONFIG_DRM_VIA is not set # CONFIG_DRM_SAVAGE is not set # CONFIG_FB_I810 is not set That will give you inteldrmfb. ^^^ Not sure what dependency is missing in your config that DRM_I915 does not show up... (it might be CONFIG_AGP_INTEL) intelfb (CONFIG_FB_I810) is obsolete and only supports a pretty limited part of intel GPU features, modesetting only for VGA output (and not sure it works at all with recent GPUs). Bruno On Sat, 11 December 2010 Pavel Machek wrote: > Hi! > > I'm trying to fix up my kernel setup so that X is happy... currently > it fails to start with: > > FATAL: Could not load /lib/modules/2.6.37-rc5+/modules.dep: No such > file or directory > (EE) intel(0): No kernel modesetting driver detected. > (EE) Screen(s) found, but none have a usable configuration. > > So far I have: > > CONFIG_DRM=y > # CONFIG_DRM_TDFX is not set > # CONFIG_DRM_R128 is not set > # CONFIG_DRM_RADEON is not set > # CONFIG_DRM_I810 is not set > # CONFIG_DRM_MGA is not set > # CONFIG_DRM_SIS is not set > # CONFIG_DRM_VIA is not set > # CONFIG_DRM_SAVAGE is not set > # CONFIG_STUB_POULSBO is not set > CONFIG_VGASTATE=y > CONFIG_VIDEO_OUTPUT_CONTROL=y > CONFIG_FB=y > CONFIG_FB_I810=y > # CONFIG_FB_I810_GTF is not set > # CONFIG_FB_LE80578 is not set > CONFIG_FB_INTEL=y > CONFIG_FB_INTEL_DEBUG=y > CONFIG_FB_INTEL_I2C=y > # CONFIG_FB_MATROX is not set > > And on the command line: > > BOOT_IMAGE=(hd0,2)/l/linux-good/arch/i386/boot/bzImage root=/dev/sda4 > resume=/dev/sda1 psmouse.psmouse_proto=imps psmouse_proto=imps > psmouse.proto=imps vga=791 init=/tmp/swsusp-init > acpi_sleep=s3_bios,s3_mode no_console_suspend i915.modeset=1 > video=intelfb:mode=1024x768 fbcon=scrollback:64k > > ...but intelfb fails with: > > [drm] Initialized drm 1.1.0 20060810 > intelfb: intelfb_init > intelfb: Framebuffer driver for Intel(R) > 830M/845G/852GM/855GM/865G/915G/915GM/945G/945GM/945GME/965G/965GM > chipsets > intelfb: Version 0.9.6 > intelfb: intelfb_setup > intelfb: options: mode=1024x768 > intelfb: intelfb_pci_register > intelfb :00:02.0: power state changed by ACPI to D0 > intelfb :00:02.0: power state changed by ACPI to D0 > intelfb :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 > intelfb: fb aperture: 0xd000/0x1000, MMIO region: > 0xee10/0x8 > intelfb: Cannot reserve FB region. > intelfb: cleanup > > Any hints? If I'm doing some trivial mistake, perhaps "cannot reserve > FB region" message could be improved? > Pavel
[RFC] drm: add kernel-log renderer
Hi David, On Thu, 06 March 2014 David Herrmann wrote: > On modern linux user-space, the VT subsystem is no longer needed for > system consoles. Although most DEs will fail if VTs are disabled, there > are several gfx-systems that support this mode. Especially the lower > system stack has been extended to work without VTs. > > However, there is one major drawback if VTs are disabled: You don't get > oops/panic-screens nor early boot-debugging. The VT subsystem registers a > console-driver, thus displays the kernel log and oops/panic screens in > those situations. This patch introduces a fallback for CONFIG_VT=n. > > A new DRM-Log core is added. At its heart, DRM-Log maintains a log-buffer > of kernel-log messages. It registers a console-driver and pushes new > messages into this buffer whenever they appear. The size of the log-buffer > can be changed via drm_log_ensure_size(). Initially, a suitable buffer is > chosen, but whenever drivers register high-res CRTCs, they ought to > increase that buffer to guarantee there's always enough data to render the > whole screen. > This log-buffer is managed at the character-level, not pixel-level. It is > shared across all users, supports parallel, atomic readers and writers and > supports seamless resizing. Does it make sense to express drm_log_ensure_size() with pixel arguments and have the buffer below operated in characters? Shouldn't the pixel->char calculation be done at a higher level? (see also below regarding high-DPI) > Additionally to the log-buffer handling, a generic software renderer is > introduced. drm_log_draw() renders the current log-buffer into any > memory-mapped framebuffer you want. Note that it supports splitting lines > in case your framebuffer is smaller than the log-buffer, but also merging > continuation lines in case your framebuffer is wider. This allows > rendering an 80x25 log-buffer in full-width on high-res displays. On the > other hand, 800x250 log-buffers can be rendered without information loss > (apart from a shorter backlog) on low-res displays. Would it be possible to pass the dlog_font to drm_log_draw() so that DRM driver or high-level code could choose a larger font on high-DPI monitors (think retina-like)? Without that option kernel would need to be built specifically for a given DPI range and not be able to provide readable debug output on multiple CRTCs with (very) different DPIs. Bruno > No high-level API is introduced, yet. So for now drivers need to decide > when and where to render on their own. A generic interface with > panic-handlers, scheduled redrawing and automatic modesetting will be > added in follow-ups. > > A few more notes: > - This is for *debugging*, and for debugging only! You can use this >renderer to get a kernel-log onto your framebuffers. However, the >renderer is horribly slow! There is no intention to speed it up. No-one >cares whether it takes 500ms to render your panic-screen! > - If you enable the log-renderer for a continous boot-log, you're >supposed to redraw on vblanks. The renderer does not support >damage-tracking as each new-line causes a scroll-up, anyway. > - The renderer works bottom-up and right-to-left. This is required to >avoid pre-calculating log sizes. > - The renderer supports multiple columns. This is quite handy on high-res >screens where you can get bigger backlogs this way. Usually 80% of the >screen are black. Now you can reuse this for the next log-column. > - I have some wrappers to use this in user-space. I did several tests >with resizing and different buffer-sizes and valgrind didn't complain. >Results looked all fine. > - The renderer supports *any* RGB target, from 8bit to 32bit with >big-endian and little-endian support. The related pixel-renderer will >probably never win a beauty-contest, but it works.. Again, who cares >for debug-log rendering speed? > - If you want a normal boot-log, use a user-space log-renderer (like >experimential systemd-er (no merged, yet)). They can render with proper >speed, can do hw-scrolling and more. >Or: Enable VTs! Seriously, if you want all the VT features, use VTs! I >will not tell you to disable them. > > On a last note: > With this (and the high-level integration) in place, you can easily > disable CONFIG_FB, CONFIG_VT and CONFIG_FRAMEBUFFER_CONSOLE. Combined > with a proper user-space system-console, you will end up with more > features, less bugs and definitely some happy kernel maintainers.
[RFC] drm: add kernel-log renderer
Hi David, On Fri, 7 Mar 2014 00:41:05 +0100 David Herrmann wrote: > On Thu, Mar 6, 2014 at 10:56 PM, Bruno Pr?mont wrote: > > On Thu, 06 March 2014 David Herrmann wrote: > >> On modern linux user-space, the VT subsystem is no longer needed for > >> system consoles. Although most DEs will fail if VTs are disabled, there > >> are several gfx-systems that support this mode. Especially the lower > >> system stack has been extended to work without VTs. > >> > >> However, there is one major drawback if VTs are disabled: You don't get > >> oops/panic-screens nor early boot-debugging. The VT subsystem registers a > >> console-driver, thus displays the kernel log and oops/panic screens in > >> those situations. This patch introduces a fallback for CONFIG_VT=n. > >> > >> A new DRM-Log core is added. At its heart, DRM-Log maintains a log-buffer > >> of kernel-log messages. It registers a console-driver and pushes new > >> messages into this buffer whenever they appear. The size of the log-buffer > >> can be changed via drm_log_ensure_size(). Initially, a suitable buffer is > >> chosen, but whenever drivers register high-res CRTCs, they ought to > >> increase that buffer to guarantee there's always enough data to render the > >> whole screen. > >> This log-buffer is managed at the character-level, not pixel-level. It is > >> shared across all users, supports parallel, atomic readers and writers and > >> supports seamless resizing. > > > > Does it make sense to express drm_log_ensure_size() with pixel arguments > > and have the buffer below operated in characters? Shouldn't the pixel->char > > calculation be done at a higher level? (see also below regarding high-DPI) > > I don't want to expose "character" sizes. Any external API should be > dealing with pixels and only pixels. There is no reason to let them > deal with glyphs and text.. Regarding DPI, see below. > > >> Additionally to the log-buffer handling, a generic software renderer is > >> introduced. drm_log_draw() renders the current log-buffer into any > >> memory-mapped framebuffer you want. Note that it supports splitting lines > >> in case your framebuffer is smaller than the log-buffer, but also merging > >> continuation lines in case your framebuffer is wider. This allows > >> rendering an 80x25 log-buffer in full-width on high-res displays. On the > >> other hand, 800x250 log-buffers can be rendered without information loss > >> (apart from a shorter backlog) on low-res displays. > > > > Would it be possible to pass the dlog_font to drm_log_draw() so that > > DRM driver or high-level code could choose a larger font on high-DPI > > monitors (think retina-like)? > > > > Without that option kernel would need to be built specifically for a > > given DPI range and not be able to provide readable debug output on > > multiple CRTCs with (very) different DPIs. > > First of all, I won't support any fancy high-DPI features, that's just > wrong for debugging stuff. What I can do (and what we do in fallback > consoles in user-space) is to add an "dpi" or "scale" argument to > drm_log_draw() which does _integer_ scaling of glyphs. This allows you > to render glyphs 2x or 3x .. as big as usual. Integer scaling would do as well. Just some way to avoid tiny glyphs on high-DPI monitors (so that it can be applied per-CRTC) is needed. > I don't think it makes sense to modify drm_log_ensure_size(). I mean, > the worst that can happen is that the *text*-backlog is twice as big > as required. But if you have a high-dpi display, you already require > like 10x as much space for each framebuffer than for the entire > log-buffer. The log-buffer requires 1 byte per *char*. The frambuffer > requires at least 8*16*4=512 bytes per char. That's fair, especially as drm_log_ensure_size() is grow-only. > Anyhow, integer-scaling should be fairly easy to get done. I thought providing the font to drm_log_draw() and express drm_log_ensure_size() in chars - or pass font to it as well - would be easier than scaling. Bruno > Thanks > David
[RFC patch v3] x86: Improve boot_vga/vga_default_device() for EFI
With commit b4aa0163056b6c70029b6e8619ce07c274351f42 Matthew Garret
introduced a efifb vga_default_device() so that EFI systems that do not
load shadow VBIOS or setup VGA get proper value for boot_vga PCI sysfs
attribute on the corresponding PCI device.
Xorg is refusing to detect devices when boot_vga=0 which is the case on
some EFI system (e.g. MacBookAir2,1). Xorg detects the GPU and finds
the dri device but then bails out with "no devices detected".
With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete
while having native drivers for the GPU also makes selecting
sysfb/efifb optional.
Remove the efifb implementation of vga_default_device() and initialize
vgaarb's vga_default_device() with the PCI GPU that matches boot
screen_info in pci_fixup_video() [x86 and ia64 pci_fixup_video merged
into common function in vgaarb.c].
Other architectures with PCI GPU might need a similar fixup.
Note: If CONFIG_VGA_ARB is unset vga_default_device() is only available
as a stub that returns NULL, making this adjustment insufficient.
In addition, with the merge of x86/ia64 fixup code, this would
also result in disabled fixup.
Unsetting CONFIG_VGA_ARB requires CONFIG_EXPERT=y though.
Signed-off-by: Bruno Pr?mont
---
arch/ia64/pci/fixup.c | 56 -
arch/x86/include/asm/vga.h | 6 -
arch/x86/pci/fixup.c | 53 +-
drivers/gpu/vga/vgaarb.c | 57 ++
drivers/video/efifb.c | 38 ---
include/linux/vgaarb.h | 37 ++
6 files changed, 99 insertions(+), 148 deletions(-)
diff --git a/arch/ia64/pci/fixup.c b/arch/ia64/pci/fixup.c
index 5dc969d..b036423 100644
--- a/arch/ia64/pci/fixup.c
+++ b/arch/ia64/pci/fixup.c
@@ -5,65 +5,17 @@
#include
#include
+#include
#include
-/*
- * Fixup to mark boot BIOS video selected by BIOS before it changes
- *
- * From information provided by "Jon Smirl"
- *
- * The standard boot ROM sequence for an x86 machine uses the BIOS
- * to select an initial video card for boot display. This boot video
- * card will have it's BIOS copied to C in system RAM.
- * IORESOURCE_ROM_SHADOW is used to associate the boot video
- * card with this copy. On laptops this copy has to be used since
- * the main ROM may be compressed or combined with another image.
- * See pci_map_rom() for use of this flag. IORESOURCE_ROM_SHADOW
- * is marked here since the boot video device will be the only enabled
- * video device at this point.
- */
-
-static void pci_fixup_video(struct pci_dev *pdev)
+static void pci_ia64_fixup_video(struct pci_dev *pdev)
{
- struct pci_dev *bridge;
- struct pci_bus *bus;
- u16 config;
-
if ((strcmp(ia64_platform_name, "dig") != 0)
&& (strcmp(ia64_platform_name, "hpzx1") != 0))
return;
/* Maybe, this machine supports legacy memory map. */
- if ((pdev->class >> 8) != PCI_CLASS_DISPLAY_VGA)
- return;
-
- /* Is VGA routed to us? */
- bus = pdev->bus;
- while (bus) {
- bridge = bus->self;
-
- /*
-* From information provided by
-* "David Miller"
-* The bridge control register is valid for PCI header
-* type BRIDGE, or CARDBUS. Host to PCI controllers use
-* PCI header type NORMAL.
-*/
- if (bridge
- &&((bridge->hdr_type == PCI_HEADER_TYPE_BRIDGE)
- ||(bridge->hdr_type == PCI_HEADER_TYPE_CARDBUS))) {
- pci_read_config_word(bridge, PCI_BRIDGE_CONTROL,
- &config);
- if (!(config & PCI_BRIDGE_CTL_VGA))
- return;
- }
- bus = bus->parent;
- }
- pci_read_config_word(pdev, PCI_COMMAND, &config);
- if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
- pdev->resource[PCI_ROM_RESOURCE].flags |= IORESOURCE_ROM_SHADOW;
- dev_printk(KERN_DEBUG, &pdev->dev, "Boot video device\n");
- }
+ pci_fixup_video(pdev);
}
-DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, pci_fixup_video);
+DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_DISPLAY_VGA,
8, pci_ia64_fixup_video);
diff --git a/arch/x86/include/asm/vga.h b/arch/x86/include/asm/vga.h
index 44282fb..c4b9dc2 100644
--- a/arch/x86/include/asm/vga.h
+++ b/arch/x86/include/asm/vga.h
@@ -17,10 +17,4 @@
#define vga_readb(x) (*(x))
#define vga_writeb(x, y) (*(y) = (x))
-#ifdef CONFIG_FB_EFI
-#define __ARCH_HAS_VGA_DEFAULT_DEVICE
-extern struct pci_dev *vga_default_device(void);
-extern void vga_set_default_device(struct pci_dev *pdev);
-#endif
-
#endif /* _ASM_X86_VGA_H */
diff --git a/arch/x86/pci/fixup.c b/arch/x
[Patch] x86, ia64, efifb: Move boot_vga fixup from pci to vgaarb
With commit b4aa0163056b6c70029b6e8619ce07c274351f42 Matthew Garret
introduced a efifb vga_default_device() so that EFI systems that do not
load shadow VBIOS or setup VGA get proper value for boot_vga PCI sysfs
attribute on the corresponding PCI device.
Xorg is refusing to autodetect devices when boot_vga=0 which is the case
on some EFI system (e.g. MacBookAir2,1). Xorg detects the GPU and finds
the dri device but then bails out with "no devices detected".
With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete
while having native drivers for the GPU also makes selecting
sysfb/efifb optional.
Remove the efifb implementation of vga_default_device() and initialize
vgaarb's vga_default_device() with the PCI GPU that matches boot
screen_info in pci_fixup_video() [x86 and ia64 pci_fixup_video merged
into common function in vgaarb.c].
Other architectures with PCI GPU might need a similar fixup.
Note: If CONFIG_VGA_ARB is unset vga_default_device() is only available
as a stub that returns NULL, making this adjustment insufficient.
In addition, with the merge of x86/ia64 fixup code, this would
also result in disabled fixup.
Unsetting CONFIG_VGA_ARB requires CONFIG_EXPERT=y though.
Signed-off-by: Bruno Pr?mont
---
This is ported to changes in pci/fixup.c that landed in 3.15-rcs.
Is this fine to go in, if so who will take it?
I got no feedback on my last respin (on top of 3.14 a couple of weeks ago,
which added moving the ia64 pci boot_vga fixup).
I've been running this revision for a week or so on 3.15-rc kernels here
(mostly EFI-enabled system, the mentioned MBA as wells as non-Apple systems
where the patch was not required).
arch/ia64/pci/fixup.c | 56 ++---
arch/x86/include/asm/vga.h | 6
arch/x86/pci/fixup.c| 55 +
drivers/gpu/vga/vgaarb.c| 75 +
drivers/video/fbdev/efifb.c | 38 ---
include/linux/vgaarb.h | 37 ++
6 files changed, 116 insertions(+), 151 deletions(-)
diff --git a/arch/ia64/pci/fixup.c b/arch/ia64/pci/fixup.c
index eee069a..5df22f9 100644
--- a/arch/ia64/pci/fixup.c
+++ b/arch/ia64/pci/fixup.c
@@ -9,64 +9,14 @@
#include
-/*
- * Fixup to mark boot BIOS video selected by BIOS before it changes
- *
- * From information provided by "Jon Smirl"
- *
- * The standard boot ROM sequence for an x86 machine uses the BIOS
- * to select an initial video card for boot display. This boot video
- * card will have it's BIOS copied to C in system RAM.
- * IORESOURCE_ROM_SHADOW is used to associate the boot video
- * card with this copy. On laptops this copy has to be used since
- * the main ROM may be compressed or combined with another image.
- * See pci_map_rom() for use of this flag. Before marking the device
- * with IORESOURCE_ROM_SHADOW check if a vga_default_device is already set
- * by either arch cde or vga-arbitration, if so only apply the fixup to this
- * already determined primary video card.
- */
-
-static void pci_fixup_video(struct pci_dev *pdev)
+static void pci_ia64_fixup_video(struct pci_dev *pdev)
{
- struct pci_dev *bridge;
- struct pci_bus *bus;
- u16 config;
-
if ((strcmp(ia64_platform_name, "dig") != 0)
&& (strcmp(ia64_platform_name, "hpzx1") != 0))
return;
/* Maybe, this machine supports legacy memory map. */
- /* Is VGA routed to us? */
- bus = pdev->bus;
- while (bus) {
- bridge = bus->self;
-
- /*
-* From information provided by
-* "David Miller"
-* The bridge control register is valid for PCI header
-* type BRIDGE, or CARDBUS. Host to PCI controllers use
-* PCI header type NORMAL.
-*/
- if (bridge
- &&((bridge->hdr_type == PCI_HEADER_TYPE_BRIDGE)
- ||(bridge->hdr_type == PCI_HEADER_TYPE_CARDBUS))) {
- pci_read_config_word(bridge, PCI_BRIDGE_CONTROL,
- &config);
- if (!(config & PCI_BRIDGE_CTL_VGA))
- return;
- }
- bus = bus->parent;
- }
- if (!vga_default_device() || pdev == vga_default_device()) {
- pci_read_config_word(pdev, PCI_COMMAND, &config);
- if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
- pdev->resource[PCI_ROM_RESOURCE].flags |=
IORESOURCE_ROM_SHADOW;
- dev_printk(KERN_DEBUG, &pdev->dev, "Boot video
device\n");
- vga_set_default_device(pdev);
- }
- }
+ pci_fixup_video(pdev);
}
DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_ANY_ID, PCI_ANY_ID,
- PCI_CLASS_DISPLAY_VGA, 8, pci_fixup_vid
[PATCH 1/2 v2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()
On Sun, 10 August 2014 Andreas Noever wrote:
> On Sun, Aug 10, 2014 at 2:21 AM, Andreas Noever
> wrote:
> > On Sat, Jul 5, 2014 at 7:15 PM, Bjorn Helgaas
> > wrote:
> >> On Wed, Jun 25, 2014 at 12:55:01AM +0200, Bruno Pr?mont wrote:
> >>> With commit b4aa0163056b ("efifb: Implement vga_default_device() (v2)")
> >>> Matthew Garrett introduced a efifb vga_default_device() so that EFI
> >>> systems that do not load shadow VBIOS or setup VGA get proper value for
> >>> boot_vga PCI sysfs attribute on the corresponding PCI device.
> >>>
> >>> Xorg is refusing to detect devices when boot_vga=0 which is the case on
> >>> some EFI system (e.g. MacBookAir2,1). Xorg detects the GPU and finds
> >>> the dri device but then bails out with "no devices detected".
> >>>
> >>> Note: When vga_default_device() is set boot_vga PCI sysfs attribute
> >>> reflects its state. When unset this attribute is 1 whenever
> >>> IORESOURCE_ROM_SHADOW flag is set.
> >>>
> >>> With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete
> >>> while having native drivers for the GPU also makes selecting
> >>> sysfb/efifb optional.
> >>>
> >>> Remove the efifb implementation of vga_default_device() and initialize
> >>> vgaarb's vga_default_device() with the PCI GPU that matches boot
> >>> screen_info in pci_fixup_video().
> >>>
> >>> Tested-by: Anibal Francisco Martinez Cortina
> >>> Cc: Matthew Garrett
> >>> Cc: stable at vger.kernel.org
> >>> Signed-off-by: Bruno Pr?mont
> >>
> >> I applied both with Matthew's ack to pci/misc for v3.17, thanks!
> >
> > I just tried to run the latest kernel. It failed to boot and git
> > bisect points to this commit (MacBookPro10,1 with Nvidia&Intel
> > graphics).
> >
> > The (now removed) code in efifb_setup did always set default_vga, even
> > if it had already been set earlier. The new code in pci_fixup_video
> > runs only if vga_default_device() is NULL. Removing the check fixes
> > the regression.
> >
> >
> > The following calls to vga_set_default_device are made during boot:
> >
> > vga_arbiter_add_pci_device -> vga_set_default_device(intel)
> > pci_fixup_video -> vga_set_default_device(intel) (there are two calls
> > in pci_fixup_video, this one is the one near "Boot video device")
> > pci_fixup_video -> vga_set_default_device(nvidia) (from the "Does
> > firmware framebuffer belong to us?" loop, only if I remove the check)
> >
> > vga_arbiter_add_pci_device chooses intel simply because it is the
> > first device. Next pci_fixup_video(intel) sees that it is the default
> > device, sets the IORESOURCE_ROM_SHADOW flag and calls
> > vga_set_default_device again. And finally (if the check is removed)
> > pci_fixup_video(nvidia) sees that it owns the framebuffer and sets
> > itself as the default device which allows the system to boot again.
> >
> > Does setting the ROM_SHADOW flag on (possibly) the wrong device have
> > any effect?
> Yes it does. Removing the line changes a long standing
> i915 :00:02.0: Invalid ROM contents
> into a
> i915 :00:02.0: BAR 6: can't assign [??? 0x flags
> 0x2000] (bogus alignment).
>
> The first is logged at KERN_ERR and the second one only at KERN_INFO.
> We are making progress.
How does your system behave if you change vga_arbiter_add_pci_device()
not to set vga_set_default_device() with the first device registered?
That is remove the
#ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
code block in vga_arbiter_add_pci_device().
How did your system behave in the past if you did not enable efifb?
Bruno
[PATCH 1/2 v2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()
On Sun, 10 August 2014 Andreas Noever wrote:
> On Sun, Aug 10, 2014 at 11:26 AM, Bruno Pr?mont wrote:
> > On Sun, 10 August 2014 Andreas Noever wrote:
> >
> >> On Sun, Aug 10, 2014 at 2:21 AM, Andreas Noeverwrote:
> >> > I just tried to run the latest kernel. It failed to boot and git
> >> > bisect points to this commit (MacBookPro10,1 with Nvidia&Intel
> >> > graphics).
> >> >
> >> > The (now removed) code in efifb_setup did always set default_vga, even
> >> > if it had already been set earlier. The new code in pci_fixup_video
> >> > runs only if vga_default_device() is NULL. Removing the check fixes
> >> > the regression.
> >> >
> >> >
> >> > The following calls to vga_set_default_device are made during boot:
> >> >
> >> > vga_arbiter_add_pci_device -> vga_set_default_device(intel)
> >> > pci_fixup_video -> vga_set_default_device(intel) (there are two calls
> >> > in pci_fixup_video, this one is the one near "Boot video device")
> >> > pci_fixup_video -> vga_set_default_device(nvidia) (from the "Does
> >> > firmware framebuffer belong to us?" loop, only if I remove the check)
> >> >
> >> > vga_arbiter_add_pci_device chooses intel simply because it is the
> >> > first device. Next pci_fixup_video(intel) sees that it is the default
> >> > device, sets the IORESOURCE_ROM_SHADOW flag and calls
> >> > vga_set_default_device again. And finally (if the check is removed)
> >> > pci_fixup_video(nvidia) sees that it owns the framebuffer and sets
> >> > itself as the default device which allows the system to boot again.
> >> >
> >> > Does setting the ROM_SHADOW flag on (possibly) the wrong device have
> >> > any effect?
> >> Yes it does. Removing the line changes a long standing
> >> i915 :00:02.0: Invalid ROM contents
> >> into a
> >> i915 :00:02.0: BAR 6: can't assign [??? 0x flags
> >> 0x2000] (bogus alignment).
> >>
> >> The first is logged at KERN_ERR and the second one only at KERN_INFO.
> >> We are making progress.
> >
> > How does your system behave if you change vga_arbiter_add_pci_device()
> > not to set vga_set_default_device() with the first device registered?
> >
> > That is remove the
> > #ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
> > code block in vga_arbiter_add_pci_device().
> The system does not boot. The Intel device is still set as the
> default device in pci_fixup_video (near "Boot video device") and
> prevents the nvidia device (which is initialized later) from becoming
> the default one.
>
> > How did your system behave in the past if you did not enable efifb?
> I don't think that I ever did not enable efifb. It seems to have been
> around for quite a while?
The question here is if you system just refuses to boot as well.
The aim of my patch is to make system work (properly) when efifb is not used
(why use efifb if built-in drm drivers handle the GPU(s)?)
If you decided to replace efifb with platform-framebuffer+simplefb/simpledrm
you would probably see the same issue as that would be no efifb as well.
The presence of efifb should not be mandatory for successfully booting
and running Xorg.
> Andreas
How does you system behave with below patch on top of Linus tree?
Bruno
---
diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index c61ea57..15d0068 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -367,7 +367,7 @@ static void pci_fixup_video(struct pci_dev *pdev)
}
bus = bus->parent;
}
- if (!vga_default_device() || pdev == vga_default_device()) {
+ if (pdev == vga_default_device()) {
pci_read_config_word(pdev, PCI_COMMAND, &config);
if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
pdev->resource[PCI_ROM_RESOURCE].flags |=
IORESOURCE_ROM_SHADOW;
diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index d2077f0..ac44d87 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -112,10 +112,8 @@ both:
return 1;
}
-#ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
/* this is only used a cookie - it should not be dereferenced */
static struct pci_dev *vga_default;
-#endif
static void vga_arb_device_card_gone(struct pci_dev *pdev);
@@ -131,7 +129,6 @@ static struct vga_device *vgadev_find(struct pci_dev *pdev)
}
/* Returns the default VGA device (vgacon's babe) */
-#ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
struct pci_dev *vga_default_device(void)
{
return vga_default;
@@ -147,7 +144,6 @@ void vga_set_default_device(struct pci_dev *pdev)
pci_dev_put(vga_default);
vga_default = pci_dev_get(pdev);
}
-#endif
static inline void vga_irq_set_state(struct vga_device *vgadev, bool state)
{
@@ -580,10 +576,10 @@ static bool vga_arbiter_add_pci_device(struct pci_dev
*pdev)
bus = bus->parent;
}
+#if 0
/* Deal with VGA default device. Use first enabled one
* by default if arch doesn't have it's own hook
*/
-#ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
[PATCH 0/2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()
This series improves on commit 20cde694027e (x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()): - cleanup remaining but always-true #ifndefs - fix boot regression on dual-GPU Macs Andreas, can you please test this series? It is a modification from previous testing patch that should still work fine for you. That testing patch would have been failing X startup on old BIOS systems booted with vga=normal (or otherwise in VGA text mode). Greg, in case you have scheduled above-mentioned commit for your next stable iteration, please hold it back in the queue until this follow-up has landed and can be included within the same stable update as alone that patch regresses for Macs with dual-GPU and using efifb. Bruno
[PATCH 1/2] vgaarb: Drop obsolete #ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
With commit 20cde694027e boot video device detection was moved from
efifb to x86 and ia64 pci/fixup.c.
Remove the left-over #ifndef check that will allways match since
the corresponding arch-specific define is gone with above patch.
Signed-off-by: Bruno Pr?mont
CC: Matthew Garrett
CC: stable at vger.kernel.org # v3.5+
---
May be applied to stable as cleanup for upstream commit
20cde694027e7477cc532833e38ab9fcaa83fb64 which is marked for
stable.
drivers/gpu/vga/vgaarb.c | 8
include/linux/vgaarb.h | 2 --
2 files changed, 10 deletions(-)
diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index d2077f0..257674d 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -112,10 +112,8 @@ both:
return 1;
}
-#ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
/* this is only used a cookie - it should not be dereferenced */
static struct pci_dev *vga_default;
-#endif
static void vga_arb_device_card_gone(struct pci_dev *pdev);
@@ -131,7 +129,6 @@ static struct vga_device *vgadev_find(struct pci_dev *pdev)
}
/* Returns the default VGA device (vgacon's babe) */
-#ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
struct pci_dev *vga_default_device(void)
{
return vga_default;
@@ -147,7 +144,6 @@ void vga_set_default_device(struct pci_dev *pdev)
pci_dev_put(vga_default);
vga_default = pci_dev_get(pdev);
}
-#endif
static inline void vga_irq_set_state(struct vga_device *vgadev, bool state)
{
@@ -583,11 +579,9 @@ static bool vga_arbiter_add_pci_device(struct pci_dev
*pdev)
/* Deal with VGA default device. Use first enabled one
* by default if arch doesn't have it's own hook
*/
-#ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
if (vga_default == NULL &&
((vgadev->owns & VGA_RSRC_LEGACY_MASK) == VGA_RSRC_LEGACY_MASK))
vga_set_default_device(pdev);
-#endif
vga_arbiter_check_bridge_sharing(vgadev);
@@ -621,10 +615,8 @@ static bool vga_arbiter_del_pci_device(struct pci_dev
*pdev)
goto bail;
}
-#ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
if (vga_default == pdev)
vga_set_default_device(NULL);
-#endif
if (vgadev->decodes & (VGA_RSRC_LEGACY_IO | VGA_RSRC_LEGACY_MEM))
vga_decode_count--;
diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h
index 2c02f3a..c37bd4d 100644
--- a/include/linux/vgaarb.h
+++ b/include/linux/vgaarb.h
@@ -182,7 +182,6 @@ extern void vga_put(struct pci_dev *pdev, unsigned int
rsrc);
* vga_get()...
*/
-#ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
#ifdef CONFIG_VGA_ARB
extern struct pci_dev *vga_default_device(void);
extern void vga_set_default_device(struct pci_dev *pdev);
@@ -190,7 +189,6 @@ extern void vga_set_default_device(struct pci_dev *pdev);
static inline struct pci_dev *vga_default_device(void) { return NULL; };
static inline void vga_set_default_device(struct pci_dev *pdev) { };
#endif
-#endif
/**
* vga_conflicts
--
1.8.5.5
[PATCH 2/2] x86, ia64: Don't default to first video device
With commit 20cde694027e boot video device detection was moved from
efifb to x86 and ia64 pci/fixup.c.
For dual-GPU Apple computers above above change represents a regression
as code in efifb did forcefully override vga_default_device while the
merge did not (changed ordering of actions).
This stops setting default_vga_device when applying
IORESOURCE_ROM_SHADOW (only doing so for the detected boot GPU) and
updates logging of boot video device selection, in vgaarb which covers
VGA text-mode booting and first half of pci_fixup_video which covers
framebuffer mode (EFI, VESA).
By setting IORESOURCE_ROM_SHADOW only on effective boot GPU we also
corrects a longstanding complaint from intel driver as reported by
Andreas:
> Does setting the ROM_SHADOW flag on (possibly) the wrong device
> have any effect?
Yes it does. Removing the line changes a long standing
i915 :00:02.0: Invalid ROM contents
into a
i915 :00:02.0: BAR 6: can't assign [??? 0x flags
0x2000] (bogus alignment).
The first is logged at KERN_ERR while the second is at KERN_INFO.
Reported-By: Andreas Noever
Signed-off-by: Bruno Pr?mont
CC: Matthew Garrett
CC: stable at vger.kernel.org # v3.5+
---
Must be applied to stable when upstream commit
20cde694027e7477cc532833e38ab9fcaa83fb64, which is marked for
stable, gets applied.
Can be applied without patch 1/2 from this series though dropped
#ifndefs will cause this patch not to apply cleanly.
arch/ia64/pci/fixup.c| 9 +
arch/x86/pci/fixup.c | 9 +
drivers/gpu/vga/vgaarb.c | 4 +++-
3 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/arch/ia64/pci/fixup.c b/arch/ia64/pci/fixup.c
index ec73b2c..05198f8 100644
--- a/arch/ia64/pci/fixup.c
+++ b/arch/ia64/pci/fixup.c
@@ -54,8 +54,10 @@ static void pci_fixup_video(struct pci_dev *pdev)
continue;
if (screen_info.lfb_base >= start &&
- (screen_info.lfb_base + screen_info.lfb_size) < end)
+ (screen_info.lfb_base + screen_info.lfb_size) <
end) {
+ dev_printk(KERN_DEBUG, &pdev->dev, "Boot video
device\n");
vga_set_default_device(pdev);
+ }
}
}
@@ -79,12 +81,11 @@ static void pci_fixup_video(struct pci_dev *pdev)
}
bus = bus->parent;
}
- if (!vga_default_device() || pdev == vga_default_device()) {
+ if (pdev == vga_default_device()) {
pci_read_config_word(pdev, PCI_COMMAND, &config);
if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
pdev->resource[PCI_ROM_RESOURCE].flags |=
IORESOURCE_ROM_SHADOW;
- dev_printk(KERN_DEBUG, &pdev->dev, "Boot video
device\n");
- vga_set_default_device(pdev);
+ dev_printk(KERN_DEBUG, &pdev->dev, "Video device with
shadowed ROM\n");
}
}
}
diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index c61ea57..5b392d2 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -342,8 +342,10 @@ static void pci_fixup_video(struct pci_dev *pdev)
continue;
if (screen_info.lfb_base >= start &&
- (screen_info.lfb_base + screen_info.lfb_size) < end)
+ (screen_info.lfb_base + screen_info.lfb_size) <
end) {
+ dev_printk(KERN_DEBUG, &pdev->dev, "Boot video
device\n");
vga_set_default_device(pdev);
+ }
}
}
@@ -367,12 +369,11 @@ static void pci_fixup_video(struct pci_dev *pdev)
}
bus = bus->parent;
}
- if (!vga_default_device() || pdev == vga_default_device()) {
+ if (pdev == vga_default_device()) {
pci_read_config_word(pdev, PCI_COMMAND, &config);
if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
pdev->resource[PCI_ROM_RESOURCE].flags |=
IORESOURCE_ROM_SHADOW;
- dev_printk(KERN_DEBUG, &pdev->dev, "Boot video
device\n");
- vga_set_default_device(pdev);
+ dev_printk(KERN_DEBUG, &pdev->dev, "Video device with
shadowed ROM\n");
}
}
}
diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index 257674d..c6eeed5 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -580,8 +580,10 @@ static bool vga_arbiter_add_pci_device(struct pci_dev
*pdev)
* by default if arch doesn't have it's own hook
*/
if (vga_default == NULL &&
- ((vgadev->owns & VGA_RSRC_LEGACY_MASK) == VGA_RSRC_LEGACY_MASK))
+ ((vgadev->owns & VGA_RSRC_LEGACY_MASK) == VGA_RSRC_LEGACY_MASK)) {
+
[PATCH 0/2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()
On Tue, 19 Aug 2014 17:45:00 +0200 Andreas Noever wrote: > On Sat, Aug 16, 2014 at 7:21 PM, Bruno Pr?mont wrote: > > This series improves on commit 20cde694027e (x86, ia64: Move EFI_FB > > vga_default_device() initialization to pci_vga_fixup()): > > - cleanup remaining but always-true #ifndefs > > - fix boot regression on dual-GPU Macs > > > > Andreas, can you please test this series? It is a modification from > > previous testing patch that should still work fine for you. > > That testing patch would have been failing X startup on old BIOS systems > > booted with vga=normal (or otherwise in VGA text mode). > > > > > > Greg, in case you have scheduled above-mentioned commit for your next > > stable iteration, please hold it back in the queue until this follow-up > > has landed and can be included within the same stable update as alone > > that patch regresses for Macs with dual-GPU and using efifb. > > > > Bruno > > Fails again (with and without efifb). > > The vga_set_default_device in vga_arbiter_add_pci_device is at fault. > It sets the boot video device to intel. Removing it makes the system > bootable again. Could you provide your whole kernel log? I would like to understand how your vga devices are setup and why it starts the wrong way. If you can grab kernel log from both working and failing setups it would be even better. The failing one is interesting for where exactly it starts failing at boot. Bruno
[PATCH 0/2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()
On Wed, 20 Aug 2014 07:55:08 +0200 Bruno Pr?mont wrote:
> On Tue, 19 Aug 2014 17:45:00 +0200 Andreas Noever wrote:
> > On Sat, Aug 16, 2014 at 7:21 PM, Bruno Pr?mont wrote:
> > > This series improves on commit 20cde694027e (x86, ia64: Move EFI_FB
> > > vga_default_device() initialization to pci_vga_fixup()):
> > > - cleanup remaining but always-true #ifndefs
> > > - fix boot regression on dual-GPU Macs
> > >
> > > Andreas, can you please test this series? It is a modification from
> > > previous testing patch that should still work fine for you.
> > > That testing patch would have been failing X startup on old BIOS systems
> > > booted with vga=normal (or otherwise in VGA text mode).
> > >
> > >
> > > Greg, in case you have scheduled above-mentioned commit for your next
> > > stable iteration, please hold it back in the queue until this follow-up
> > > has landed and can be included within the same stable update as alone
> > > that patch regresses for Macs with dual-GPU and using efifb.
> > >
> > > Bruno
> >
> > Fails again (with and without efifb).
> >
> > The vga_set_default_device in vga_arbiter_add_pci_device is at fault.
> > It sets the boot video device to intel. Removing it makes the system
> > bootable again.
>
> Could you provide your whole kernel log? I would like to understand
> how your vga devices are setup and why it starts the wrong way.
>
> If you can grab kernel log from both working and failing setups it
> would be even better. The failing one is interesting for where exactly it
> starts failing at boot.
While collecting debug logs, please apply following patch to get
PCI command and bridge control registers as configured when vgaarb looks
at them.
diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index af02597..8c8e7af 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -554,6 +554,7 @@ static bool vga_arbiter_add_pci_device(struct pci_dev *pdev)
* clear that below if the bridge isn't forwarding
*/
pci_read_config_word(pdev, PCI_COMMAND, &cmd);
+ pr_info("vgaarb: PCI:%s PCI_COMMAND=%04x\n", pci_name(pdev), (unsigned
int)cmd);
if (cmd & PCI_COMMAND_IO)
vgadev->owns |= VGA_RSRC_LEGACY_IO;
if (cmd & PCI_COMMAND_MEMORY)
@@ -567,6 +568,7 @@ static bool vga_arbiter_add_pci_device(struct pci_dev *pdev)
u16 l;
pci_read_config_word(bridge, PCI_BRIDGE_CONTROL,
&l);
+ pr_info("vgaarb: PCI:%s, bridge PCI:%s
PCI_BRIDGE_CONTROL=%04x\n", pci_name(pdev), pci_name(bridge), (unsigned int)l);
if (!(l & PCI_BRIDGE_CTL_VGA)) {
vgadev->owns = 0;
break;
[PATCH 0/2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()
On Thu, 21 August 2014 Andreas Noever wrote: > dmesg with your patches and vga_set_default_device commented out > (after "vgaarb: Boot video device...") as otherwise the system won't > boot. Do you know more precisely where your system hangs when it does not boot? That's the part I can't find in this thread. Is it dead-locking/freezing or just booting without displaying anything (though network coming up if connected, keyboard working (e.g. caps key). Try blacklisting both i915 and nouveau modules (and each one individually) an see how far your system gets. Also make sure your network comes up automatically, so that even if display remains black you can check via network if your system is alive and what it complains about. > dmesg | grep vgaarb > [1.340118] vgaarb: PCI::00:02.0 PCI_COMMAND=0007 > [1.340119] vgaarb: Boot video device: PCI::00:02.0 > [1.340120] vgaarb: device added: > PCI::00:02.0,decodes=io+mem,owns=io+mem,locks=none > [1.340130] vgaarb: PCI::01:00.0 PCI_COMMAND=0006 > [1.340132] vgaarb: PCI::01:00.0, bridge PCI::00:01.0 > PCI_BRIDGE_CONTROL= > [1.340133] vgaarb: device added: > PCI::01:00.0,decodes=io+mem,owns=none,locks=none > [1.340135] vgaarb: loaded > [1.340136] vgaarb: bridge control possible :01:00.0 > [1.340136] vgaarb: no bridge control possible :00:02.0 > [3.798430] vgaarb: device changed decodes: > PCI::00:02.0,olddecodes=io+mem,decodes=none:owns=io+mem > > > If the line is not commented out then vgaarb simply declares the first > (enabled) device to be the default one, which is incorrect. And the > overwrite logic in pci_fixup_video is not triggered, since a default > device has already been set. The initial selection I am doing does match the PCI_COMMAND flags as set for the devices (or masked by parent bridge), but probably none of them has active legacy VGA I/O ports. So the question would rather be how to determine which I/O port is active for the Intel graphics and adjust vgaarb's "decodes"/owns interpretation on that basis (there is no I/O active for the nvidia one). I'm thinking about selecting only device that decodes the legacy VGA I/O range and not those with any some other I/O range. The short-term fix probably is to just unconditionally perform the screen_info check in pci_fixup_video() while leaving vgaarb's initial card selection alone for legacy hardware. Thus replicating efifb's original behavior (and also get back incorrect ROM_SHADOW flagging). Corresponding patch below (on top of both patches in this series, but should apply without them as well). As mentioned in the patch this papers over the real issue. A second step would then be to tune vgaarb's initial selection. Bjorn, is it possible to verify which I/O ports are decoded by a PCI device at the time of adding it to vgaarb? If so, how? I would like to check for legacy VGA I/O range (0x03B0-0x03DF) and only let vgaarb set a device as default if that I/O range is decoded by the device. Bruno > On Wed, Aug 20, 2014 at 9:11 AM, Bruno Pr?mont wrote: > > On Wed, 20 Aug 2014 07:55:08 +0200 Bruno Pr?mont wrote: > >> On Tue, 19 Aug 2014 17:45:00 +0200 Andreas Noever wrote: > >> > On Sat, Aug 16, 2014 at 7:21 PM, Bruno Pr?mont wrote: > >> > > This series improves on commit 20cde694027e (x86, ia64: Move EFI_FB > >> > > vga_default_device() initialization to pci_vga_fixup()): > >> > > - cleanup remaining but always-true #ifndefs > >> > > - fix boot regression on dual-GPU Macs > >> > > > >> > > Andreas, can you please test this series? It is a modification from > >> > > previous testing patch that should still work fine for you. > >> > > That testing patch would have been failing X startup on old BIOS > >> > > systems > >> > > booted with vga=normal (or otherwise in VGA text mode). > >> > > > >> > > > >> > > Greg, in case you have scheduled above-mentioned commit for your next > >> > > stable iteration, please hold it back in the queue until this follow-up > >> > > has landed and can be included within the same stable update as alone > >> > > that patch regresses for Macs with dual-GPU and using efifb. > >> > > > >> > > Bruno > >> > > >> > Fails again (with and without efifb). > >> > > >> > The vga_set_default_device in vga_arbiter_add_pci_device is at fault. > >> > It sets the boot video device to intel. Removing it makes the system > >> > bootable again. > >> > >> Could you provide your whole kernel log? I would like to understand > >> how your vga devices are setup and why it starts the wrong way. > >> > >> If you can grab kernel log from both working and failing setups it > >> would be even better. The failing one is interesting for where exactly it > >> starts failing at boot. > > > > While collecting debug logs, please apply following patch to get > > PCI command and bridge control registers as configured when vgaarb looks > > at them. From: Bruno Pr?mont Subject: [PATCH] x86: Force selection of vga_default_device
[PATCH 0/2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()
On Thu, 21 Aug 2014 23:39:31 -0500 Bjorn Helgaas wrote: > On Thu, Aug 21, 2014 at 4:34 PM, Bruno Pr?mont wrote: > > > A second step would then be to tune vgaarb's initial selection. > > Bjorn, is it possible to verify which I/O ports are decoded by a PCI > > device at the time of adding it to vgaarb? If so, how? I would like to > > check for legacy VGA I/O range (0x03B0-0x03DF) and only let vgaarb set > > a device as default if that I/O range is decoded by the device. > > I don't know of a way. I'm pretty sure VGA devices are allowed to > respond to those legacy addresses even if there's no BAR for them, but > I haven't found a spec reference for this. There is the VGA Enable > bit in bridges, of course (PCI Bridge spec, sec 12.1.1. If the VGA > device is behind a bridge that doesn't have the VGA Enable bit set, it > probably isn't the default device. Those VGA devices behind bridges are the easy ones that vgaarb selects properly. It's the ones not behind a bridge (integrated graphics) like the intel one that cause problems. For Andreas's system the discrete nvidia GPU has no I/O enabled according to PCI_COMMAND flags while the integrated intel one does have them (that's why the Intel GPU is chosen). Unfortunately I don't know what makes his system choke at boot time as he did not provide logs for the failing case. If there is no better way to detect the proper legacy VGA device the only remaining option would be to perform the screen_info testing in vga_arb_device_init() enclosed in arch #ifdef... Bruno
[PATCH 0/2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()
On Fri, 22 August 2014 Andreas Noever wrote: > > For Andreas's system the discrete nvidia GPU has no I/O enabled > > according to PCI_COMMAND flags while the integrated intel one does have > > them (that's why the Intel GPU is chosen). > > > > Unfortunately I don't know what makes his system choke at boot time as > > he did not provide logs for the failing case. > Attached dmesg for the failing case (obtained via ssh). > > Without blacklisting a small horizontal bar of vertical green bars > appears (no x, no console). It's good to know that it's just the graphics (console / X) that are not displaying properly. > If nouveau is blacklisted then I get a console, but X will not start > (No devices found). The console you get is EFIFB (on the nvidia GPU to which display is routed). Here the reason why X does not start is probably that i915 did not find its VBIOS tables nor any connected monitor and thus X thinks "no active output => I don't start". Though your X would be able to start if it did not find xf86-video-intel (intel_drv.so) and/or did find/had an explicit reference to xf86-video-fbdev (fbdev_drv.so). If under OSX you told your system to start on intel GPU (I think there is an option in this direction) you system would probably boot fine as the initial choice by vgaarb would match gmux/switcheroo settings. > If i915 is blacklisted then I do not get a console. The screen just > freezes after a few boot messages. This is more interesting. Initially you had efifb printing kernel logs until nouveau gets loaded by udev and replaces efifb. From there on possibly applegmux does not take over correctly (it may need both i915 and nouveau active to properly route framebuffer to panel or connector). Though your X should be telling the same thing as for nouveau blacklisted as nvidia GPU is not the one having boot_vga set... If not it may be worth finding out in what state your system exactly is with regards to graphics. > What is vga_default_device() used for? Is it supposed to hold the > device that is controlling the (boot) screen? Why can't we just read > the configuration from vga_switcheroo/gmux? For systems not using vga_switcheroo: vga_default_device represents the PCI GPU that was used to boot (and normally handles legacy VGA I/O). It's never changed after boot (except eventually when a GPU gets hotplugged) For systems with vga_switcheroo vga_default_device represents the active GPU (the one that would be handling legacy VGA I/O if used - and the one controlling the output connectors) vga_switcheroo is actively changing vga_default_device. gmux is a driver for vga_switcheroo to perform the low-level platform operations allowing switching (outputs) from one GPU to the other. So a guess on my side would be that with both i915 and nouveau loaded you may be able to get your display working if you can tell X to switch GPU twice (and thus end up with matching vga_default_device and device selected by gmux) - though I don't know how one asks for this switch to happen. > > If there is no better way to detect the proper legacy VGA device the > > only remaining option would be to perform the screen_info testing in > > vga_arb_device_init() enclosed in arch #ifdef... I will propose a patch in this direction later this weekend. Bruno
[PATCH 1/2 v2] vgaarb: Don't default exclusively to first video device with mem+io
With commit 20cde694027e boot video device detection was moved from
efifb to x86 and ia64 pci/fixup.c.
For dual-GPU Apple computers above change represents a regression as
code in efifb did forcefully override vga_default_device while the
merge did not (vgaarb happens prior to PCI fixup).
To improve on initial device selection by vgaarb (it cannot know if
PCI device not behind bridges see/decode legacy VGA I/O or not), move
the screen_info based check from pci_video_fixup to vgaarb's init
function and use it to refine/override decision taken while adding
the individual PCI VGA devices.
This way PCI fixup has no reason to adjust vga_default_device
anymore but can depend on its value for flagging shadowed VBIOS.
This has the nice benefit of removing duplicated code but does
introduce a #if defined() block in vgaarb.
Not all architectures have screen_info and would cause compile to
fail without it.
Reported-By: Andreas Noever
CC: Matthew Garrett
CC: stable at vger.kernel.org # v3.5+
Signed-off-by: Bruno Pr?mont
---
Andreas, does this work properly for you, including the improvement
on i915 complaint about VBIOS going from KERN_ERR to KERN_INFO?
Other arches using PCI and vgaarb that have screen_info may want
to be added to the #if defined() block or even introduce a new
CONFIG_HAVE_SCREEN_INFO or similar...
arch/ia64/pci/fixup.c| 24 +---
arch/x86/pci/fixup.c | 24 +---
drivers/gpu/vga/vgaarb.c | 38 +-
3 files changed, 39 insertions(+), 47 deletions(-)
diff --git a/arch/ia64/pci/fixup.c b/arch/ia64/pci/fixup.c
index ec73b2c..fc505d5 100644
--- a/arch/ia64/pci/fixup.c
+++ b/arch/ia64/pci/fixup.c
@@ -38,27 +38,6 @@ static void pci_fixup_video(struct pci_dev *pdev)
return;
/* Maybe, this machine supports legacy memory map. */
- if (!vga_default_device()) {
- resource_size_t start, end;
- int i;
-
- /* Does firmware framebuffer belong to us? */
- for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
- if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM))
- continue;
-
- start = pci_resource_start(pdev, i);
- end = pci_resource_end(pdev, i);
-
- if (!start || !end)
- continue;
-
- if (screen_info.lfb_base >= start &&
- (screen_info.lfb_base + screen_info.lfb_size) < end)
- vga_set_default_device(pdev);
- }
- }
-
/* Is VGA routed to us? */
bus = pdev->bus;
while (bus) {
@@ -83,8 +62,7 @@ static void pci_fixup_video(struct pci_dev *pdev)
pci_read_config_word(pdev, PCI_COMMAND, &config);
if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
pdev->resource[PCI_ROM_RESOURCE].flags |=
IORESOURCE_ROM_SHADOW;
- dev_printk(KERN_DEBUG, &pdev->dev, "Boot video
device\n");
- vga_set_default_device(pdev);
+ dev_printk(KERN_DEBUG, &pdev->dev, "Video device with
shadowed ROM\n");
}
}
}
diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index c61ea57..9a2b710 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -326,27 +326,6 @@ static void pci_fixup_video(struct pci_dev *pdev)
struct pci_bus *bus;
u16 config;
- if (!vga_default_device()) {
- resource_size_t start, end;
- int i;
-
- /* Does firmware framebuffer belong to us? */
- for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
- if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM))
- continue;
-
- start = pci_resource_start(pdev, i);
- end = pci_resource_end(pdev, i);
-
- if (!start || !end)
- continue;
-
- if (screen_info.lfb_base >= start &&
- (screen_info.lfb_base + screen_info.lfb_size) < end)
- vga_set_default_device(pdev);
- }
- }
-
/* Is VGA routed to us? */
bus = pdev->bus;
while (bus) {
@@ -371,8 +350,7 @@ static void pci_fixup_video(struct pci_dev *pdev)
pci_read_config_word(pdev, PCI_COMMAND, &config);
if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
pdev->resource[PCI_ROM_RESOURCE].flags |=
IORESOURCE_ROM_SHADOW;
- dev_printk(KERN_DEBUG, &pdev->dev, "Boot video
device\n");
- vga_set_default_device(pdev);
+ dev_printk(KERN_DEBUG, &pdev->dev, "Video device with
shadowed ROM\n");
}
[PATCH 2/2 v2] vgaarb: Drop obsolete #ifndef
With commit 20cde694027e boot video device detection was moved from
efifb to x86 and ia64 pci/fixup.c.
Remove the left-over #ifndef check that will allways match since
the corresponding arch-specific define is gone with above patch.
Signed-off-by: Bruno Pr?mont
CC: Matthew Garrett
---
No fundamental change from previous iteration, just reversed the
patch ordering and dropped the stable@ tag as this is just clean-up.
drivers/gpu/vga/vgaarb.c | 8
include/linux/vgaarb.h | 2 --
2 files changed, 10 deletions(-)
diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index cffdff9..fb28314 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -113,10 +113,8 @@ both:
return 1;
}
-#ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
/* this is only used a cookie - it should not be dereferenced */
static struct pci_dev *vga_default;
-#endif
static void vga_arb_device_card_gone(struct pci_dev *pdev);
@@ -132,7 +130,6 @@ static struct vga_device *vgadev_find(struct pci_dev *pdev)
}
/* Returns the default VGA device (vgacon's babe) */
-#ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
struct pci_dev *vga_default_device(void)
{
return vga_default;
@@ -148,7 +145,6 @@ void vga_set_default_device(struct pci_dev *pdev)
pci_dev_put(vga_default);
vga_default = pci_dev_get(pdev);
}
-#endif
static inline void vga_irq_set_state(struct vga_device *vgadev, bool state)
{
@@ -584,14 +580,12 @@ static bool vga_arbiter_add_pci_device(struct pci_dev
*pdev)
/* Deal with VGA default device. Use first enabled one
* by default if arch doesn't have it's own hook
*/
-#ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
if (vga_default == NULL &&
((vgadev->owns & VGA_RSRC_LEGACY_MASK) == VGA_RSRC_LEGACY_MASK)) {
pr_info("vgaarb: setting as boot device: PCI:%s\n",
pci_name(pdev));
vga_set_default_device(pdev);
}
-#endif
vga_arbiter_check_bridge_sharing(vgadev);
@@ -625,10 +619,8 @@ static bool vga_arbiter_del_pci_device(struct pci_dev
*pdev)
goto bail;
}
-#ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
if (vga_default == pdev)
vga_set_default_device(NULL);
-#endif
if (vgadev->decodes & (VGA_RSRC_LEGACY_IO | VGA_RSRC_LEGACY_MEM))
vga_decode_count--;
diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h
index 2c02f3a..c37bd4d 100644
--- a/include/linux/vgaarb.h
+++ b/include/linux/vgaarb.h
@@ -182,7 +182,6 @@ extern void vga_put(struct pci_dev *pdev, unsigned int
rsrc);
* vga_get()...
*/
-#ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
#ifdef CONFIG_VGA_ARB
extern struct pci_dev *vga_default_device(void);
extern void vga_set_default_device(struct pci_dev *pdev);
@@ -190,7 +189,6 @@ extern void vga_set_default_device(struct pci_dev *pdev);
static inline struct pci_dev *vga_default_device(void) { return NULL; };
static inline void vga_set_default_device(struct pci_dev *pdev) { };
#endif
-#endif
/**
* vga_conflicts
--
1.8.5.5
[PATCH 0/2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()
Hi Daniel, On Mon, 25 Aug 2014 14:16:02 +0200 Daniel Vetter wrote: > Very often when something goes wrong with a kms driver we hang while doing > the initial modeset. Which is all done while holding the console_lock > (because fbdev+vt locking is just insane). You can try to get a closer > look with I915_FBDEV=n which will avoid the console_lock, but which also > won't register the legacy/compat i915 fbdev emulation any more, so greatly > changes boot behaviour. > > If that doesn't lead to clues the next approach is to "carefully" > drop&reacquire console_lock at a few "interesting" places to get a few > printks out over netconsole or similar. Or just hack up entire netconsole > loggin infrastructure which bypasses printk and so all the console_lock > insanity. In this case it's not that bad as Andreas could send the logs for all cases (captured via ssh). So probably console lock is not held (unless he did have to do terminal-free ssh which I doubt). It looks much more as if it's just the output routing that gets weird on his Mac (or possibly any other dual-GPU MacBook where discrete GPU is primary). Black screen but alive system :) See follow-up posts in this thread. If you have some uncommon or otherwise weird (EFI) multi-GPU systems around and want to give my patches sent yesterday evening a try, you're welcome! Some with non-Apple GPU multiplexer would be nice to have tested as well. The following part mentioned earlier by Andreas might be of interest to you though (and my latest patch series should bring the improvement): > > vga_arbiter_add_pci_device chooses intel simply because it is the > > first device. Next pci_fixup_video(intel) sees that it is the default > > device, sets the IORESOURCE_ROM_SHADOW flag and calls > > vga_set_default_device again. And finally (if the check is removed) > > pci_fixup_video(nvidia) sees that it owns the framebuffer and sets > > itself as the default device which allows the system to boot again. > > > > Does setting the ROM_SHADOW flag on (possibly) the wrong device have > > any effect? > Yes it does. Removing the line changes a long standing > i915 :00:02.0: Invalid ROM contents > into a > i915 :00:02.0: BAR 6: can't assign [??? 0x flags 0x2000] > (bogus alignment). > > The first is logged at KERN_ERR and the second one only at KERN_INFO. > We are making progress. Bruno
[PATCH 1/2 v2] vgaarb: Don't default exclusively to first video device with mem+io
On Tue, 26 August 2014 Andreas Noever wrote: > On Sun, Aug 24, 2014 at 11:09 PM, Bruno Pr?mont wrote: > > With commit 20cde694027e boot video device detection was moved from > > efifb to x86 and ia64 pci/fixup.c. > > > > For dual-GPU Apple computers above change represents a regression as > > code in efifb did forcefully override vga_default_device while the > > merge did not (vgaarb happens prior to PCI fixup). > > > > To improve on initial device selection by vgaarb (it cannot know if > > PCI device not behind bridges see/decode legacy VGA I/O or not), move > > the screen_info based check from pci_video_fixup to vgaarb's init > > function and use it to refine/override decision taken while adding > > the individual PCI VGA devices. > > This way PCI fixup has no reason to adjust vga_default_device > > anymore but can depend on its value for flagging shadowed VBIOS. > > > > This has the nice benefit of removing duplicated code but does > > introduce a #if defined() block in vgaarb. > > Not all architectures have screen_info and would cause compile to > > fail without it. > > > > Reported-By: Andreas Noever > > CC: Matthew Garrett > > CC: stable at vger.kernel.org # v3.5+ > > Signed-off-by: Bruno Pr?mont > > --- > > Andreas, does this work properly for you, including the improvement > > on i915 complaint about VBIOS going from KERN_ERR to KERN_INFO? > Yep, thanks! > > > > > Other arches using PCI and vgaarb that have screen_info may want > > to be added to the #if defined() block or even introduce a new > > CONFIG_HAVE_SCREEN_INFO or similar... Bjorn, can you queue these two patches, probably going through -next for a week and passing them to Linus for -rc4, adding Andreas's Tested-by to Patch 1/2 v2? Thanks, Bruno
X.org doesn't start with 3.14: [KMS] drm report modesetting isn't supported
Hi Justin, CC-ing dri-devel as more KMS/radeon people will see it there. On Mon, 31 March 2014 "Justin Piszcz" wrote: > Do I need some updated ATI firmware (I believe this might have happened in > the past)..? > I booted back to 3.13.6, Xorg starts up fine, but with 3.14 it does not > start. Could you include all the drm/kms/radeon related output from your kernel log as well as your /proc/cmdline? Also, are /sys/class/drm/card0* entries present with proper contents (modes, enabled, status attributes present and with sensible values)? What exact AMD/ATI GPU is present in your system (lspci)? Are your graphics drivers built-in or built as a module? Bruno > Thoughts? > > 3.13.6: > $ ps auxww|grep X > root 4368 5.3 0.0 296648 37364 tty7 Ssl+ 18:23 0:00 /usr/bin/X > :0 vt7 -nolisten tcp > > 3.14: > [ 346.490] (**) ModulePath set to "/usr/lib/xorg/modules" > [ 346.490] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or > 'vmmouse' will be disabled. > [ 346.490] (WW) Disabling Mouse0 > [ 346.490] (WW) Disabling Keyboard0 > [ 346.490] (II) [KMS] drm report modesetting isn't supported. > [ 346.490] (EE) > [ 346.490] (EE) Backtrace: > [ 346.490] (EE) 0: Xorg (xorg_backtrace+0x48) [0x7fbbbd731c58] > [ 346.490] (EE) 1: Xorg (0x7fbbbd58a000+0x1ab949) [0x7fbbbd735949] > [ 346.490] (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 > (0x7fbbbc3c5000+0xf880) [0x7fbbbc3d4880] > [ 346.490] (EE) > [ 346.490] (EE) Segmentation fault at address 0x0 > [ 346.490] (EE) > Fatal server error: > [ 346.491] (EE) Caught signal 11 (Segmentation fault). Server aborting > [ 346.491] (EE) > [ 346.491] (EE) > Please consult the The X.Org Foundation support >at http://wiki.x.org > for help. > [ 346.491] (EE) Please also check the log file at "/var/log/Xorg.0.log" > for additional information. > [ 346.491] (EE) > > Kernel config: > http://home.comcast.net/~jpiszcz/20140331/3.14.txt > > Kernel diffs: > > $ diff -u config-20140331.1396303540 config-20140320.1395308867 | grep \^+ > +++ config-20140320.1395308867 2014-03-20 05:47:47.508584015 -0400 > +# Linux/x86 3.13.6 Kernel Configuration > +CONFIG_UIDGID_STRICT_TYPE_CHECKS=y > +CONFIG_MICROCODE_INTEL_LIB=y > +# CONFIG_CC_STACKPROTECTOR is not set > +# CONFIG_SCSI_AIC7XXX_OLD is not set > +# CONFIG_CPU_THERMAL is not set > +# CONFIG_GENERIC_PHY is not set > > $ diff -u config-20140331.1396303540 config-20140320.1395308867 | grep \^- > --- config-20140331.1396303540 2014-03-31 18:05:40.775863929 -0400 > -# Linux/x86 3.14.0 Kernel Configuration > -CONFIG_HAVE_CC_STACKPROTECTOR=y > -# CONFIG_CC_STACKPROTECTOR is not set > -CONFIG_CC_STACKPROTECTOR_NONE=y > -# CONFIG_CC_STACKPROTECTOR_REGULAR is not set > -# CONFIG_CC_STACKPROTECTOR_STRONG is not set > -# CONFIG_ZSMALLOC is not set > -# CONFIG_NETFILTER_XT_MATCH_IPCOMP is not set > -# CONFIG_NETFILTER_XT_MATCH_L2TP is not set > -# CONFIG_GENWQE is not set > -# CONFIG_I40EVF is not set > -CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y > -# CONFIG_I2C_DESIGNWARE_PLATFORM is not set > -# CONFIG_I2C_ROBOTFUZZ_OSIF is not set > -# CONFIG_ACPI_INT3403_THERMAL is not set > -# CONFIG_DW_WATCHDOG is not set > -# CONFIG_MFD_MAX14577 is not set > -# CONFIG_MFD_LP3943 is not set > -# CONFIG_DRM_I915 is not set > -# CONFIG_DRM_BOCHS is not set > -# CONFIG_FB_OPENCORES is not set > -# CONFIG_USB_MUSB_HDRC is not set > -# CONFIG_USB_DWC2 is not set > -# CONFIG_USB_SERIAL_MXUPORT is not set > -# CONFIG_USB_OTG_FSM is not set > -# CONFIG_RTC_DRV_ISL12057 is not set > -# CONFIG_HP_WIRELESS is not set > -CONFIG_GENERIC_PHY=y > -# CONFIG_BCM_KONA_USB2_PHY is not set > -CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y > -CONFIG_PANIC_TIMEOUT=0 > > > > Justin.
[PATCH 1/3] nouveau: Do not BUG_ON(!spin_is_locked()) on UP
On !SMP systems spinlocks do not exist. Thus checking of they
are active will always fail.
Use
assert_spin_locked(lock);
instead of
BUG_ON(!spin_is_locked(lock));
to not BUG() on all UP systems.
Signed-off-by: Bruno Prémont
---
See also fdo bug #87552
drivers/gpu/drm/nouveau/core/core/event.c | 4 ++--
drivers/gpu/drm/nouveau/core/core/notify.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
b/drivers/gpu/drm/nouveau/core/core/event.c
index ff2b434..760947e 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -26,7 +26,7 @@
void
nvkm_event_put(struct nvkm_event *event, u32 types, int index)
{
- BUG_ON(!spin_is_locked(&event->refs_lock));
+ assert_spin_locked(&event->refs_lock);
while (types) {
int type = __ffs(types); types &= ~(1 << type);
if (--event->refs[index * event->types_nr + type] == 0) {
@@ -39,7 +39,7 @@ nvkm_event_put(struct nvkm_event *event, u32 types, int index)
void
nvkm_event_get(struct nvkm_event *event, u32 types, int index)
{
- BUG_ON(!spin_is_locked(&event->refs_lock));
+ assert_spin_locked(&event->refs_lock);
while (types) {
int type = __ffs(types); types &= ~(1 << type);
if (++event->refs[index * event->types_nr + type] == 1) {
diff --git a/drivers/gpu/drm/nouveau/core/core/notify.c
b/drivers/gpu/drm/nouveau/core/core/notify.c
index d1bcde5..839a325 100644
--- a/drivers/gpu/drm/nouveau/core/core/notify.c
+++ b/drivers/gpu/drm/nouveau/core/core/notify.c
@@ -98,7 +98,7 @@ nvkm_notify_send(struct nvkm_notify *notify, void *data, u32
size)
struct nvkm_event *event = notify->event;
unsigned long flags;
- BUG_ON(!spin_is_locked(&event->list_lock));
+ assert_spin_locked(&event->list_lock);
BUG_ON(size != notify->size);
spin_lock_irqsave(&event->refs_lock, flags);
--
1.8.1.5
[PATCH 3/3] msm: Do not BUG_ON(!spin_is_locked()) on UP
On !SMP systems spinlocks do not exist. Thus checking of they are active will always fail. Use assert_spin_locked(lock); instead of BUG_ON(!spin_is_locked(lock)); to not BUG() on all UP systems. Signed-off-by: Bruno Prémont --- drivers/gpu/drm/msm/mdp/mdp_kms.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/mdp/mdp_kms.c b/drivers/gpu/drm/msm/mdp/mdp_kms.c index 03455b6..f5e2173 100644 --- a/drivers/gpu/drm/msm/mdp/mdp_kms.c +++ b/drivers/gpu/drm/msm/mdp/mdp_kms.c @@ -34,7 +34,7 @@ static void update_irq(struct mdp_kms *mdp_kms) struct mdp_irq *irq; uint32_t irqmask = mdp_kms->vblank_mask; - BUG_ON(!spin_is_locked(&list_lock)); + assert_spin_locked(&list_lock)); list_for_each_entry(irq, &mdp_kms->irq_list, node) irqmask |= irq->irqmask; -- 1.8.1.5
[PATCH 2/3] omap: Do not BUG_ON(!spin_is_locked()) on UP
On !SMP systems spinlocks do not exist. Thus checking of they are active will always fail. Use assert_spin_locked(lock); instead of BUG_ON(!spin_is_locked(lock)); to not BUG() on all UP systems. Signed-off-by: Bruno Prémont --- drivers/gpu/drm/omapdrm/omap_irq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c b/drivers/gpu/drm/omapdrm/omap_irq.c index f035d2b..6ca9253 100644 --- a/drivers/gpu/drm/omapdrm/omap_irq.c +++ b/drivers/gpu/drm/omapdrm/omap_irq.c @@ -34,7 +34,7 @@ static void omap_irq_update(struct drm_device *dev) struct omap_drm_irq *irq; uint32_t irqmask = priv->vblank_mask; - BUG_ON(!spin_is_locked(&list_lock)); + assert_spin_locked(&list_lock)); list_for_each_entry(irq, &priv->irq_list, node) irqmask |= irq->irqmask; -- 1.8.1.5
[PATCH 2/3] omap: Do not BUG_ON(!spin_is_locked()) on UP
On Mon, 22 Dec 2014 08:46:48 -0500 Rob Clark wrote: > On Sun, Dec 21, 2014 at 11:43 AM, Bruno Prémont wrote: > > On !SMP systems spinlocks do not exist. Thus checking of they > > are active will always fail. > > > > Use > > assert_spin_locked(lock); > > instead of > > BUG_ON(!spin_is_locked(lock)); > > to not BUG() on all UP systems. > > > > Signed-off-by: Bruno Prémont > > --- > > drivers/gpu/drm/omapdrm/omap_irq.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c > > b/drivers/gpu/drm/omapdrm/omap_irq.c > > index f035d2b..6ca9253 100644 > > --- a/drivers/gpu/drm/omapdrm/omap_irq.c > > +++ b/drivers/gpu/drm/omapdrm/omap_irq.c > > @@ -34,7 +34,7 @@ static void omap_irq_update(struct drm_device *dev) > > struct omap_drm_irq *irq; > > uint32_t irqmask = priv->vblank_mask; > > > > - BUG_ON(!spin_is_locked(&list_lock)); > > + assert_spin_locked(&list_lock)); > > btw, one too many ')' there... I've fixed up the same issue w/ msm > patch as I applied it Oops. I got it right for the nouveau patch, so I was probably too quick doing the manual replace for the other occurrences in drivers/gpu/. I didn't check how far back these BUG_ON() go though they might be worth applying to stable trees as well (could be the assert_spin_locked() macro appeared only after the introduction of some of these BUG_ON()s though). I've hit them on nouveau on 3.18 and 3.19-rc1. Bruno > BR, > -R > > > > > > list_for_each_entry(irq, &priv->irq_list, node) > > irqmask |= irq->irqmask; > > -- > > 1.8.1.5
drm/nouveau: NULL pointer deref in drm_handle_vblank() on rebind
I can easily trigger a crash in nouveau interrupt handler by unbinding and rebinding the GPU. The command used: echo $pci_device > nouveau/unbind && \ sleep 5 && \ echo $pci_device > nouveau/bind Kernel is 3.4.0 with modular drm/nouveau. GPU is NVidia nForce IGP (NV11) Unbinding seems to work fine, display switching back to VGA text mode. Rebinding the GPU slightly later causes the below trace: Bruno (analysis following below trace) [ 1432.012832] Console: switching to colour VGA+ 80x25 [ 1432.014796] drm: unregistered panic notifier [ 1432.014905] [drm] nouveau :02:00.0: Setting dpms mode 3 on vga encoder (output 0) [ 1432.026324] [drm] nouveau :02:00.0: 0xAFD8: Parsing digital output script table [ 1432.026611] [drm] nouveau :02:00.0: Restoring VGA fonts [ 1432.028353] [TTM] Finalizing pool allocator [ 1432.029325] [TTM] Zone kernel: Used memory at exit: 0 kiB [ 1437.066950] [drm] nouveau :02:00.0: Detected an NV10 generation card (0x01a000b1) [ 1437.068909] [drm] nouveau :02:00.0: Checking PRAMIN for VBIOS [ 1437.103400] [drm] nouveau :02:00.0: ... BIOS checksum invalid [ 1437.103459] [drm] nouveau :02:00.0: Checking PROM for VBIOS [ 1437.103638] [drm] nouveau :02:00.0: ... BIOS checksum invalid [ 1437.103694] [drm] nouveau :02:00.0: Checking ACPI for VBIOS [ 1437.103859] [drm] nouveau :02:00.0: ... BIOS checksum invalid [ 1437.103915] [drm] nouveau :02:00.0: Checking PCIROM for VBIOS [ 1437.105143] [drm] nouveau :02:00.0: ... appears to be valid [ 1437.105217] [drm] nouveau :02:00.0: Using VBIOS from PCIROM [ 1437.105507] [drm] nouveau :02:00.0: BMP BIOS found [ 1437.105562] [drm] nouveau :02:00.0: BMP version 5.20 [ 1437.105624] [drm] nouveau :02:00.0: Bios version 03.1a.01.03 [ 1437.107663] [drm] nouveau :02:00.0: MXM: no VBIOS data, nothing to do [ 1437.109053] [drm] nouveau :02:00.0: Parsing VBIOS init table 0 at offset 0xA850 [ 1437.109120] [drm] nouveau :02:00.0: Parsing VBIOS init table 1 at offset 0xADC5 [ 1437.109197] [drm] nouveau :02:00.0: Parsing VBIOS init table 2 at offset 0xA851 [ 1437.109268] [drm] nouveau :02:00.0: Parsing VBIOS init table 3 at offset 0xADC4 [ 1437.109337] [drm] nouveau :02:00.0: Parsing VBIOS init table 4 at offset 0xA875 [ 1437.109405] [drm] nouveau :02:00.0: Parsing VBIOS init table 5 at offset 0xA931 [ 1437.109494] [drm] nouveau :02:00.0: Parsing VBIOS init table 6 at offset 0xA876 [ 1437.109572] [drm] nouveau :02:00.0: Parsing VBIOS init table 7 at offset 0xA8CC [ 1437.109985] [TTM] Zone kernel: Available graphics memory: 240004 kiB [ 1437.110079] [TTM] Initializing pool allocator [ 1437.110177] [drm] nouveau :02:00.0: Detected 32MiB VRAM (unknown type) [ 1437.110424] agpgart-nvidia :00:00.0: AGP 2.0 bridge [ 1437.110566] agpgart-nvidia :00:00.0: putting AGP V2 device into 4x mode [ 1437.110717] nouveau :02:00.0: putting AGP V2 device into 4x mode [ 1437.110783] agpgart-nvidia :00:00.0: AGP 2.0 bridge [ 1437.110865] agpgart-nvidia :00:00.0: putting AGP V2 device into 4x mode [ 1437.111010] nouveau :02:00.0: putting AGP V2 device into 4x mode [ 1437.111070] [drm] nouveau :02:00.0: 32 MiB GART (aperture) [ 1437.111233] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.111298] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.111363] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.111427] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.111489] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.111551] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.111613] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.111676] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.111737] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.111800] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.111862] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.111924] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.111986] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.112048] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.112110] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.112172] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.112233] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.112296] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.112357] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.112420] [drm] nouveau :02:00.0: PMC - unhandled INTR 0x0100 [ 1437.112577] [drm] nouveau :02:00.0: Saving VGA fonts [ 1437.175978] BUG: unable to handle kernel NULL pointer dereference at (null) [ 1437.176134] IP: [] drm_handle_vblank+0x3c/0x1d0 [ 1437.176314] *pde = [ 1
[RFC patch] PCI: Extend boot_vga sysfs attribute lookup to fix X on MBA+EFI
On a MacBookAir2,1, booting to Linux with EFI though having
no efifb built-in Xorg refuses to start with "no devices detected"
because for the only VGA device available (NVidia Geforce 9400M)
the sysfs attribute boot_vga is zero (instead of expected 1).
When CONFIG_FB_EFI is selected, efifb does provide its own
vga_default_device() to report the PCI device matching global
screen_info as determined during efifb setup.
Otherwise there is just a dummy or VGA_ARB's vga_default_device()
that does not provide the right information.
On the other hand, boot_vga_show() falls back to poking PCI
resources to flag a PCI device as boot_vga if vga_default_device()
returned no PCI device (NULL).
To complement this PCI resource poking, this patch copies the
validation code used to determine which PCI device to report as
default VGA device by efifb into boot_vga_show().
Signed-off-by: Bruno Pr?mont
---
Would it make sense to kill the corresponding code from efifb
as it covers only a single case?
The other EFI capable system I have (AMD Ilano based, Gigabyte
mainboard does report boot_vga=1, possibly through the resources
poking and there Xorg starts properly without efifb built in.
Selecting CONFIG_X86_SYSFB (combined with CONFIG_FB_SIMPLE) does
not help by itself, patching that one instead of PCI's boot_vga
attribute directly would still not cover the case when neither
of them is enabled.
drivers/pci/pci-sysfs.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 7128cfd..91cac71 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include "pci.h"
@@ -540,6 +541,26 @@ boot_vga_show(struct device *dev, struct device_attribute
*attr, char *buf)
if (vga_dev)
return sprintf(buf, "%u\n", (pdev == vga_dev));
+ if ((pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA) {
+ resource_size_t start, end;
+ int i;
+
+ for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
+ if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM))
+ continue;
+
+ start = pci_resource_start(pdev, i);
+ end = pci_resource_end(pdev, i);
+
+ if (!start || !end)
+ continue;
+
+ if (screen_info.lfb_base >= start &&
+ (screen_info.lfb_base + screen_info.lfb_size) <
end)
+ return sprintf(buf, "1\n");
+ }
+ }
+
return sprintf(buf, "%u\n",
!!(pdev->resource[PCI_ROM_RESOURCE].flags &
IORESOURCE_ROM_SHADOW));
[RFC patch] PCI: Extend boot_vga sysfs attribute lookup to fix X on MBA+EFI
On Mon, 25 November 2013 Bjorn Helgaas wrote:
> On Mon, Nov 25, 2013 at 12:54 PM, Bruno Pr?mont wrote:
> > On a MacBookAir2,1, booting to Linux with EFI though having
> > no efifb built-in Xorg refuses to start with "no devices detected"
> > because for the only VGA device available (NVidia Geforce 9400M)
> > the sysfs attribute boot_vga is zero (instead of expected 1).
> >
> > When CONFIG_FB_EFI is selected, efifb does provide its own
> > vga_default_device() to report the PCI device matching global
> > screen_info as determined during efifb setup.
> >
> > Otherwise there is just a dummy or VGA_ARB's vga_default_device()
> > that does not provide the right information.
>
> Wouldn't it be cleaner to fix vga_default_device() so it returns the
> correct thing even when CONFIG_FB_EFI=n?
I would rather completely drop the vga_default_device() from efifb
(CONFIG_FB_EFI) and just keep vga_default_device() for
vga-arbitration/vga-switcheroo.
The fact that there are currently *two* instances of that function
doesn't make life easy for determining who is providing it and when.
drivers/gpu/vga/vgaarb.c:135
drivers/video/efifb.c:88
include/linux/vgaarb.h:190 (dummy)
> > On the other hand, boot_vga_show() falls back to poking PCI
> > resources to flag a PCI device as boot_vga if vga_default_device()
> > returned no PCI device (NULL).
> >
> > To complement this PCI resource poking, this patch copies the
> > validation code used to determine which PCI device to report as
> > default VGA device by efifb into boot_vga_show().
>
> If we do have to use logic like this, I'd like it better if it were
> factored into a single function called both here and from
> efifb_setup().
As of above, I would preferably drop that part of code from
efifb_setup() and have the logic called only in one place and each
time the same way.
Otherwise efifb versus x86_sysfb+simplefb or directly going to
native driver (nvoueau/radeon/...) behave differently without reason.
Bruno
> > Signed-off-by: Bruno Pr?mont
> > ---
> > Would it make sense to kill the corresponding code from efifb
> > as it covers only a single case?
> >
> > The other EFI capable system I have (AMD Ilano based, Gigabyte
> > mainboard does report boot_vga=1, possibly through the resources
> > poking and there Xorg starts properly without efifb built in.
> >
> > Selecting CONFIG_X86_SYSFB (combined with CONFIG_FB_SIMPLE) does
> > not help by itself, patching that one instead of PCI's boot_vga
> > attribute directly would still not cover the case when neither
> > of them is enabled.
> >
> >
> > drivers/pci/pci-sysfs.c | 21 +
> > 1 file changed, 21 insertions(+)
> >
> > diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> > index 7128cfd..91cac71 100644
> > --- a/drivers/pci/pci-sysfs.c
> > +++ b/drivers/pci/pci-sysfs.c
> > @@ -28,6 +28,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include "pci.h"
> >
> > @@ -540,6 +541,26 @@ boot_vga_show(struct device *dev, struct
> > device_attribute *attr, char *buf)
> > if (vga_dev)
> > return sprintf(buf, "%u\n", (pdev == vga_dev));
> >
> > + if ((pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA) {
> > + resource_size_t start, end;
> > + int i;
> > +
> > + for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
> > + if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM))
> > + continue;
> > +
> > + start = pci_resource_start(pdev, i);
> > + end = pci_resource_end(pdev, i);
> > +
> > + if (!start || !end)
> > + continue;
> > +
> > + if (screen_info.lfb_base >= start &&
> > + (screen_info.lfb_base +
> > screen_info.lfb_size) < end)
> > + return sprintf(buf, "1\n");
> > + }
> > + }
> > +
> > return sprintf(buf, "%u\n",
> > !!(pdev->resource[PCI_ROM_RESOURCE].flags &
> >IORESOURCE_ROM_SHADOW));
[RFC patch] PCI: Extend boot_vga sysfs attribute lookup to fix X on MBA+EFI
Hi David,
On Wed, 27 Nov 2013 21:40:39 +0100 David Herrmann wrote:
> On Mon, Nov 25, 2013 at 8:54 PM, Bruno Pr?mont wrote:
> > On a MacBookAir2,1, booting to Linux with EFI though having
> > no efifb built-in Xorg refuses to start with "no devices detected"
> > because for the only VGA device available (NVidia Geforce 9400M)
> > the sysfs attribute boot_vga is zero (instead of expected 1).
> >
> > When CONFIG_FB_EFI is selected, efifb does provide its own
> > vga_default_device() to report the PCI device matching global
> > screen_info as determined during efifb setup.
> >
> > Otherwise there is just a dummy or VGA_ARB's vga_default_device()
> > that does not provide the right information.
> >
> > On the other hand, boot_vga_show() falls back to poking PCI
> > resources to flag a PCI device as boot_vga if vga_default_device()
> > returned no PCI device (NULL).
> >
> > To complement this PCI resource poking, this patch copies the
> > validation code used to determine which PCI device to report as
> > default VGA device by efifb into boot_vga_show().
> >
> > Signed-off-by: Bruno Pr?mont
> > ---
> > Would it make sense to kill the corresponding code from efifb
> > as it covers only a single case?
> >
> > The other EFI capable system I have (AMD Ilano based, Gigabyte
> > mainboard does report boot_vga=1, possibly through the resources
> > poking and there Xorg starts properly without efifb built in.
> >
> > Selecting CONFIG_X86_SYSFB (combined with CONFIG_FB_SIMPLE) does
> > not help by itself, patching that one instead of PCI's boot_vga
> > attribute directly would still not cover the case when neither
> > of them is enabled.
>
> How about moving the code from efifb to arch/x86/kernel/sysfb_efi.c?
> efifb is x86 only so we don't break anything by this. And all the
> other efi-quirks have already been moved. Imho this would be the
> easiest fix right now. But if you can spend some time to clean up the
> vga_default_device() mess, please go ahead.
Well, I don't know how things work on other arches where GPU is
a PCI device...
Possibly the issue exists for any arch whose firmware does not cause
!!(pdev->resource[PCI_ROM_RESOURCE].flags & IORESOURCE_ROM_SHADOW)
to be 1 and for which there is no magic vga_default_device()
re-implementation.
That's the reason why I don't think moving it to any arch/firmware
place is such a good idea.
I will cook the vga_default_device() cleanup over the weekend and
post a follow-up patch by then.
> Btw., thanks for tracking this down. It bothered me for quite some
> while that Xorg ignores my cards if I boot via efi..
I already hit it a year ago or so and did hide it by keeping
efifb enabled on the MBA (had not been looking at the cause by then
though, thinking it was some magic EFI poking needed on MBA as
FB_EFI=n worked fine on a EFI PC system with radeon).
Bruno
> Thanks
> David
>
> >
> > drivers/pci/pci-sysfs.c | 21 +
> > 1 file changed, 21 insertions(+)
> >
> > diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> > index 7128cfd..91cac71 100644
> > --- a/drivers/pci/pci-sysfs.c
> > +++ b/drivers/pci/pci-sysfs.c
> > @@ -28,6 +28,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include "pci.h"
> >
> > @@ -540,6 +541,26 @@ boot_vga_show(struct device *dev, struct
> > device_attribute *attr, char *buf)
> > if (vga_dev)
> > return sprintf(buf, "%u\n", (pdev == vga_dev));
> >
> > + if ((pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA) {
> > + resource_size_t start, end;
> > + int i;
> > +
> > + for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
> > + if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM))
> > + continue;
> > +
> > + start = pci_resource_start(pdev, i);
> > + end = pci_resource_end(pdev, i);
> > +
> > + if (!start || !end)
> > + continue;
> > +
> > + if (screen_info.lfb_base >= start &&
> > + (screen_info.lfb_base +
> > screen_info.lfb_size) < end)
> > + return sprintf(buf, "1\n");
> > + }
> > + }
> > +
> > return sprintf(buf, "%u\n",
> > !!(pdev->resource[PCI_ROM_RESOURCE].flags &
> >IORESOURCE_ROM_SHADOW));
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC patch v2] x86: Improve boot_vga/vga_default_device() for EFI
With commit b4aa0163056b6c70029b6e8619ce07c274351f42 Matthew Garret
introduced a efifb vga_default_device() so that EFI systems that do not
load shadow VBIOS or setup VGA get proper value for boot_vga PCI sysfs
attribute on the corresponding PCI device.
Xorg is refusing to detect devices when boot_vga=0 which is the case
on some EFI system (e.g. MacBookAir2,1). Xorg detects the GPU and finds
the dri device but then bails out with "no devices detected".
With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete
while having native drivers for the GPU also makes selecting sysfb/efifb
optional.
Remove the efifb implementation of vga_default_device() and initialize
vgaarb's vga_default_device() with the PCI GPU that matches boot
screen_info in x86's pci_fixup_video().
Notes:
- Other architectures with PCI GPU might need a similar fixup.
- If CONFIG_VGA_ARB is unset vga_default_device() is only available
as a stub that returns NULL, making this adjustment insufficient.
Unsetting CONFIG_VGA_ARB requires CONFIG_EXPERT=y though.
Signed-off-by: Bruno Pr?mont
---
arch/x86/include/asm/vga.h | 6 --
arch/x86/pci/fixup.c | 21 +
drivers/video/efifb.c | 38 --
3 files changed, 21 insertions(+), 44 deletions(-)
diff --git a/arch/x86/include/asm/vga.h b/arch/x86/include/asm/vga.h
index 44282fb..c4b9dc2 100644
--- a/arch/x86/include/asm/vga.h
+++ b/arch/x86/include/asm/vga.h
@@ -17,10 +17,4 @@
#define vga_readb(x) (*(x))
#define vga_writeb(x, y) (*(y) = (x))
-#ifdef CONFIG_FB_EFI
-#define __ARCH_HAS_VGA_DEFAULT_DEVICE
-extern struct pci_dev *vga_default_device(void);
-extern void vga_set_default_device(struct pci_dev *pdev);
-#endif
-
#endif /* _ASM_X86_VGA_H */
diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index f5809fa..440343e 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
@@ -323,6 +324,26 @@ static void pci_fixup_video(struct pci_dev *pdev)
struct pci_bus *bus;
u16 config;
+ if (!vga_default_device()) {
+ resource_size_t start, end;
+ int i;
+
+ for (i=0; i < DEVICE_COUNT_RESOURCE; i++) {
+ if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM))
+ continue;
+
+ start = pci_resource_start(pdev, i);
+ end = pci_resource_end(pdev, i);
+
+ if (!start || !end)
+ continue;
+
+ if (screen_info.lfb_base >= start &&
+ (screen_info.lfb_base + screen_info.lfb_size) <
end)
+ vga_set_default_device(pdev);
+ }
+ }
+
/* Is VGA routed to us? */
bus = pdev->bus;
while (bus) {
diff --git a/drivers/video/efifb.c b/drivers/video/efifb.c
index 7f9ff75..fb3fb50 100644
--- a/drivers/video/efifb.c
+++ b/drivers/video/efifb.c
@@ -19,8 +19,6 @@
static bool request_mem_succeeded = false;
-static struct pci_dev *default_vga;
-
static struct fb_var_screeninfo efifb_defined = {
.activate = FB_ACTIVATE_NOW,
.height = -1,
@@ -85,18 +83,6 @@ static struct fb_ops efifb_ops = {
.fb_imageblit = cfb_imageblit,
};
-struct pci_dev *vga_default_device(void)
-{
- return default_vga;
-}
-
-EXPORT_SYMBOL_GPL(vga_default_device);
-
-void vga_set_default_device(struct pci_dev *pdev)
-{
- default_vga = pdev;
-}
-
static int efifb_setup(char *options)
{
char *this_opt;
@@ -127,30 +113,6 @@ static int efifb_setup(char *options)
}
}
- for_each_pci_dev(dev) {
- int i;
-
- if ((dev->class >> 8) != PCI_CLASS_DISPLAY_VGA)
- continue;
-
- for (i=0; i < DEVICE_COUNT_RESOURCE; i++) {
- resource_size_t start, end;
-
- if (!(pci_resource_flags(dev, i) & IORESOURCE_MEM))
- continue;
-
- start = pci_resource_start(dev, i);
- end = pci_resource_end(dev, i);
-
- if (!start || !end)
- continue;
-
- if (screen_info.lfb_base >= start &&
- (screen_info.lfb_base + screen_info.lfb_size) < end)
- default_vga = dev;
- }
- }
-
return 0;
}
[PATCH 1/3] nouveau: Do not BUG_ON(!spin_is_locked()) on UP
Hi Greg, stable team,
Please apply this patch to stable (3.18 and 3.17).
It is commit ff4c0d5213b015e60aa87c1352604f10ba9c3e12 in linus's tree:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ff4c0d5213b015e60aa87c1352604f10ba9c3e12
Thanks,
Bruno
On Sun, 21 December 2014 Bruno Prémont wrote:
> On !SMP systems spinlocks do not exist. Thus checking of they
> are active will always fail.
>
> Use
> assert_spin_locked(lock);
> instead of
> BUG_ON(!spin_is_locked(lock));
> to not BUG() on all UP systems.
>
> Signed-off-by: Bruno Prémont
> ---
> See also fdo bug #87552
>
> drivers/gpu/drm/nouveau/core/core/event.c | 4 ++--
> drivers/gpu/drm/nouveau/core/core/notify.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
> b/drivers/gpu/drm/nouveau/core/core/event.c
> index ff2b434..760947e 100644
> --- a/drivers/gpu/drm/nouveau/core/core/event.c
> +++ b/drivers/gpu/drm/nouveau/core/core/event.c
> @@ -26,7 +26,7 @@
> void
> nvkm_event_put(struct nvkm_event *event, u32 types, int index)
> {
> - BUG_ON(!spin_is_locked(&event->refs_lock));
> + assert_spin_locked(&event->refs_lock);
> while (types) {
> int type = __ffs(types); types &= ~(1 << type);
> if (--event->refs[index * event->types_nr + type] == 0) {
> @@ -39,7 +39,7 @@ nvkm_event_put(struct nvkm_event *event, u32 types, int
> index)
> void
> nvkm_event_get(struct nvkm_event *event, u32 types, int index)
> {
> - BUG_ON(!spin_is_locked(&event->refs_lock));
> + assert_spin_locked(&event->refs_lock);
> while (types) {
> int type = __ffs(types); types &= ~(1 << type);
> if (++event->refs[index * event->types_nr + type] == 1) {
> diff --git a/drivers/gpu/drm/nouveau/core/core/notify.c
> b/drivers/gpu/drm/nouveau/core/core/notify.c
> index d1bcde5..839a325 100644
> --- a/drivers/gpu/drm/nouveau/core/core/notify.c
> +++ b/drivers/gpu/drm/nouveau/core/core/notify.c
> @@ -98,7 +98,7 @@ nvkm_notify_send(struct nvkm_notify *notify, void *data,
> u32 size)
> struct nvkm_event *event = notify->event;
> unsigned long flags;
>
> - BUG_ON(!spin_is_locked(&event->list_lock));
> + assert_spin_locked(&event->list_lock);
> BUG_ON(size != notify->size);
>
> spin_lock_irqsave(&event->refs_lock, flags);
