mplicated, but you'll need docs for it. Charlie
Huang ought to be able to get you the NDA docs that should have the
info you need.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
v3: use a function pointer (Chris)
drop gen2 bits (Daniel)
v4: call e820_sanitize_map after adding the region
v5: fixup comments (Peter)
simplify loop (Chris)
Acked-by: Ingo Molnar
Signed-off-by: Jesse Barnes
---
arch/x86/kernel/early-quirks
For use by userspace (at some point in the future) and other kernel code.
v2: move PCI IDs to uabi (Chris)
move PCI IDs to drm/ (Dave)
v3: fixup Quanta detection - needs to come first (Daniel)
v4: fix up PCI match structure init for easier use by userspace (Chris)
Signed-off-by: Jesse Barnes
or finding stolen
space.
But I think these two are ready as-is. How should we merge them? Just
through the i915 tree since the first one touches our headers? that and
there probably won't be conflicts on the early-quirks file; that's not
touch too often...
Thanks,
Jesse
--
To unsubscribe
On Fri, 26 Jul 2013 09:58:45 -0700
"H. Peter Anvin" wrote:
> On 07/25/2013 09:37 AM, Jesse Barnes wrote:
> > Systems with Intel graphics controllers set aside memory exclusively for
> > + /*
> > +* Almost universally we can find the Graphics Base of Stolen M
uot;firmware tables don't show
> all devices" issue before.
>
> The only odd thing about this one is how the quirk in question uses
> "e820_add_region()" instead of just adding things to the MMIO list.
> And I think that's actually likely a mistake.
>
&g
On Thu, 25 Jul 2013 20:31:27 -0700
"H. Peter Anvin" wrote:
> On 07/25/2013 07:14 PM, Jesse Barnes wrote:
> > To clarify: it'll either be marked reserved or not listed at all in e820,
> > which is why I did this early, before any other e820 stuff like the "
On Thu, 25 Jul 2013 23:59:25 +0100
Chris Wilson wrote:
> Hmm, interesting licence block in i915_pciids.h - our claim to
> grant licence but TG disclaims liability.
Oops my manual search & replace obviously failed. Will fix up.
--
Jesse Barnes, Intel Open Source Technology Ce
Well, it's ok if the boot loader writes to this memory, the worst
that'll happen is you'll see garbage on the screen. If the boot loader
tries to do MMIO mapping on top it'll get into trouble... but why would
it do that?
Jesse
On Thu, 25 Jul 2013 15:42:25 -0700
"H. P
On Thu, 25 Jul 2013 22:05:51 +0200
Ingo Molnar wrote:
>
> * Jesse Barnes wrote:
>
> > Patch 2/2 has the description, but suffice it to say I'm
> > not really pleased with this, though it does solve a
> > problem we have. On some machines, we get MMIO spa
a function pointer (Chris)
drop gen2 bits (Daniel)
Signed-off-by: Jesse Barnes
---
arch/x86/kernel/early-quirks.c | 158 +++
drivers/gpu/drm/i915/i915_reg.h | 15
include/drm/i915_drm.h | 32
3 files changed, 190 inserti
ant code in the i915 driver
at least.
Any comments? I assume no one likes this, but maybe it's just another
early quirk we'll have to live with...
Thanks,
Jesse
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vge
For use by userspace (at some point in the future) and other kernel code.
v2: move PCI IDs to uabi (Chris)
move PCI IDs to drm/ (Dave)
v3: fixup Quanta detection - needs to come first (Daniel)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 164
://bugs.freedesktop.org/show_bug.cgi?id=54089
> References: https://bugzilla.kernel.org/show_bug.cgi?id=58971
> Signed-off-by: Konstantin Khlebnikov
> Cc: Daniel Vetter
> Cc: Chris Wilson
> Cc: Jesse Barnes
> ---
My hero!
So the later init change didn't work?
Eithe
On Tue, 16 Jul 2013 22:43:49 +0200
Daniel Vetter wrote:
> On Tue, Jul 16, 2013 at 01:19:25PM -0700, Jesse Barnes wrote:
> > On Tue, 16 Jul 2013 10:06:54 -0700
> > Jesse Barnes wrote:
> >
> > > On Tue, 16 Jul 2013 11:34:25 +0400
> > > Konstantin Khlebnikov
On Tue, 16 Jul 2013 10:06:54 -0700
Jesse Barnes wrote:
> On Tue, 16 Jul 2013 11:34:25 +0400
> Konstantin Khlebnikov wrote:
> > I've tested that patch and it really works for me. If you want change
> > something for other hardware or
> > extend range where forcew
er than trying
to forcewake around everywhere we need it.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d
index 12ea1a9..9152cba 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915
On Sat, 22 Jun 2013 13:04:09 -0700
Guenter Roeck wrote:
> On Sat, Jun 22, 2013 at 12:16:46PM -0700, Jesse Barnes wrote:
> > On Fri, 21 Jun 2013 23:58:08 -0700
> > Guenter Roeck wrote:
> >
> > > Hi all,
> > >
> > > after upgrading one
On Tue, 25 Jun 2013 20:51:27 +
Shuah Khan wrote:
> On 06/25/2013 02:06 PM, Jesse Barnes wrote:
> > On Tue, 25 Jun 2013 19:59:28 +
> > Shuah Khan wrote:
> >
> >> On 06/25/2013 01:52 PM, Jesse Barnes wrote:
> >>> On Tue, 25 Jun 2013
just be the default on x86? Or do we allocate
ROM space to address some other platform where we need it and the BIOS
doesn't do it for the devices we care about?
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel
On Tue, 25 Jun 2013 19:59:28 +
Shuah Khan wrote:
> On 06/25/2013 01:52 PM, Jesse Barnes wrote:
> > On Tue, 25 Jun 2013 21:37:37 +0200
> > Daniel Vetter wrote:
> >
>
> >>
> >> Adding more lists to cc + Jesse since he's the guilty one
some will probably
> miss 3.11), but the refcounting part is all in -next.
>
> So I think the first step would be to test latest linux-next (or the
> drm-intel-nightly branch from
> http://cgit.freedesktop.org/~danvet/drm-intel/ if you just want the
> drm parts on top of a recent -rc). A
se I can do besides using a special kernel with the backed out
> commit ? Is it possible that others have the same problem ?
Ouch, so a BIOS that uses the other forcewake mechanism seems to have
escaped. Is there a newer one available for your system? I'm hoping
it'll fix the issu
On Fri, Jun 21, 2013 at 8:22 AM, Randy Dunlap wrote:
> On 06/21/13 01:17, Stephen Rothwell wrote:
>> Hi all,
>>
>> Happy solstice!
>>
>> Changes since 20130620:
>>
>
> when CONFIG_INET is not enabled:
>
> CC net/openvswitch/flow.o
> In file included from net/openvswitch/flow.c:43:0:
> inclu
On 06/06/2013 03:09 PM, Dave Jones wrote:
> On Thu, Jun 06, 2013 at 02:59:44PM -0500, Jesse Larrew wrote:
>
> > > pr_debug("%s: xmit %p %pM\n", vi->dev->name, skb, dest);
> > > +if (vi->mergeable_rx_bufs)
> > > +
r
> s/g */
> +
> #define VIRTIO_NET_S_LINK_UP 1 /* Link is up */
> #define VIRTIO_NET_S_ANNOUNCE2 /* Announcement is needed */
>
> @@ -70,7 +72,9 @@ struct virtio_net_config {
> __u16 max_virtqueue_pairs;
> } __attribute__((packed));
>
>
On Sun, 19 May 2013, Or Gerlitz wrote:
> On Sun, May 19, 2013 at 1:25 PM, Eliezer Tamir
> wrote:
> > This is an updated version of the code we posted on February.
>
> Last time you've placed a copy of the patchset in the rfc branch of
> git://github.com/jbrandeb/lls.git - can you repost there V2
On Thu, 28 Mar 2013 05:04:26 -0700
"Luis R. Rodriguez" wrote:
> The new commit by Jesse that extended the fb_info with a skip_vt_switch
> element is the simplest example of a data structure expansion. We'd backport
> this by adding a static inline to compat so that n
d to the nvidia chip instead of the i915 one,
the i915 driver may get confused and panic.
For debugging, you could modify the modeset_init function in i915_dma.c
and make it return early with an error. You could use that to narrow
down which part of init was failing.
--
Jesse Barnes, Intel Open
r for display.
I don't know about the ACPI change mentioned, but ACPI is involved in
dual-GPU configurations. Maybe the change affected the default
behavior and pointed more functions at the nVidia device rather than
the Intel?
--
Jesse Barnes, Intel Open Source Technology Ce
If PM_SLEEP is disabled, we need stub versions of these functions.
v2: fix up struct device forward decl.
Signed-off-by: Jesse Barnes
---
include/linux/pm.h |9 +
1 file changed, 9 insertions(+)
diff --git a/include/linux/pm.h b/include/linux/pm.h
index 98310eb..e5da2f3 100644
that work isn't ready yet either I've dropped the offending
> patches.
I sent a patch yesterday for this. I'll bounce it over again.
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Mon, 04 Feb 2013 21:26:26 +0100
"Rafael J. Wysocki" wrote:
> On Monday, February 04, 2013 01:37:20 PM Jesse Barnes wrote:
> > KMS drivers can potentially restore the display configuration without
> > userspace help. Such drivers can can call a new funciton,
> &
flag to indicate we don't need to VT switch
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 28 +---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_display.c | 25 +
drivers/gpu/drm
Use the new PM routines to indicate whether we need to VT switch at suspend
and resume time. When a new driver is bound, set its flag accordingly,
and when unbound, remove it from the PM's console tracking list.
Signed-off-by: Jesse Barnes
---
drivers/video/fbmem.c |7 +++
in
o the original VT on resume, but rather leave things
alone for a nicer looking suspend and resume sequence.
v2: make a function so we can handle multiple drivers (Alan)
v3: use a list to track device requests (Rafael)
Signed-off-by: Jesse Barnes
---
include/linux/pm.h |4 ++
kernel/power/cons
other problems. And I found a bug in mine last night.
So I think I need a separate count of drivers that need the switch, and
ones that don't. Then if either no driver has registered or if the
need_switch count is nonzero, we'll do the switch. Otherwise, if the
dont_need_switch is nonzer
if this looks ok I can
do that.
Thanks,
Jesse
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
o the original VT on resume, but rather leave things
alone for a nicer looking suspend and resume sequence.
v2: make a function so we can handle multiple drivers (Alan)
Signed-off-by: Jesse Barnes
---
include/linux/pm.h |2 ++
kernel/power/console.c |
On Fri, 11 Jan 2013 14:39:04 -0800
tip-bot for Jesse Barnes wrote:
> Commit-ID: a9acc5365dbda29f7be2884efb63771dc24bd815
> Gitweb: http://git.kernel.org/tip/a9acc5365dbda29f7be2884efb63771dc24bd815
> Author: Jesse Barnes
> AuthorDate: Wed, 14 Nov 2012 20:43:31 +
>
Correct a typo in the comment explaining hypercalls.
Signed-off-by: Jesse Larrew
---
arch/x86/include/asm/kvm_para.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
index eb3e9d8..f49c16d 100644
--- a/arch
appropriately.
Signed-off-by: Jesse Larrew
---
arch/x86/kvm/vmx.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index f858159..8b37f5f 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -4682,8 +4682,7 @@ static int
On Fri, Nov 16, 2012 at 12:35 AM, Shan Wei wrote:
> Shan Wei said, at 2012/11/13 9:52:
>> From: Shan Wei
>>
>> just use more faster this_cpu_ptr instead of per_cpu_ptr(p,
>> smp_processor_id());
>>
>>
>> Signed-off-by: Shan Wei
>> Reviewed
On Thu, 15 Nov 2012 10:47:11 -0200
Henrique de Moraes Holschuh wrote:
> On Wed, 14 Nov 2012, Jesse Barnes wrote:
> > + unsigned long bad_ranges[] = {
> > + 0x2005,
> > + 0x2011,
> > +
On Thu, 15 Nov 2012 10:47:11 -0200
Henrique de Moraes Holschuh wrote:
> On Wed, 14 Nov 2012, Jesse Barnes wrote:
> > + unsigned long bad_ranges[] = {
> > + 0x2005,
> > + 0x2011,
> > +
On Wed, 14 Nov 2012 20:43:31 +
Jesse Barnes wrote:
> SNB graphics devices have a bug that prevent them from accessing certain
> memory ranges, namely anything below 1M and in the pages listed in the
> table. So reserve those at boot if set detect a SNB gfx device on the
> CPU
On Wed, 14 Nov 2012 21:19:05 +
Alan Cox wrote:
> On Wed, 14 Nov 2012 20:43:31 +
> Jesse Barnes wrote:
>
> > SNB graphics devices have a bug that prevent them from accessing certain
> > memory ranges, namely anything below 1M and in the pages listed in the
> &g
allocator awhile
back, but rather than reserving pages up front, it leaked them at
allocation time.
Signed-off-by: Jesse Barnes
---
arch/x86/kernel/setup.c | 72 +++
1 file changed, 72 insertions(+)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel
d the framebuffer layer to let kms get at it.
yay console layer... ok I'll check it out.
Overall it's probably worth some grotting around in the console layer.
Avoiding a VT switch makes suspend/resume a lot nicer looking. No more
blinking cursor in the corner and ugly flickering.
Jess
On 11/2/2012 4:38 PM, Rafael J. Wysocki wrote:
On Friday, November 02, 2012 04:29:37 PM Jesse Barnes wrote:
On Fri, 02 Nov 2012 22:51:07 +0100
"Rafael J. Wysocki" wrote:
On Friday, November 02, 2012 02:43:39 PM Jesse Barnes wrote:
I've lightly tested this with X and it defi
On 11/2/2012 4:43 PM, Alan Cox wrote:
On Fri, 2 Nov 2012 14:43:40 -0700
Jesse Barnes wrote:
KMS drivers can potentially restore the display configuration without
userspace help. Such drivers can set a new global, pm_vt_switch, to
false if they support this feature. In that case, the PM
On Fri, 02 Nov 2012 22:51:07 +0100
"Rafael J. Wysocki" wrote:
> On Friday, November 02, 2012 02:43:39 PM Jesse Barnes wrote:
> > I've lightly tested this with X and it definitely makes my
> > suspend/resume sequence a bit prettier. It should speed things up
>
VT on resume, but rather leave things alone for a nicer looking
suspend and resume sequence.
Signed-off-by: Jesse Barnes
---
include/linux/pm.h |3 +++
kernel/power/console.c |7 +++
2 files changed, 10 insertions(+)
diff --git a/include/linux/pm.h b/include/linux/pm.h
index 00
to be more defensive about the
resume configuration in case the BIOS did something weird, but overall I
think we should be able to do this one way or another.
Thanks,
Jesse
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kerne
: Jesse Barnes
---
drivers/gpu/drm/i915/i915_dma.c |3 +++
drivers/gpu/drm/i915/i915_drv.c | 28 +---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_display.c | 25 +
4 files changed, 54 insertions(+), 3
On Thu, Nov 1, 2012 at 7:33 AM, Christoph Lameter wrote:
> On Thu, 1 Nov 2012, Shan Wei wrote:
>
>> But for different field in same per-cpu variable, how to guarantee n_missed
>> and n_hit are from same cpu?
>> this_cpu_read(dp->stats_percpu->n_missed);
>> [processor changed]
>> this_cpu_read(dp->
bout 11:08:16 -, Dirk Gouders wrote:
> >>>> Borislav Petkov writes:
> >>>>
> >>>>> On Fri, Jul 27, 2012 at 11:24:53AM +0200, Dirk Gouders wrote:
> >>>>>> Cong Wang writes:
> >>>>>>
> >>>>>
>From 5dfd547532fca61462dc17fd0bb8e533002c4bc5 Mon Sep 17 00:00:00 2001
From: Jesse Larrew
Date: Thu, 7 Jun 2012 16:04:34 -0500
arch_update_cpu_topology() should only return 1 when the topology has
actually changed, and should return 0 otherwise.
This patch fixes a potential bug wh
On Thursday, February 21, 2008 5:28 pm Linus Torvalds wrote:
> On Thu, 21 Feb 2008, Jesse Barnes wrote:
> > So the advantage of the kernel suspend/resume hooks for the DRM layer is
> > that the kernel video drivers can do full state save/restore (which X
> > usually doesn&#
On Thursday, February 21, 2008 5:13 pm Jesse Barnes wrote:
> On Thursday, February 21, 2008 4:54 pm Rafael J. Wysocki wrote:
> > On Friday, 22 of February 2008, Linus Torvalds wrote:
> > > On Fri, 22 Feb 2008, Rafael J. Wysocki wrote:
> > > > - if (s
On Thursday, February 21, 2008 4:52 pm Jeff Chua wrote:
> On Fri, Feb 22, 2008 at 8:46 AM, Jesse Barnes <[EMAIL PROTECTED]>
wrote:
> > Your s2ram script is doing your STD also? Seems counterintuitive.
> > Anyway, some machines also re-POST the GPU on resume from S3; may
ks like I forgot to reboot between tests (just rmmod'd &
modprobed i915), your patch actually does work.
However, making new PM event messages might be a good thing anyway, assuming
Linus takes it for 2.6.25, since it should make the migration to ->hibernate
callbacks easier.
Jesse
On Thursday, February 21, 2008 4:42 pm Jeff Chua wrote:
> On Fri, Feb 22, 2008 at 8:23 AM, Jesse Barnes <[EMAIL PROTECTED]>
wrote:
> > Your system (either your distro suspend/resume scripts or your platform)
> > must be running the video BIOS at resume time, otherwise it wo
On Thursday, February 21, 2008 4:20 pm Jeff Chua wrote:
> On Fri, Feb 22, 2008 at 5:02 AM, Jesse Barnes <[EMAIL PROTECTED]>
wrote:
> > On Thursday, February 21, 2008 11:43 am Romano Giannetti wrote:
> > > > > Let's try to narrow it down to what the inter
point, the known workarounds to the hang at suspend time are to
remove the device power down call or to boot with 'no_console_suspend'.
The 'screen turns green' problem is fixed by the extra 'inb' added in the
patch below (at least for me).
Jesse
diff --git a/d
this communication in error, please immediately notify
> the sender by reply e-mail and destroy this message. Thank you for your
> cooperation.
Really? This contains confidential information? I'd better notify you and
destroy this message now... :)
Jesse
--
To unsubscribe from this
On Thursday, February 21, 2008 8:27 am Rafael J. Wysocki wrote:
> On Thursday, 21 of February 2008, Jeff Chua wrote:
> > On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes <[EMAIL PROTECTED]>
wrote:
> > > On Wednesday, February 20, 2008 4:35 pm Jeff Chua wrote:
> > >
On Wednesday, February 20, 2008 5:19 pm Jeff Chua wrote:
> On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes <[EMAIL PROTECTED]>
wrote:
> > Oops, maybe this should just be pci_choose_state instead.
> > And this change should just be reverted (leave it as PCI_D0).
>
> driv
On Wednesday, February 20, 2008 4:35 pm Jeff Chua wrote:
> On Thu, Feb 21, 2008 at 5:37 AM, Jesse Barnes <[EMAIL PROTECTED]>
wrote:
> > Ok, can you give this patch a try with the 'platform' method? It should
> > at least tell us what ACPI would like the device to
hen we have separate callbacks for
> hibernation.
Ok, thanks.
Jesse
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Wednesday, February 20, 2008 3:03 pm Jesse Barnes wrote:
> On Wednesday, February 20, 2008 2:32 pm Jesse Barnes wrote:
> > On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
> > > On Feb 21, 2008 2:53 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > > &g
On Wednesday, February 20, 2008 2:32 pm Jesse Barnes wrote:
> On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
> > On Feb 21, 2008 2:53 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > > > So, next I'll try "shutdown" to see if it work. I was usin
On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
> On Feb 21, 2008 2:53 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > > So, next I'll try "shutdown" to see if it work. I was using "platform".
> >
> > Ok, that would be good to try.
&
On Wednesday, February 20, 2008 1:13 pm Linus Torvalds wrote:
> On Wed, 20 Feb 2008, Jesse Barnes wrote:
> > The current callback system looks like this (according to Rafael and the
> > last time I looked):
> > ->suspend(PMSG_FREEZE)
> > ->resume()
> >
On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
> On Feb 21, 2008 2:53 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > > So, next I'll try "shutdown" to see if it work. I was using "platform".
> >
> > Ok, that would be good to try.
&
SUSPEND). So in the short
term it would be nice to at least get the target state exported.
And in the long term we could have:
->suspend()
*enter S3*
->resume()
or:
->hibernate()
*kexec to another kernel to save image*
*power off*
->return_from_hibernate() (or somesuch)
Je
On Wednesday, February 20, 2008 11:18 am Jesse Barnes wrote:
> On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
> > On Feb 21, 2008 2:53 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > > > So, next I'll try "shutdown" to see if it work. I was usin
On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
> On Feb 21, 2008 2:53 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > > So, next I'll try "shutdown" to see if it work. I was using "platform".
> >
> > Ok, that would be good to try.
&
l. The intel_reg_dumper
> > tool
>
> Attached are the two dumps from console. One prior to suspend, and one
> after resume.
Looks like the AR registers are hosed, which is what I thought I fixed... Can
you attach your i915_drv.c file just so I can sanity check it?
Thanks,
Jesse
--
nto D3hot makes the ACPI code that
>actually does the shutoff unhappy. Probably because it wants to access
>the device, and ends up not ever getting the replies it wants, since
>the hardware has been turned off.
Sounds like a good theory... now if we could just use set_powe
if that also turns your screen green?
Also, getting a GPU register dump would be helpful. The intel_reg_dumper tool
is built as part of the xf86-video-driver build
(git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel), can you
pull that down and try it out?
Thanks,
Jesse
--
To unsubs
On Tuesday, February 19, 2008 6:28 pm Linus Torvalds wrote:
> On Tue, 19 Feb 2008, Jesse Barnes wrote:
> > I found the same poweroff issue on my T61. It turned out to be related
> > to the C state code disabling interrupts when it shouldn't iirc. Booting
> > with '
I found the same poweroff issue on my T61. It turned out to be related to the
C state code disabling interrupts when it shouldn't iirc. Booting
with 'idle=poll' seems to work around the problem.
The "green screen" problem should be fixed (see the DRM git tree for det
ed though ...
We're doing something similar in the DRM these days... We need big chunks of
memory to be pinned so that the GPU can operate on them, but when the
operation completes we can allow them to be swappable again. I think with
the current implementation, allocations are always pin
ke sure you have i915 loaded before you suspend if you want your text
console to come back.
Jesse
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
>
> > > I have Lenovo ThinkPad T61.
> >
> > If you have CONFIG_CPU_IDLE set, please try to boot with idle=poll and
> > see if that helps.
>
> Just sent this patch to fix a regression in acpi processor_idle.c on
> another thread. Can you try the patch below
allocating more in case of malloc or char *foo[0].)
I think he was saying that the warning was legit. Anyway, my gcc isn't smart
enough to emit warnings like this, maybe it's time to ugprade...
Jesse
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
A_GR_DATA, 0x18);
>
> which looks legit, since saveGR is
>
> u8 saveGR[24];
>
> It has been introduced by commit
> ba8bbcf6ff4650712f64c0ef61139c73898e2165, which seems to be you Jesse.
Just a silly off by one, don't know why I didn't catch it earlier. I'll push
the
A_GR_DATA, 0x18);
>
> which looks legit, since saveGR is
>
> u8 saveGR[24];
>
> It has been introduced by commit
> ba8bbcf6ff4650712f64c0ef61139c73898e2165, which seems to be you Jesse.
I'll take a look, thanks.
Jesse
--
To unsubscribe from this list: send the line "unsu
4249 that may work for
you (this one in particular is the one I'm worried may break 855).
Thanks,
Jesse
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
en system memory").
For legacy memory, we actually have /sys/bus/pci//legacy_mem
(though ia64 may be the only supported platform). It's actually
required on some arches due to the way this space is allocated across
the system.
Jesse
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
t commit itself needed a couple of follow on bug fixes, but the point
is that you could download 7.3.20 from sourceforge (which would compile
on your kernel) and compare the performance with it if you were
interested in a further experiment.
Jesse
--
To unsubscribe from this list: send the line &qu
we need a new platform hook to disable SMM/NMI/etc.
around PCI probing)
What else was there? What reason do we have to think that things are so
disastrous?
So I really prefer willy's approach to Arjan's alternative...
Jesse
--
To unsubscribe from this list: send the line "un
t the PCIe devices only.
> If that's the case then the original changelog entry "Move PCI-Express
> device IDs over to e1000e" is misleading as it's not only PCI-Express
> devices...
Unfortunate bit of confusion over terminology.
> Hmmm. Or does which dri
cpu for x86_32, and move mtrr_bp_init early
>
> compiled test only, need someone test it
I like this approach too. So as long as the E820 modification method works
(i.e. we have some testers, maybe Justin can give it a try), you can add
Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]>
or
Acked
sage
count = 1
Where 2.6.24-rc5 e1000 is okay still. Seems like maybe we are still
missing a netif_rx_complete or a napi_disable somewhere.
I don't think this problem has anything to do with the irq_sem right
now. Something is still badly broken. I am just using the interface
regularly (no heavy
it looks good.
>
> I think it should be enabled on AMD too though. If the reordering breaks
> it then blacklisting won't help anyways.
>
> -Andi
>
> [1] but I checked the known errata and there was nothing related to MTRR.
Ah, ok, that explains your reticence earlier. Tha
enable it for AMD as well, and it would also be
good to track down the one failure you found... I don't *think* the
re-ordering of MTRR initialization should affect AMDs anymore than it does
Intel, but someone familiar with the boot code would have to do a quick audit
to be sure.
Jesse
--
Andrew Morton wrote:
> On Thu, 17 Jan 2008 11:22:19 -0800 "Pallipadi, Venkatesh"
> <[EMAIL PROTECTED]> wrote:
>
>>
>> The problem is
modprobe:2584 conflicting cache attribute 5000-50001000
uncached<->default
>>
>> Some address range here is being mapped with conflicting types.
>>
David Miller wrote:
> From: "Brandeburg, Jesse" <[EMAIL PROTECTED]>
> Date: Tue, 15 Jan 2008 13:53:43 -0800
>
>> The tx code has an "early exit" that tries to limit the amount of tx
>> packets handled in a single poll loop and requires napi or inte
201 - 300 of 756 matches
Mail list logo
