On Fri, Dec 13, 2024 at 10:35:03AM +0200, Kalle Valo wrote:
> I agree, it makes the code harder to read for someone who is not
> familiar with all the %p magic we have (like me).
+1
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Sun, Sep 08, 2024 at 11:53:56PM -0700, Hugues Bruant wrote:
> Hi,
>
> I have discovered a 100% reliable soft lockup on boot on my laptop:
> Purism Librem 14, Intel Core i7-10710U, 48Gb RAM, Samsung Evo Plus 970
> SSD, CoreBoot BIOS, grub bootloader, Arch Linux.
>
> The last working release is
el.org/intel-gfx/20240227100342.GAZd2zfmYcPS_SndtO@fat_crate.local/
> Reported-by: Borislav Petkov
> Signed-off-by: Ville Syrjälä
Thanks for the fix - splat is gone.
Tested-by: Borislav Petkov (AMD)
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Tue, Feb 27, 2024 at 12:58:08PM +0200, Jani Nikula wrote:
> Let's see what Ville says, but in the end bisection might be the
> quickest way to find the regression. Though I understand it can be
> tedious for you personally.
That still fires with 6.-9-rc1. Does Ville have any suggestions or
shou
On Tue, Feb 27, 2024 at 12:58:08PM +0200, Jani Nikula wrote:
> Let's see what Ville says, but in the end bisection might be the
> quickest way to find the regression. Though I understand it can be
> tedious for you personally.
Ha, I can do it in parallel with the gazillion other things. :-)
It'll
On Tue, Feb 27, 2024 at 12:37:02PM +0200, Jani Nikula wrote:
> Is this a recent regression?
Yeah, no clue. Hadn't booted that machine since 6.7-rc1... I can bisect
if you want me to.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Hi all,
this lockdep splat at the end is from an old Atom 32-bit laptop with the
latest Linus + tip lineup:
[0.00] Linux version 6.8.0-rc6+ (boris@zn) (gcc (Debian 13.2.0-9)
13.2.0, GNU ld (GNU Binutils for Debian) 2.41.50.20231227) #1 SMP
PREEMPT_DYNAMIC Tue Feb 27 10:43:15 CET 2024
[
On Mon, Jul 10, 2023 at 09:36:14AM +0200, Janusz Krzysztofik wrote:
> Assume that adding _PAGE_PAT to _PAGE_CHG_MASK doesn't break pte_modify()
> and its users, and go for it. Also, add _PAGE_PAT_LARGE to
That's my only worry.
I'd suggest we queue this but not send it to Linus now. Instead, let
Hi,
I'm getting this on latest Linus master with gcc (SUSE Linux) 7.5.0:
DESCEND objtool
CALLscripts/checksyscalls.sh
CC [M] drivers/gpu/drm/i915/gt/uc/intel_guc_submission.o
In file included from :0:0:
In function ‘__guc_context_policy_add_priority.isra.45’,
inlined from ‘__guc_co
From: Borislav Petkov
Fix:
In file included from :0:0:
drivers/gpu/drm/i915/gt/uc/intel_guc.c: In function ‘intel_guc_send_mmio’:
././include/linux/compiler_types.h:352:38: error: call to
‘__compiletime_assert_1047’ \
declared with attribute error: FIELD_PREP: mask is not constant
n Thu, Jan 13, 2022 at 04:28:39PM -0800, Lucas De Marchi wrote:
> early_pci_scan_bus() does a depth-first traversal, possibly calling
> the quirk functions for each device based on vendor, device and class
> from early_qrk table. intel_graphics_quirks() however uses PCI_ANY_ID
> and does additional
On Mon, Nov 08, 2021 at 03:59:26PM -0500, Alan Stern wrote:
> Is there really any reason for returning an error code? For example, is
> it anticipated that at some point in the future these registration calls
> might fail?
>
> Currently, the only reason for failing...
Right, I believe with not
On Mon, Nov 08, 2021 at 11:23:13AM -0500, Steven Rostedt wrote:
> Question, how often does this warning trigger? Is it common to see in
> development?
Yeah, haven't seen it myself yet.
But we hashed it out over IRC. :-)
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-ne
On Mon, Nov 08, 2021 at 05:12:16PM +0100, Geert Uytterhoeven wrote:
> Returning void is the other extreme ;-)
>
> There are 3 levels (ignoring BUG_ON()/panic () inside the callee):
> 1. Return void: no one can check success or failure,
> 2. Return an error code: up to the caller to decide,
>
On Mon, Nov 08, 2021 at 04:25:47PM +0100, Geert Uytterhoeven wrote:
> I'm not against returning proper errors codes. I'm against forcing
> callers to check things that cannot fail and to add individual error
> printing to each and every caller.
If you're against checking things at the callers, th
On Mon, Nov 08, 2021 at 03:24:39PM +0100, Borislav Petkov wrote:
> I guess I can add another indirection to notifier_chain_register() and
> avoid touching all the call sites.
IOW, something like this below.
This way I won't have to touch all the callsites and the registration
rou
On Mon, Nov 08, 2021 at 09:17:03AM -0500, Alan Stern wrote:
> What reason is there for moving the check into the callers? It seems
> like pointless churn. Why not add the error return code, change the
> WARN to pr_warn, and leave the callers as they are? Wouldn't that end
> up having exactly
On Mon, Nov 08, 2021 at 03:07:03PM +0100, Geert Uytterhoeven wrote:
> I think the addition of __must_check is overkill, leading to the
> addition of useless error checks and message printing.
See the WARN in notifier_chain_register() - it will already do "message
printing".
> Many callers call th
From: Borislav Petkov
Avoid homegrown notifier registration checks.
No functional changes.
Signed-off-by: Borislav Petkov
Cc: intel-gvt-...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
---
drivers/gpu/drm/i915/gvt/scheduler.c | 6 --
1 file changed, 4 insertions(+), 2
From: Borislav Petkov
The notifier registration routine doesn't return a proper error value
when a callback has already been registered, leading people to track
whether that registration has happened at the call site:
https://lore.kernel.org/amd-gfx/20210512013058.6827-1-mukul.jo...@am
From: Borislav Petkov
Hi all,
this is a huge patchset for something which is really trivial - it
changes the notifier registration routines to return an error value
if a notifier callback is already present on the respective list of
callbacks. For more details scroll to the last patch
d62a200608e0b029056baf6
> drm/i915/jsl: Split EHL/JSL platform info and PCI ids
>
> V2:
> - Added maintainer list in cc
> - Added patch ref in commit message
> V1:
> - Added Cc: x...@kernel.org
>
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Pe
kula
> Cc: Ville Syrjälä
> Cc: Imre Deak
> Cc: x...@kernel.org
> Cc: Ingo Molnar ,
> Cc: Thomas Gleixner ,
> Cc: Borislav Petkov
> Signed-off-by: Caz Yokoyama
> Signed-off-by: Aditya Swarup
> Reviewed-by: Lucas De Marchi
> ---
<--- ... here, under those lines
On Mon, Jan 25, 2021 at 02:59:31AM -0800, Aditya Swarup wrote:
> From: Caz Yokoyama
>
> Alderlake-S is a Gen 12 based hybrid processor architeture. As it
typo: "architecture"
> belongs to Gen 12 family, it uses the same GTT stolen memory settings
> like its predecessors - ICL(Gen 11) and TGL(Ge
On Sun, Aug 02, 2020 at 02:14:06PM -0500, Bjorn Helgaas wrote:
> Wait, I'm not convinced yet. I know that if a PCI read fails, you
> normally get ~0 data because the host bridge fabricates it to complete
> the CPU load.
>
> But what guarantees that a PCI config register cannot contain ~0?
Well,
On Sun, Aug 02, 2020 at 07:28:00PM +0200, Saheed Bolarinwa wrote:
> Because the value ~0 has a meaning to some drivers and only
No, ~0 means that the PCI read failed. For *every* PCI device I know.
Here's me reading from 0xf0 offset of my hostbridge:
# setpci -s 00:00.0 0xf0.l
0100
That dev
On Sat, Aug 01, 2020 at 01:24:29PM +0200, Saheed O. Bolarinwa wrote:
> The return value of pci_read_config_*() may not indicate a device error.
> However, the value read by these functions is more likely to indicate
> this kind of error. This presents two overlapping ways of reporting
> errors and
ine _ASM_X86_DEVICE_H
>
> struct dev_archdata {
> -#ifdef CONFIG_IOMMU_API
> - void *iommu; /* hook for IOMMU specific extension */
> -#endif
> };
>
> struct pdev_archdata {
> --
Acked-by: Borislav Petkov
--
Regar
On Tue, May 19, 2020 at 04:57:27PM -0700, Lucas De Marchi wrote:
> The following files are outside of i915 maintenance scope:
> arch/x86/kernel/early-quirks.c
>
> Can we get an ack?
Acked-by: Borislav Petkov
> Going forward, for simple changes like this, do you prefer to still
On Fri, Mar 15, 2019 at 12:19:38PM -0700, Rodrigo Vivi wrote:
> Let's reserve EHL stolen memory for graphics.
>
> ElkhartLake is a gen11 platform which is compatible with
> ICL changes.
>
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
&g
Hi,
I see this on an 32-bit acer atom mini-laptop with -rc8+tip:
[2.399416] pipe B vblank wait timed out
[2.399506] [ cut here ]
[2.399533] WARNING: CPU: 1 PID: 22 at
/mnt/kernel/kernel/linux-2.6/drivers/gpu/drm/i915/intel_display.c:12176
intel_atomic_commit_
From: Borislav Petkov
Use the fast variant in the DRM code.
Signed-off-by: Borislav Petkov
Cc: dri-de...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
---
arch/x86/include/asm/cpufeature.h | 1 -
arch/x86/kernel/cpu/intel.c| 2 +-
arch/x86/kernel/tce_64.c
From: Borislav Petkov
Signed-off-by: Borislav Petkov
Cc: intel-gfx@lists.freedesktop.org
---
@tip guys, the pat_bsp_init() and pat_ap_init() hunk will conflict with
d63dcf49cf5a ("x86/mm/pat: Replace cpu_has_pat with boot_cpu_has()")
in tip/x86:mm. Let me know how you wanna han
From: Borislav Petkov
gcc complains on 32-bit like this:
drivers/gpu/drm/i915/intel_display.c: In function ‘intel_plane_obj_offset’:
drivers/gpu/drm/i915/intel_display.c:2954:11: warning: cast to pointer from \
integer of different size [-Wint-to-pointer-cast]
offset
+ intel-gfx@lists.freedesktop.org
On Thu, Oct 01, 2015 at 12:20:10AM -0700, Gary Barrueto wrote:
> Got a intel nuc i7 and am getting this when I start playing video in
> vlc and many times the system just freezes.
>
> Oct 1 00:08:59 inuc kernel: [ 81.127657] [ cut here
> ]
On Tue, Jan 20, 2015 at 01:17:10AM -0600, Larry Finger wrote:
> Hi,
>
> I just discovered almost 100 of the following entries in my log:
>
> [drm:intel_uncore_check_errors [i915]] *ERROR* Unclaimed register before
> interrupt
>
> Those were accumulated in about 12 hours of operation. I also hav
On Thu, Nov 13, 2014 at 07:33:54PM +0200, Ville Syrjälä wrote:
> We use it both ways in i915. So please don't break it.
Haha, we started from Intel with Ross' patch and made a full circle
back. Maybe you guys should talk about it.
LOL. :-)
--
Regards/Gruss,
Boris.
Sent from a fat crate und
On Thu, Nov 13, 2014 at 08:38:23AM -0800, Andy Lutomirski wrote:
> On Nov 13, 2014 3:20 AM, "Borislav Petkov" wrote:
> >
> > On Wed, Nov 12, 2014 at 07:14:21PM -0800, Andy Lutomirski wrote:
> > > On 11/11/2014 10:43 AM, Ross Zwisler wrote:
> > > >
On Tue, Mar 04, 2014 at 02:45:09PM +0100, Borislav Petkov wrote:
> On Mon, Mar 03, 2014 at 03:20:11PM +0100, Jiri Kosina wrote:
> > I encountered this again with -rc5.
> >
> > If there is anything I can do to help debug this, please let me know.
>
> I have a similar is
On Mon, Mar 03, 2014 at 03:20:11PM +0100, Jiri Kosina wrote:
> I encountered this again with -rc5.
>
> If there is anything I can do to help debug this, please let me know.
I have a similar issue where the screen blanks after the machine idle
timeout expires (not suspending the box - just leaving
On Thu, Feb 27, 2014 at 11:12:17PM +0100, Rafael J. Wysocki wrote:
> I won't be able to look at that before Monday I'm afraid (personal
> stuff).
No worries, sir, whenever. It can wait.
Thanks a lot!
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
_
On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
> My Lenovo IVB is like yours. But I tried on my SandyBridge desktop and
> there to BAR is at a completely different address. Same thing on my
> Haswell desktop system.
Hrrm, I'd like to see what Rafael finds out, whether what we're
On Wed, Feb 26, 2014 at 02:57:16PM +0100, Rafael J. Wysocki wrote:
> On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
> > This started happening this morning after booting -rc4+tip, let's
> > add *everybody* to CC :-)
>
> What about -rc4 without tip?
Can you please, pretty please, not top-post...
On Wed, Feb 26, 2014 at 10:47:05AM +0100, Stephane Eranian wrote:
> Hi,
>
> Ok, so I am getting the same error message as you.
> I checked my syslog now.
>
> I have my uncore_imc addr=0xfed1 (after masking)
>
> And I also have pnp 00:01 overlap
On Wed, Feb 26, 2014 at 07:56:58AM +0100, Stephane Eranian wrote:
> > Also IVB, model 58?
> >
> Yes.
Right, so it must be chipset-specific.
> > Dunno. What do you mean by "pm callbacks" exactly? I don't know that
> > code so I have to ask.
> >
> power management callbacks.
Ok, just as I thought.
On Tue, Feb 25, 2014 at 07:54:53PM +0100, Stephane Eranian wrote:
> I am on tip.git at cfbf8d4 Linux 3.14-rc4.
> and I don't see the problem (using Ubuntu Saucy).
Also IVB, model 58?
> Given what you commented out, it seems like you're saying
> something goes wrong with pci_get_device().
Probab
On Tue, Feb 25, 2014 at 05:33:13PM +0100, Stephane Eranian wrote:
> No, it's a T430s. What happens if you boot vanilla tip.git?
linus/master + tip/master -> fails
tip/master-> fails
All trees are from today, like an hour ago or so.
Doing what hpa suggested:
diff --git a/arch/x86
On Tue, Feb 25, 2014 at 05:14:01PM +0100, Stephane Eranian wrote:
> I am trying to understand your test case.
> Were you actually measure uncore_imc events at the time you suspended?
No test case, just the machine booting; look at the printk timestamps.
> I tried on my IvyBridge Lenovo and it wor
k but
the machine is responsive over the network.
And this doesn't happen on every resume but only sporadically.
And yep, -rc3 was fine.
On Mon, Feb 24, 2014 at 05:24:00PM +0100, Borislav Petkov wrote:
> This started happening this morning after booting -rc4+tip, let's
>
This started happening this morning after booting -rc4+tip, let's
add *everybody* to CC :-)
We have intel_uncore_init, snb_uncore_imc_init_box, uncore_pci_probe and
other goodies on the stack.
...
[0.488998] software IO TLB [mem 0xcac3-0xcec3] (64MB) mapped at
[8800cac3-8
On Fri, Feb 07, 2014 at 06:47:54PM +0200, Imre Deak wrote:
> Ok, not sure why the sdvo initialization fails, but the lockdep
> warning is probably fixed by the below patch. Could you try it and
> send a dmesg with drm.debug=0xe?
Yep, FWIW, the issue is fixed in -rc2, as it got cleared in the other
On Fri, Feb 07, 2014 at 05:32:06PM +0200, Imre Deak wrote:
> I just realized it's a different issue, since it's on the init path.
> Also we set the drm device as the parent for the sdvo i2c adapter as
> opposed to the dp i2c adapter where it's the connector device. So the
> above patch won't help i
On Fri, Feb 07, 2014 at 01:12:22PM +0200, Imre Deak wrote:
> On Fri, 2014-02-07 at 13:04 +0200, Jani Nikula wrote:
> > Imre, is this the same i2c_del_adapter issue you're looking at? Any
> > patches to try yet?
>
> It looks like the same issue yes. The following patch fixed it for me:
>
> http://
Hi guys,
so I'm seeing this on rc1 + tip during boot:
[0.558106] Linux agpgart interface v0.103
[0.558283] [drm] Initialized drm 1.1.0 20060810
[0.562280] [drm] Memory usable by graphics device = 2048M
[0.632301] i915 :00:02.0: irq 42 for MSI/MSI-X
[0.632401] [drm] Support
On Wed, Dec 18, 2013 at 09:59:22PM +0100, MPhil. Emanoil Kotsev wrote:
> I was able to solve the issue by removing some of the modules I had in
> xorg.conf. I noticed that it is not the cpu that is overheating, but
> rather the video/graphic card. The area around the "Dell" logo on the
> front of t
On Fri, Nov 22, 2013 at 05:09:59PM +0200, Ville Syrjälä wrote:
> IIRC this warning was there for me too on gcc 4.6, but it disappeared
> on gcc 4.7, which is why I decided not to send a patch for it.
A disappearing and reappearing warning happened to me recently too. I
attributed that to compiler
From: Borislav Petkov
Too many t's.
Cc: Daniel Vetter
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Borislav Petkov
---
drivers/gpu/drm/i915/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/Kcon
From: Borislav Petkov
gcc complains that:
drivers/gpu/drm/i915/i915_debugfs.c: In function ‘display_crc_ctl_write’:
drivers/gpu/drm/i915/i915_debugfs.c:2393:2: warning: ‘val’ may be used
uninitialized in this function [-Wuninitialized]
drivers/gpu/drm/i915/i915_debugfs.c:2350:6: note: ‘val
On Thu, Nov 21, 2013 at 05:10:30PM +0100, Richard Weinberger wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 6ed45a984230..1191aa47adc9 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
On Sun, Nov 17, 2013 at 05:45:18PM +0100, MPhil. Emanoil Kotsev wrote:
> How - new libraries - more exhaustive algorythms - higher cpu usage
> etc. Some of the things M$ is doing on purpose to force you upgrade
> your hardware every 2-3years
That would be too easy and machines would be dying left
On Sun, Nov 17, 2013 at 03:45:34PM +0100, MPhil. Emanoil Kotsev wrote:
> this is also true - which makes me sad as the notebook was working
> thgreat in e past 7y
Hmm, maybe it is heading slowly for the eternal hunting fields... :-)
> > What kind of upgrade exactly did you do to a laptop?
>
> I
On Sun, Nov 17, 2013 at 12:35:16PM +0100, MPhil. Emanoil Kotsev wrote:
> After doing all of this I was able to reproduce the issue by
> overloading the system with following simple steps:
> 1. start a compilation of something (ex. kernel)
> 2. run another process hungry application (flashplayer in
Some more suggestions, in addition to Daniel's:
On Wed, Nov 13, 2013 at 09:09:14PM +0100, Daniel Vetter wrote:
> > Nov 13 09:36:21 maistor kernel: [ 40.447271] [ cut
> > here ]
> > Nov 13 09:36:21 maistor kernel: [ 40.447311] WARNING: CPU: 1 PID: 4142 at
> > drivers/g
On Fri, Nov 01, 2013 at 10:18:49AM +0100, MPhil. Emanoil Kotsev wrote:
> On Thursday 31 October 2013 17:44:03 you wrote:
> > Please do not top-post.
>
> Sorry for top posting
No probs :). Btw, one more thing: when you reply, make sure you hit
reply-to-all so that CC list remains intact.
> I trie
Please do not top-post.
On Thu, Oct 31, 2013 at 04:52:54PM +0100, emanoil.kot...@fincom.at wrote:
> Hi, thanks for swift response.
> Yes, without those modules loaded it hangs as well. Perhaps I did
> not understand you well - do you mean unloaded or not
> compiled/installed, or even blacklisted.
Adding intel-gfx@ to CC.
On Thu, Oct 31, 2013 at 03:00:24PM +0100, emanoil.kot...@fincom.at wrote:
> Hi again, just noticed that it happens also without starring at
> youtube, but again in the drm
Right, I can see a bunch of #GPs happening at
drivers/gpu/drm/i915/intel_display.c:8292 check_crtc_
Let's CC some more people.
On Sun, Sep 29, 2013 at 10:17:34AM -0400, Wakko Warner wrote:
> Wakko Warner wrote:
> > Please keep me in CC.
> >
> > I receive a warning in drivers/gpu/drm/i915/intel_display.c:3869. This
> > happens when I'm on a console, the screen has gone into power save and I
> >
On Mon, Aug 05, 2013 at 03:23:53PM +0200, Johannes Stezenbach wrote:
> wrt to $Subject, I get this with 3.10.5:
>
> [4.342638] i915 :00:02.0: setting latency timer to 64
> [4.409045] INFO: trying to register non-static key.
> [4.409164] the code is fine but needs lockdep annotation
On Mon, Aug 05, 2013 at 01:06:35AM +0200, Daniel Vetter wrote:
> On Wed, Jul 31, 2013 at 6:22 PM, Borislav Petkov wrote:
> > Dudes,
> >
> > has anyone already reported this (happens on Linus of today +
> > tip/master):
>
> I think this
On Fri, Aug 02, 2013 at 10:11:27PM +0200, Josep Lladonosa wrote:
> "Before" means with previous kernels that worked with
>
> GRUB_CMDLINE_LINUX="acpi_osi=Linux acpi_backlight=vendor"
>
> I have not checked this issue with acpi_osi="!Windows 2012".
Hey Josep,
would you please not top-post when y
On Fri, Aug 02, 2013 at 09:16:03AM +0800, Aaron Lu wrote:
> Since the sysfs interface works on your system, I think your problem
> should be different. Can you please file a bug for this? I can provide
> you with a debug patch and then see what happened. Please attach
> acpidump when filing the bug
On Fri, Aug 02, 2013 at 02:00:42PM +0800, Aaron Lu wrote:
> Assume you have specified to use intel_backlight in xorg.conf
Right, I have:
Section "Device"
Option "Backlight" "intel_backlight"
Identifier "Card0"
Driver "intel"
BusID "PCI:0:2:0"
EndSe
On Thu, Aug 01, 2013 at 09:13:35AM +0800, Aaron Lu wrote:
> Can you please run acpi_listen and then press the Fn-Fx key, see if the
> events are correctly sent out?
Like this?
# acpi_listen
video/brightnessdown BRTDN 0087
video/brightnessup BRTUP 0086
video/brightnessdow
On Wed, Jul 31, 2013 at 06:22:52PM +0200, Borislav Petkov wrote:
> Dudes,
>
> has anyone already reported this (happens on Linus of today +
> tip/master):
Oh, one more thing: I can't control the backlight anymore on this x230
with the Fn-Fx keys and this is most probably relat
On Wed, Jul 31, 2013 at 11:16:52PM +0200, Rafael J. Wysocki wrote:
> Does reverting efaa14c help?
Nope.
But see my other reply to Aaron.
Thanks.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/in
Dudes,
has anyone already reported this (happens on Linus of today +
tip/master):
[0.608465] Linux agpgart interface v0.103
[0.608615] [drm] Initialized drm 1.1.0 20060810
[0.612050] [drm] Memory usable by graphics device = 2048M
[0.612212] i915 :00:02.0: setting latency timer
76 matches
Mail list logo
