On Wednesday, May 23, 2007 5:21:13 Linus Torvalds wrote:
On Wed, 23 May 2007, Jesse Barnes wrote:
After I sent my last message I realized the same thing... though I
occasionally hear people talk about removing it (I seriously doubt that
will ever happen). I don't even think there's a way
On Wednesday, May 23, 2007 5:20:46 Wayne Sherman wrote:
Ivan Kokshaysky wrote:
No, it won't help. The 1M range (ff50-ff5f) is more than enough.
Good catch, I didn't look close enough at the allocations of the devices
under the bridge.
The reason why the D-Link resource is not
On Wednesday, May 23, 2007 8:08:23 Jesse Barnes wrote:
On Wednesday, May 23, 2007 5:20:46 Wayne Sherman wrote:
Ivan Kokshaysky wrote:
No, it won't help. The 1M range (ff50-ff5f) is more than
enough.
Good catch, I didn't look close enough at the allocations of the devices
problems there.
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 Tuesday, May 22, 2007, Robert Hancock wrote:
> Jesse Barnes wrote:
> > On Tuesday, May 22, 2007, Robert Hancock wrote:
> >> Eww. I don't see where we disable the decode at all while we probe
> >> the BARs on the device. That seems like a bad thing, especially with
&
should
disable in the command word, which may be a problem (just disabled them
both every probe). I'll try again with more precise enable/disable
semantics.
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
On Tuesday, May 22, 2007, Benjamin Herrenschmidt wrote:
> On Tue, 2007-05-22 at 08:39 -0700, Jesse Barnes wrote:
> > The current code does its best to figure out what modes are available
> > and tries to pick a good one for each display. It sounds like you're
> > mainly conc
bus-resources' to your kernel at boot time, the code will
try to reallocate bridge space for you if needed.
Jesse
From [EMAIL PROTECTED] Tue May 15 15:39:53 2007
Received: from virtuous by box128.bluehost.com with local-bsmtp (Exim 4.63)
(envelope-from <[EMAIL PROTECTED]>)
id 1Ho5gr-0001rh-22
On Tuesday, May 22, 2007 3:05 pm Randy Dunlap wrote:
> On Tue, 22 May 2007 14:44:52 -0700 Jesse Barnes wrote:
> > When unloaded, the fbcon driver should unregister itself from the
> > VT subsystem using unbind_con_driver. This patch makes it use the
> > newly exporte
On Thursday, May 17, 2007, Antonino A. Daplas wrote:
> On Thu, 2007-05-17 at 15:32 -0700, Jesse Barnes wrote:
> > Randy just informed me that the patch limits are bigger now, so here
> > are the actual patches.
> >
> > This patch allows for proper console unre
On Thursday, May 17, 2007, Antonino A. Daplas wrote:
> On Thu, 2007-05-17 at 15:32 -0700, Jesse Barnes wrote:
> > Randy just informed me that the patch limits are bigger now, so here
> > are the actual patches.
> >
> > This patch allows for proper console unre
rying to address many of the
problems outlined in my initial mail too, we just have different opinions
about how exactly those problems should be solved. :)
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Mo
On Tuesday, May 22, 2007, Jon Smirl wrote:
> On 5/22/07, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > On Tuesday, May 22, 2007, Jon Smirl wrote:
> > > I've talked to an ATI engineer about VBIOS initialization. The chips
> > > may have different step
since
we'll need to do that ourselves for suspend resume and to fully support
various multihead configurations.
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/maj
On Monday, May 21, 2007, Wayne Sherman wrote:
> Jesse Barnes wrote:
> > There's a recent thread about PCI resource assignment (sounds like
> > your BIOS might be buggy btw, or you're somehow running out of space),
> > search for the title "PCI bridge range sizing bug"
and in many cases the BIOS doesn't. In
order to address that, we need to learn how to do it ourselves... So if
at all possible, I'd like to avoid baking any assumptions about VBIOS POST
into this design.
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel&qu
eally sure how much of a problem broken EDIDs will be. The X
server only has a few quirks for broken EDIDs now, nothing major afaict,
and apparently the FB layer already has some code for handling EDID
quirks, so I don't think that'll be our biggest problem. So far, it looks
like handling lapto
On Tuesday, May 22, 2007, Jon Smirl wrote:
On 5/22/07, Jesse Barnes [EMAIL PROTECTED] wrote:
On Tuesday, May 22, 2007, Jon Smirl wrote:
I've talked to an ATI engineer about VBIOS initialization. The chips
may have different steppings. They flash the right VBIOS that
matches the chip
different opinions
about how exactly those problems should be solved. :)
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
On Thursday, May 17, 2007, Antonino A. Daplas wrote:
On Thu, 2007-05-17 at 15:32 -0700, Jesse Barnes wrote:
Randy just informed me that the patch limits are bigger now, so here
are the actual patches.
This patch allows for proper console unregistration via the VT layer,
and updates
On Thursday, May 17, 2007, Antonino A. Daplas wrote:
On Thu, 2007-05-17 at 15:32 -0700, Jesse Barnes wrote:
Randy just informed me that the patch limits are bigger now, so here
are the actual patches.
This patch allows for proper console unregistration via the VT layer,
and updates
On Tuesday, May 22, 2007 3:05 pm Randy Dunlap wrote:
On Tue, 22 May 2007 14:44:52 -0700 Jesse Barnes wrote:
When unloaded, the fbcon driver should unregister itself from the
VT subsystem using unbind_con_driver. This patch makes it use the
newly exported function to do just
to reallocate bridge space for you if needed.
Jesse
From [EMAIL PROTECTED] Tue May 15 15:39:53 2007
Received: from virtuous by box128.bluehost.com with local-bsmtp (Exim 4.63)
(envelope-from [EMAIL PROTECTED])
id 1Ho5gr-0001rh-22
for [EMAIL PROTECTED]; Tue, 15 May 2007 16:40:21 -0600
X-Spam
On Tuesday, May 22, 2007, Benjamin Herrenschmidt wrote:
On Tue, 2007-05-22 at 08:39 -0700, Jesse Barnes wrote:
The current code does its best to figure out what modes are available
and tries to pick a good one for each display. It sounds like you're
mainly concerned with the actual mode
be a problem (just disabled them
both every probe). I'll try again with more precise enable/disable
semantics.
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
On Tuesday, May 22, 2007, Robert Hancock wrote:
Jesse Barnes wrote:
On Tuesday, May 22, 2007, Robert Hancock wrote:
Eww. I don't see where we disable the decode at all while we probe
the BARs on the device. That seems like a bad thing, especially with
the way we probe 64-bit BARs (do
don't think that'll be our biggest problem. So far, it looks
like handling laptop panels is a bit trickier (at least for Intel
chips)...
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
VBIOS POST
into this design.
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 Monday, May 21, 2007, Wayne Sherman wrote:
Jesse Barnes wrote:
There's a recent thread about PCI resource assignment (sounds like
your BIOS might be buggy btw, or you're somehow running out of space),
search for the title PCI bridge range sizing bug. You may need the
kernel
that ourselves for suspend resume and to fully support
various multihead configurations.
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
test patches along these lines.
If you can find out what resource it's colliding with, that might give you
a clue.
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/
why I'm posting this stuff in the first place! :) Again, if
you have specific problems with the proposed interfaces (problems that
would preclude your wishlist from being fully implementable), please let
me know (preferably with specifics).
Thanks,
Jesse
-
To unsubscribe from this list: send
e my machine ok.
For older kernels, I think you can pass 'all-generic-ide' on the boot
line to get the old IDE layer to drive the device.
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
On Monday, May 21, 2007, Jesse Barnes wrote:
> Yeah, I've got that data... just a sec while I make sure it's
> reproducable...
>
> Aha, I hadn't decoded the devfn before, looks like it's dying on an
> access to the graphics device (bus 0, slot 2, device 0):
>
> ...
> pc
be the graphics memory
range address, and 0xc00c is the correct value. But for some reason
it hangs on the second access.
It hangs here everytime.
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTEC
ing out exactly why it's hanging is a bit difficult.
Any ideas on what to try next? I'll see if I can get some more details
from our BIOS folks and do yet another pass over the documentation to see
if there's something I'm missing.
Thanks,
Jesse
-
To unsubscribe from this list: send the line &quo
On Monday, May 21, 2007, Jon Smirl wrote:
> On 5/21/07, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > On Monday, May 21, 2007, Jesse Barnes wrote:
> > > > There is more to fbdev than mode setting. It is also how non-x86
> > > > platforms achieve th
On Monday, May 21, 2007, Jesse Barnes wrote:
> > There is more to fbdev than mode setting. It is also how non-x86
> > platforms achieve their boot display. How will boot display be handled
> > with the your design? What about console display on non-x86 platforms?
> > Loadin
On Monday, May 21, 2007, Jon Smirl wrote:
> On 5/21/07, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > On Sunday, May 20, 2007, Jon Smirl wrote:
> > > On 5/20/07, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > > > With the interfaces implemented here,
I want it a system that allows
> multiseat for those that care to set it up.
Sure, and like I mentioned to Jon in another mail, a decent multiseat setup
is possible with these interfaces, albeit with a userlevel graphics daemon
to arbitrate what the CRTC->output mappings are and to c
for ICH3/4/5. Are there
> any errata affecting these ICHs?
I see it documented in the ICH5 datasheet, but that bit is marked reserved
in the ICH3 and ICH4 datasheets... Which docs are you looking at?
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
On Sunday, May 20, 2007, Jon Smirl wrote:
> On 5/20/07, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > With the interfaces implemented here, a userspace application can
> > create a multiseat environment either with a single graphics card with
> > multiple outputs or m
On Sunday, May 20, 2007, Jon Smirl wrote:
On 5/20/07, Jesse Barnes [EMAIL PROTECTED] wrote:
With the interfaces implemented here, a userspace application can
create a multiseat environment either with a single graphics card with
multiple outputs or multiple cards. It could do
in the ICH5 datasheet, but that bit is marked reserved
in the ICH3 and ICH4 datasheets... Which docs are you looking at?
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
graphics daemon
to arbitrate what the CRTC-output mappings are and to coordinate access
to the hw if needed.
So really, I think the interfaces posted here will do what you want. Maybe
you can take a closer look and make sure?
Thanks,
Jesse
-
To unsubscribe from this list: send the line unsubscribe
On Monday, May 21, 2007, Jon Smirl wrote:
On 5/21/07, Jesse Barnes [EMAIL PROTECTED] wrote:
On Sunday, May 20, 2007, Jon Smirl wrote:
On 5/20/07, Jesse Barnes [EMAIL PROTECTED] wrote:
With the interfaces implemented here, a userspace application can
create a multiseat environment
On Monday, May 21, 2007, Jesse Barnes wrote:
There is more to fbdev than mode setting. It is also how non-x86
platforms achieve their boot display. How will boot display be handled
with the your design? What about console display on non-x86 platforms?
Loading both fbdev and the new code
On Monday, May 21, 2007, Jon Smirl wrote:
On 5/21/07, Jesse Barnes [EMAIL PROTECTED] wrote:
On Monday, May 21, 2007, Jesse Barnes wrote:
There is more to fbdev than mode setting. It is also how non-x86
platforms achieve their boot display. How will boot display be
handled
next? I'll see if I can get some more details
from our BIOS folks and do yet another pass over the documentation to see
if there's something I'm missing.
Thanks,
Jesse
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
on the second access.
It hangs here everytime.
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 Monday, May 21, 2007, Jesse Barnes wrote:
Yeah, I've got that data... just a sec while I make sure it's
reproducable...
Aha, I hadn't decoded the devfn before, looks like it's dying on an
access to the graphics device (bus 0, slot 2, device 0):
...
pci_mmcfg_read: 0, 0, 0x10, 0x18, 4
pass 'all-generic-ide' on the boot
line to get the old IDE layer to drive the device.
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
place! :) Again, if
you have specific problems with the proposed interfaces (problems that
would preclude your wishlist from being fully implementable), please let
me know (preferably with specifics).
Thanks,
Jesse
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
.
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 Sunday, May 20, 2007, Jon Smirl wrote:
> On Thu, 17 May 2007 14:23:45 -0700, Jesse Barnes wrote:
> > In collaboration with the FB guys, we've been working on enhancing the
> > kernel's graphics subsystem in an attempt to bring some sanity to the
> > Linux graphics world an
On Sunday, May 20, 2007, Jon Smirl wrote:
On Thu, 17 May 2007 14:23:45 -0700, Jesse Barnes wrote:
In collaboration with the FB guys, we've been working on enhancing the
kernel's graphics subsystem in an attempt to bring some sanity to the
Linux graphics world and avoid the situation we have
In fact, I've received some comments pushing me towards moving the core
code (crtc, mode management) to drivers/video instead of DRM. That
might make sense, especially if we can just use/extend the FB layer's
mode tracking structures.
Thanks,
Jesse
-
To unsubscribe from this list: send
the core
code (crtc, mode management) to drivers/video instead of DRM. That
might make sense, especially if we can just use/extend the FB layer's
mode tracking structures.
Thanks,
Jesse
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Thursday, May 17, 2007, Luca Tettamanti wrote:
> Il Thu, May 17, 2007 at 03:37:45PM -0700, Jesse Barnes ha scritto:
> > This patch adds the core of the new DRM based modesetting system.
>
> A couple of comments on drm_fb since I'm somewhat familiar with fb code:
> >
On Thursday, May 17, 2007, Antonino A. Daplas wrote:
> On Thu, 2007-05-17 at 15:32 -0700, Jesse Barnes wrote:
> > Randy just informed me that the patch limits are bigger now, so here
> > are the actual patches.
> >
> > This patch allows for proper console unre
On Thursday, May 17, 2007 3:37 pm Jesse Barnes wrote:
> This patch adds the core of the new DRM based modesetting system. It
> creates several new structures in the DRM, the primary ones being the
> CRTC, which controls all aspects of your device's CRTC(s), output,
> which describes
On Thursday, May 17, 2007 3:40 pm Jesse Barnes wrote:
> This patch adds support for DRM modesetting to the Intel DRM driver
> and stubs out a simple FB driver to sit underneath. The code had to
> be refactored a bit, since current DRM drivers tend to be fully
> initialized by userspac
On Thursday, May 17, 2007 3:32 pm Jesse Barnes wrote:
> Randy just informed me that the patch limits are bigger now, so here
> are the actual patches.
>
> This patch allows for proper console unregistration via the VT layer,
> and updates the FB layer to use it. This makes debugg
unloading.
Antonio already checked it out (and suggested a tweak for the fbcon side)
so I think it's on its way already via the FB tree.
Jesse
--- linux-2.6.21-rc4/drivers/video/fbmem.c 2007-03-15 17:20:01.0
-0700
+++ linux-2.6.21-rc4-modesetting/drivers/video/fbmem.c 2007-04-26
le have for graphics on Linux so we can prioritize our work.
And of course, large chunks of this code came from X.Org's modesetting
and Intel driver code, but it should all be marked with the proper
copyrights and licenses if it wasn't written from scratch.
Comments, questions, suggest
on Linux so we can prioritize our work.
And of course, large chunks of this code came from X.Org's modesetting
and Intel driver code, but it should all be marked with the proper
copyrights and licenses if it wasn't written from scratch.
Comments, questions, suggestions?
Thanks,
Jesse
unloading.
Antonio already checked it out (and suggested a tweak for the fbcon side)
so I think it's on its way already via the FB tree.
Jesse
--- linux-2.6.21-rc4/drivers/video/fbmem.c 2007-03-15 17:20:01.0
-0700
+++ linux-2.6.21-rc4-modesetting/drivers/video/fbmem.c 2007-04-26
On Thursday, May 17, 2007 3:32 pm Jesse Barnes wrote:
Randy just informed me that the patch limits are bigger now, so here
are the actual patches.
This patch allows for proper console unregistration via the VT layer,
and updates the FB layer to use it. This makes debugging new console
On Thursday, May 17, 2007 3:37 pm Jesse Barnes wrote:
This patch adds the core of the new DRM based modesetting system. It
creates several new structures in the DRM, the primary ones being the
CRTC, which controls all aspects of your device's CRTC(s), output,
which describes and controls
On Thursday, May 17, 2007 3:40 pm Jesse Barnes wrote:
This patch adds support for DRM modesetting to the Intel DRM driver
and stubs out a simple FB driver to sit underneath. The code had to
be refactored a bit, since current DRM drivers tend to be fully
initialized by userspace via ioctls
On Thursday, May 17, 2007, Antonino A. Daplas wrote:
On Thu, 2007-05-17 at 15:32 -0700, Jesse Barnes wrote:
Randy just informed me that the patch limits are bigger now, so here
are the actual patches.
This patch allows for proper console unregistration via the VT layer,
and updates
On Thursday, May 17, 2007, Luca Tettamanti wrote:
Il Thu, May 17, 2007 at 03:37:45PM -0700, Jesse Barnes ha scritto:
This patch adds the core of the new DRM based modesetting system.
A couple of comments on drm_fb since I'm somewhat familiar with fb code:
new file mode 100644
index
oot
> option.
>
> > Ivan, want to add some way to force that allocation (something like
> > "pci=assign-bus-resources")
>
> Yes, hopefully I'll get something in a next couple of days.
Any update on this, Ivan? Maybe I missed your post, but I haven't seen
anythin
(something like
pci=assign-bus-resources)
Yes, hopefully I'll get something in a next couple of days.
Any update on this, Ivan? Maybe I missed your post, but I haven't seen
anything yet...
Thanks,
Jesse
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Wednesday, May 2, 2007 4:54 pm Jesse Barnes wrote:
> > What happens if you take out the chipset register detection, does
> > the MCFG table give you the same result? Wonder if they're doing
> > something funny with start/end bus values or something in their
> > table.
ght thing to do...
So aside from the comment issues Lee already pointed out, I think
Kamezawa-san's patch from
http://marc.info/?l=linux-mm=117758484122663=4 seems reasonable.
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
gh to clear the scanout buffer and output the
printk, though if there's a lot of rendering going on, the DRM driver
might have to be pretty smart about it.
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More ma
t, then by zone iirc, but has a
few other tweaks).
Another option would be to make this behavior automatic if both ZONE_DMA
and ZONE_NORMAL had pages. I initially wrote this stuff with the idea
that machines that really needed it would have all their memory in
ZONE_DMA, but obviously that's n
with the idea
that machines that really needed it would have all their memory in
ZONE_DMA, but obviously that's not the case, so some more smarts are
needed.
Jesse
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
driver
might have to be pretty smart about it.
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/
the comment issues Lee already pointed out, I think
Kamezawa-san's patch from
http://marc.info/?l=linux-mmm=117758484122663w=4 seems reasonable.
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
On Wednesday, May 2, 2007 4:54 pm Jesse Barnes wrote:
What happens if you take out the chipset register detection, does
the MCFG table give you the same result? Wonder if they're doing
something funny with start/end bus values or something in their
table. There's some code in my patch
On Wednesday, May 2, 2007 4:45 pm Robert Hancock wrote:
> Jesse Barnes wrote:
> > On Wednesday, May 2, 2007 7:34 am Robert Hancock wrote:
> >> Jesse Barnes wrote:
> >>> On Tuesday, May 01, 2007, Jesse Barnes wrote:
> >>>>> I'm testing it now on my
On Wednesday, May 2, 2007 7:34 am Robert Hancock wrote:
> Jesse Barnes wrote:
> > On Tuesday, May 01, 2007, Jesse Barnes wrote:
> >>> I'm testing it now on my 965...
> >>
> >> Bah... nevermind Robert, I see you're doing this already in
> >> pci_mmcf
On Wednesday, May 2, 2007 7:34 am Robert Hancock wrote:
Jesse Barnes wrote:
On Tuesday, May 01, 2007, Jesse Barnes wrote:
I'm testing it now on my 965...
Bah... nevermind Robert, I see you're doing this already in
pci_mmcfg_reject_broken. I'm about to reboot test now.
Ok, I've
On Wednesday, May 2, 2007 4:45 pm Robert Hancock wrote:
Jesse Barnes wrote:
On Wednesday, May 2, 2007 7:34 am Robert Hancock wrote:
Jesse Barnes wrote:
On Tuesday, May 01, 2007, Jesse Barnes wrote:
I'm testing it now on my 965...
Bah... nevermind Robert, I see you're doing
On Tuesday, May 01, 2007, Jesse Barnes wrote:
> > I'm testing it now on my 965...
>
> Bah... nevermind Robert, I see you're doing this already in
> pci_mmcfg_reject_broken. I'm about to reboot & test now.
Ok, I've tested a bit on my 965 (after re-adding my old patch to suppo
On Tuesday, May 01, 2007, Jesse Barnes wrote:
> On Monday, April 30, 2007, Olivier Galibert wrote:
> > On Sun, Apr 29, 2007 at 08:14:37PM -0600, Robert Hancock wrote:
> > > -Validate that the area is reserved even if we read it from the
> > > chipset directly
eturns a
failure, there's no way MCFG space can work, so we should disable it
unconditionally in that case (even if ACPI says "trust me, when have I
ever lied to you?").
I'm testing it now on my 965...
Thanks,
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel&quo
nfig-shared.c to check against the register
values like Olivier mentioned?
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/
he pata controller interface and both my hd
> and od are on the second
> channel of the pata.
>
> So can I configure out the old ide and just have ata_piix
> automatically control them both in
> 2.6.21?
Yeah, I think that'll work. You could try an FC7 .config file if that's
g as you make
sure you use the libata based drivers for everything. If you're
running Fedora I think the rawhide kernels are configured this way, but
the fc6 era kernels aren't.
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
t from the documentation.
Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]>
Thanks,
Jesse
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 84c3bd0..49b1ea3 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-pa
> table without questions.
We need to look at the register, but we may not want to use it if it looks
too confused. If it doesn't agree with what we see in ACPI, we likely
have a problem due to the issues Robert outlined in his other mail.
Jesse
-
To unsubscribe from this list: send the l
it if it looks
too confused. If it doesn't agree with what we see in ACPI, we likely
have a problem due to the issues Robert outlined in his other mail.
Jesse
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
-off-by: Jesse Barnes [EMAIL PROTECTED]
Thanks,
Jesse
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 84c3bd0..49b1ea3 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -722,14 +722,6 @@ and is between 256
drivers for everything. If you're
running Fedora I think the rawhide kernels are configured this way, but
the fc6 era kernels aren't.
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
interface and both my hd
and od are on the second
channel of the pata.
So can I configure out the old ide and just have ata_piix
automatically control them both in
2.6.21?
Yeah, I think that'll work. You could try an FC7 .config file if that's
easier.
Jesse
-
To unsubscribe from this list: send
values like Olivier mentioned?
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/
if ACPI says trust me, when have I
ever lied to you?).
I'm testing it now on my 965...
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
801 - 900 of 1411 matches
Mail list logo
