On 30/03/2005 10:45:55 linux-kernel-owner wrote:
>> The solution is fairly well known. Rather than treating the zillions
of
>> disk seeks during the boot process as random unconnected events, you
>
>Heh, we actually tried that at SuSE and yes, eliminating seeks helps a
>bit, but no, it is not ma
Hi!
> > > I'm really not trolling, but I suspect if we made the boot process less
> > > verbose, people would start to wonder more about why Linux takes so much
> > > longer than XP to boot.
> >
> > By the way, Microsoft seems to be claiming that boot time will be reduced
> > to the half
> > wit
On Wed, Mar 23, 2005 at 05:49:47PM +0100, Giuseppe Bilotta wrote:
> > > What are the cons of using "all of" the RAM at boot time to
> > > cache the boot disk?
>
> Dave Jones wrote:
> > It's memory that's otherwise unused. Once you start using the system
> > anything cached will get reclaime
> > What are the cons of using "all of" the RAM at boot time to
> > cache the boot disk?
Dave Jones wrote:
> It's memory that's otherwise unused. Once you start using the system
> anything cached will get reclaimed as its needed.
So there is no substantial loss? IOW, it would suffice to have
al
On Wed, Mar 23, 2005 at 09:21:22AM +0100, Giuseppe Bilotta wrote:
> Dave Jones wrote:
> > Some of the folks on our desktop team have been doing a bunch of
> > experiments
> > at getting boot times down, including laying out the blocks in a more
> > optimal manner, allowing /sbin/readahead to
El Tue, 22 Mar 2005 20:13:15 -0500,
Dave Jones <[EMAIL PROTECTED]> escribió:
> With something like this, and some additional bookkeeping to keep track of
> which files we open in the first few minutes of uptime, we could periodically
> reorganise the layout back to an optimal state.
That wouldn't
Lee Revell wrote:
> Yup, many people on this list seem unaware but read the XP white papers,
> then try booting it side by side with Linux. They put some serious,
> serious engineering into that problem and came out with a big win.
> Screw Longhorn, we need improve by 50% to catch up to what they
Dave Jones wrote:
> Some of the folks on our desktop team have been doing a bunch of experiments
> at getting boot times down, including laying out the blocks in a more
> optimal manner, allowing /sbin/readahead to slurp the data off the disk
> in one big chunk, and run almost entirely from cache.
Dave Jones <[EMAIL PROTECTED]> wrote:
>
> This old mail: http://marc.free.net.ph/message/20040304.030616.59761bf3.html
> references a 'move block' ioctl, which is probably the hardest part of the
> problem,
> though I didn't find the code referenced in that mail. Andrew ?
That would be http://
On Tue, Mar 22, 2005 at 07:53:37PM -0500, Lee Revell wrote:
> The solution is fairly well known. Rather than treating the zillions of
> disk seeks during the boot process as random unconnected events, you
> analyze the I/O done during the boot process, then lay out those disk
> blocks optimal
On Wed, 2005-03-23 at 01:37 +0100, Diego Calleja wrote:
> El Mon, 14 Mar 2005 14:07:53 -0500,
> Lee Revell <[EMAIL PROTECTED]> escribió:
>
> > I'm really not trolling, but I suspect if we made the boot process less
> > verbose, people would start to wonder more about why Linux takes so much
> > lo
On Wed, 23 Mar 2005 01:37:29 +0100, Diego Calleja <[EMAIL PROTECTED]> wrote:
>El Mon, 14 Mar 2005 14:07:53 -0500,
>Lee Revell <[EMAIL PROTECTED]> escribió:
>
>> I'm really not trolling, but I suspect if we made the boot process less
>> verbose, people would start to wonder more about why Linux tak
On Wed, 2005-03-23 at 01:37 +0100, Diego Calleja wrote:
> El Mon, 14 Mar 2005 14:07:53 -0500,
> Lee Revell <[EMAIL PROTECTED]> escribió:
>
> > I'm really not trolling, but I suspect if we made the boot process less
> > verbose, people would start to wonder more about why Linux takes so much
> > lo
El Mon, 14 Mar 2005 14:07:53 -0500,
Lee Revell <[EMAIL PROTECTED]> escribió:
> I'm really not trolling, but I suspect if we made the boot process less
> verbose, people would start to wonder more about why Linux takes so much
> longer than XP to boot.
By the way, Microsoft seems to be claiming th
On Mon, 14 Mar 2005, Lee Revell wrote:
On Mon, 2005-03-14 at 19:12 +0100, Diego Calleja wrote:
Why should people look at all that "horrid" debug info everytime
they boot, except when they have a problem?
I'm really not trolling, but I suspect if we made the boot process less
verbose, people would s
Linus Torvalds <[EMAIL PROTECTED]> writes:
> And those occasional people are often not going to eb very good at
> reporting bugs. If they don't see anything happening, they'll just give up
> rather than bother to report it. So I do think we want the fairly verbose
> thing enabled by default. You
Hi!
> > We already have the 'quiet' option, but even so, I think the kernel is
> > *way*
> > too verbose. Someone needs to make a personal crusade out of removing
> > unneeded and unjustified printks from the kernel before it really gets
> > better
> > though...
>
> Oh well, I admit going b
On Tue, 15 Mar 2005, Benjamin Herrenschmidt wrote:
We already have the 'quiet' option, but even so, I think the kernel is *way*
too verbose. Someone needs to make a personal crusade out of removing
unneeded and unjustified printks from the kernel before it really gets better
though...
Oh well, I a
> We already have the 'quiet' option, but even so, I think the kernel is *way*
> too verbose. Someone needs to make a personal crusade out of removing
> unneeded and unjustified printks from the kernel before it really gets better
> though...
Oh well, I admit going backward here with my new r
[trimming cc list in case this starts a flame war)
On Mon, 2005-03-14 at 19:12 +0100, Diego Calleja wrote:
> Why should people look at all that "horrid" debug info everytime
> they boot, except when they have a problem?
I'm really not trolling, but I suspect if we made the boot process less
verbo
El Mon, 14 Mar 2005 08:55:18 -0800,
Jesse Barnes <[EMAIL PROTECTED]> escribió:
> We already have the 'quiet' option, but even so, I think the kernel is *way*
> too verbose. Someone needs to make a personal crusade out of removing
> unneeded and unjustified printks from the kernel before it real
Hi!
> > We already have the 'quiet' option, but even so, I think the kernel is
> > *way*
> > too verbose. Someone needs to make a personal crusade out of removing
> > unneeded and unjustified printks from the kernel before it really gets
> > better
> > though...
>
> The thing is, this comes
On Monday, March 14, 2005 9:18 am, Linus Torvalds wrote:
> In fact, even the ones that have no "information" end up often being a big
> clue about where the hang happened.
Yeah, I use the startup output all the time for stuff like that, no question
it's useful.
> And those occasional people are
On Mon, Mar 14, 2005 at 08:55:18AM -0800, Jesse Barnes wrote:
> On Monday, March 14, 2005 12:37 am, Pavel Machek wrote:
> > Perhaps we could have a rule like
> >
> > "non-experimental driver may only print out one line per actual
> > device?"
> >
> > (and perhaps: dmesg output for boot going
On Mon, 14 Mar 2005, Jesse Barnes wrote:
>
> We already have the 'quiet' option, but even so, I think the kernel is *way*
> too verbose. Someone needs to make a personal crusade out of removing
> unneeded and unjustified printks from the kernel before it really gets better
> though...
The t
Hi!
> > "non-experimental driver may only print out one line per actual
> > device?"
> >
> > (and perhaps: dmesg output for boot going okay should fit on one screen).
> >
> > Or perhaps we should have warnings-like regression testing.
> >
> > "New kernel 2.8.17 came: 3 errors, 135 warnings, 1890 l
On Monday, March 14, 2005 12:37 am, Pavel Machek wrote:
> Perhaps we could have a rule like
>
> "non-experimental driver may only print out one line per actual
> device?"
>
> (and perhaps: dmesg output for boot going okay should fit on one screen).
>
> Or perhaps we should have warnings-like regres
Hi!
> >>I'm fascinated that not a single person picked up on this problem
> >>whilst the agp code sat in -mm. Even if DRI isn't enabled,
> >>every box out there with AGP that uses the generic routines
> >>(which is a majority), should have barfed loudly when it hit
> >>this check during boot. Doe
On Mon, 14 Mar 2005, Pavel Machek wrote:
I'm fascinated that not a single person picked up on this problem
whilst the agp code sat in -mm. Even if DRI isn't enabled,
every box out there with AGP that uses the generic routines
(which is a majority), should have barfed loudly when it hit
this check d
On Pá 11-03-05 17:26:14, Dave Jones wrote:
> On Sat, Mar 12, 2005 at 07:18:19AM +0900, OGAWA Hirofumi wrote:
> > Linus Torvalds <[EMAIL PROTECTED]> writes:
> >
> > > Hmm.. We seem to not have any tests for the counts becoming negative, and
> > > this would seem to be an easy mistake to make co
On Sat, Mar 12, 2005 at 11:08:20PM -0500, Dave Jones wrote:
> On Sat, Mar 12, 2005 at 07:13:05PM -0800, Jesse Barnes wrote:
> > On Friday, March 11, 2005 7:58 pm, Dave Jones wrote:
> > > > sgi-agp.c was sent to Dave about 2 weeks ago. I assumed he was
> waiting
> > > > for the TIO header
On Sat, Mar 12, 2005 at 07:13:05PM -0800, Jesse Barnes wrote:
> On Friday, March 11, 2005 7:58 pm, Dave Jones wrote:
> > > sgi-agp.c was sent to Dave about 2 weeks ago. I assumed he was waiting
> > > for the TIO header files to make it from the ia64 tree into Linus's
> > > tree.
> >
> > Ac
On Friday, March 11, 2005 7:58 pm, Dave Jones wrote:
> > sgi-agp.c was sent to Dave about 2 weeks ago. I assumed he was waiting
> > for the TIO header files to make it from the ia64 tree into Linus's
> > tree.
>
> Actually I just got swamped with other stuff, and dropped the ball.
> I still have
On Thu, Mar 10, 2005 at 09:49:53PM -0500, Dave Jones wrote:
> On Fri, Mar 11, 2005 at 01:40:24PM +1100, Benjamin Herrenschmidt wrote:
> >
> > > After it does that pci_dev_put on the from, it does another pci_dev_get
> > > on 'dev', which is what my put was releasing.
> > >
> > > Or am I terr
On Sun, 13 Mar 2005, OGAWA Hirofumi wrote:
>
> However, inode->i_writecount and some stuffs seems to be already using
> the negative values (or sparc was used the signed 24 bits value).
>
> Anyway, unfortunately inode->i_writecount triggered in atomic_dec().
Ahh, you're right. Thanks for testi
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Btw, this should probably check for negative 32-bit values too, ie the
> test should probably be
>
> if ((int)atomic_read(v) <= 0)
>
> and it should probably be done for the regular atomic_dec() etc cases too,
> not just the dec-and-test. "atomi
On Sat, 12 Mar 2005, OGAWA Hirofumi wrote:
>
> diff -puN include/asm-i386/atomic.h~detect-atomic-counter-underflows
> include/asm-i386/atomic.h
> --- 25/include/asm-i386/atomic.h~detect-atomic-counter-underflows Wed Nov
> 3 15:27:37 2004
> +++ 25-akpm/include/asm-i386/atomic.h Wed Nov 3
On Fri Mar 11 2005 - 18:30:03 EST Bjorn Helgaas wrote:
> On Sat, 2005-03-12 at 09:43 +1100, Paul Mackerras wrote:
> > On PPC/PPC64 machines, the host bridges generally do not appear as PCI
> > devices either. *However*, the AGP spec requires a set of registers
> > in PCI config space for controll
On Fri, Mar 11, 2005 at 07:27:04PM -0800, Mike Werner wrote:
> On Friday 11 March 2005 10:04, Jesse Barnes wrote:
> > On Friday, March 11, 2005 9:59 am, Bjorn Helgaas wrote:
> > > > Right, it's a special agp driver, sgi-agp.c.
> > >
> > > Where's sgi-agp.c? The HP (ia64-only at the moment) co
On Friday 11 March 2005 10:04, Jesse Barnes wrote:
> On Friday, March 11, 2005 9:59 am, Bjorn Helgaas wrote:
> > > Right, it's a special agp driver, sgi-agp.c.
> >
> > Where's sgi-agp.c? The HP (ia64-only at the moment) code is hp-agp.c.
> > It does make a fake PCI dev for the bridge because DRM s
Bjorn Helgaas writes:
> I still don't quite understand this. If the host bridge is not a
> PCI device, what PCI device contains the AGP capability that controls
> the host bridge? I assume you're saying that you are required to
The AGP spec shows an example northbridge implementation that has t
> I still don't quite understand this. If the host bridge is not a
> PCI device, what PCI device contains the AGP capability that controls
> the host bridge? I assume you're saying that you are required to
> have TWO PCI devices that have the AGP capability, one for the AGP
> device and one for
On Friday 11 March 2005 18:09, Paul Mackerras wrote:
>Dave Jones writes:
>> I'm fascinated that not a single person picked up on this problem
>> whilst the agp code sat in -mm. Even if DRI isn't enabled,
>> every box out there with AGP that uses the generic routines
>> (which is a majority), should
On Friday 11 March 2005 17:33, Chris Wedgwood wrote:
>On Fri, Mar 11, 2005 at 05:26:14PM -0500, Dave Jones wrote:
>> Does no-one read dmesg output any more?
>
>For many people it's overly verbose and long --- so I assume they
> just tune it out.
>
>Sometimes I wonder if it would be a worth-while ef
Dave Jones writes:
> I'm fascinated that not a single person picked up on this problem
> whilst the agp code sat in -mm. Even if DRI isn't enabled,
> every box out there with AGP that uses the generic routines
> (which is a majority), should have barfed loudly when it hit
> this check during boot.
On Fri, 2005-03-11 at 22:46 +, J.A. Magallon wrote:
> On 03.11, Dave Jones wrote:
> > On Fri, Mar 11, 2005 at 10:11:08PM +, J.A. Magallon wrote:
> > >
> > > On 03.11, Paul Mackerras wrote:
> > > > Linus,
> > > >
> > > ...
> > > >
> > > > Oh, and by the way, I have 3D working relat
On Fri, 2005-03-11 at 23:17 +, J.A. Magallon wrote:
> On 03.12, Martin Schlemmer wrote:
> > On Fri, 2005-03-11 at 22:46 +, J.A. Magallon wrote:
> > > On 03.11, Dave Jones wrote:
> > > > On Fri, Mar 11, 2005 at 10:11:08PM +, J.A. Magallon wrote:
> > > > >
> > > > > On 03.11, Paul Mack
On 03.12, Martin Schlemmer wrote:
> On Fri, 2005-03-11 at 23:17 +, J.A. Magallon wrote:
> > On 03.12, Martin Schlemmer wrote:
> > > On Fri, 2005-03-11 at 22:46 +, J.A. Magallon wrote:
> > > > On 03.11, Dave Jones wrote:
> > > > > On Fri, Mar 11, 2005 at 10:11:08PM +, J.A. Magallon wrot
On Sat, 2005-03-12 at 09:43 +1100, Paul Mackerras wrote:
> On PPC/PPC64 machines, the host bridges generally do not appear as PCI
> devices either. *However*, the AGP spec requires a set of registers
> in PCI config space for controlling the target (host) side of the AGP
> bus. In other words you
On 03.12, Martin Schlemmer wrote:
> On Fri, 2005-03-11 at 22:46 +, J.A. Magallon wrote:
> > On 03.11, Dave Jones wrote:
> > > On Fri, Mar 11, 2005 at 10:11:08PM +, J.A. Magallon wrote:
> > > >
> > > > On 03.11, Paul Mackerras wrote:
> > > > > Linus,
> > > > >
> > > > ...
> > > > >
On 03.11, Dave Jones wrote:
> On Fri, Mar 11, 2005 at 10:11:08PM +, J.A. Magallon wrote:
> >
> > On 03.11, Paul Mackerras wrote:
> > > Linus,
> > >
> > ...
> > >
> > > Oh, and by the way, I have 3D working relatively well on my G5 with a
> > > 64-bit kernel (and 32-bit X server and
On Fri, 11 Mar 2005 17:42:46 -0500, Dmitry Torokhov
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Sat, 12 Mar 2005 07:18:19 +0900, OGAWA Hirofumi
> <[EMAIL PROTECTED]> wrote:
> >
> > + if (!atomic_read(v)) {
> > + printk("BUG: atomic counter underflow at:\n");
> > + dum
Hi,
On Sat, 12 Mar 2005 07:18:19 +0900, OGAWA Hirofumi
<[EMAIL PROTECTED]> wrote:
>
> + if (!atomic_read(v)) {
> + printk("BUG: atomic counter underflow at:\n");
> + dump_stack();
> + }
I wonder if adding "unlikely" might be beneficial here.
--
Dmitry
-
Bjorn Helgaas writes:
> HP ia64 and parisc boxes are similar. The host bridges do not appear
> as PCI devices. We discover them via ACPI on ia64 and PDC on parisc.
On PPC/PPC64 machines, the host bridges generally do not appear as PCI
devices either. *However*, the AGP spec requires a set of r
On Fri, 11 Mar 2005, Dave Jones wrote:
>
> I'm fascinated that not a single person picked up on this problem
> whilst the agp code sat in -mm. Even if DRI isn't enabled,
> every box out there with AGP that uses the generic routines
> (which is a majority), should have barfed loudly when it hit
>
On Fri, Mar 11, 2005 at 05:26:14PM -0500, Dave Jones wrote:
> Does no-one read dmesg output any more?
For many people it's overly verbose and long --- so I assume they just
tune it out.
Sometimes I wonder if it would be a worth-while effort to trim the
dmesg boot text down to what users really *
On Sat, Mar 12, 2005 at 07:18:19AM +0900, OGAWA Hirofumi wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > Hmm.. We seem to not have any tests for the counts becoming negative, and
> > this would seem to be an easy mistake to make considering that both I and
> > Dave did it.
>
> I
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Hmm.. We seem to not have any tests for the counts becoming negative, and
> this would seem to be an easy mistake to make considering that both I and
> Dave did it.
I stole this from -mm.
--
OGAWA Hirofumi <[EMAIL PROTECTED]>
From: Ingo Molnar <[EM
On Fri, Mar 11, 2005 at 10:11:08PM +, J.A. Magallon wrote:
>
> On 03.11, Paul Mackerras wrote:
> > Linus,
> >
> ...
> >
> > Oh, and by the way, I have 3D working relatively well on my G5 with a
> > 64-bit kernel (and 32-bit X server and clients), which is why I care
> > about AGP 3.
On 03.11, Paul Mackerras wrote:
> Linus,
>
...
>
> Oh, and by the way, I have 3D working relatively well on my G5 with a
> 64-bit kernel (and 32-bit X server and clients), which is why I care
> about AGP 3.0 support. :)
>
I think it is not a G5 only problem. I have a x8 card, a x8 slot, but
ag
On Friday, March 11, 2005 10:04 am, James Simmons wrote:
> > > Oh, and by the way, I have 3D working relatively well on my G5 with a
> > > 64-bit kernel (and 32-bit X server and clients), which is why I care
> > > about AGP 3.0 support. :)
> >
> > I have a system in my office with several gfx pipes
On Friday, March 11, 2005 9:59 am, Bjorn Helgaas wrote:
> > Right, it's a special agp driver, sgi-agp.c.
>
> Where's sgi-agp.c? The HP (ia64-only at the moment) code is hp-agp.c.
> It does make a fake PCI dev for the bridge because DRM still seemed to
> want that.
I think Mike posted it but hasn'
> > Oh, and by the way, I have 3D working relatively well on my G5 with a
> > 64-bit kernel (and 32-bit X server and clients), which is why I care
> > about AGP 3.0 support. :)
>
> I have a system in my office with several gfx pipes on different AGP busses,
> and I'd like that to work well too!
On Fri, 2005-03-11 at 08:39 -0800, Jesse Barnes wrote:
> On Thursday, March 10, 2005 8:30 pm, Benjamin Herrenschmidt wrote:
> > On Thu, 2005-03-10 at 20:02 -0800, Jesse Barnes wrote:
> > > On Thursday, March 10, 2005 6:38 pm, Benjamin Herrenschmidt wrote:
> > > > That one is even worse... from what
On Thursday, March 10, 2005 8:30 pm, Benjamin Herrenschmidt wrote:
> On Thu, 2005-03-10 at 20:02 -0800, Jesse Barnes wrote:
> > On Thursday, March 10, 2005 6:38 pm, Benjamin Herrenschmidt wrote:
> > > That one is even worse... from what I see in your lspci output, you
> > > have no bridge with AGP
On Thu, 2005-03-10 at 20:02 -0800, Jesse Barnes wrote:
> On Thursday, March 10, 2005 6:38 pm, Benjamin Herrenschmidt wrote:
> > That one is even worse... from what I see in your lspci output, you have
> > no bridge with AGP capability at all, and the various AGP devices are
> > all siblings...
>
>
On Thursday, March 10, 2005 6:38 pm, Benjamin Herrenschmidt wrote:
> That one is even worse... from what I see in your lspci output, you have
> no bridge with AGP capability at all, and the various AGP devices are
> all siblings...
Both of the video cards are sitting on agp busses in agp slots hoo
On Fri, Mar 11, 2005 at 01:40:24PM +1100, Benjamin Herrenschmidt wrote:
>
> > After it does that pci_dev_put on the from, it does another pci_dev_get
> > on 'dev', which is what my put was releasing.
> >
> > Or am I terribly confused ?
>
> Well, pci_get_class() put's the passed-in device
On Thu, 2005-03-10 at 18:18 -0800, Jesse Barnes wrote:
> On Thursday, March 10, 2005 6:11 pm, Paul Mackerras wrote:
> > What is the relationship in the PCI device tree between the video
> > cards and their bridges? Is there for instance only one AGP bridge
> > per host bridge?
>
> I *think* a TIO
On Fri, Mar 11, 2005 at 01:35:40PM +1100, Benjamin Herrenschmidt wrote:
>
> >
> > This part I'm not so sure about.
> > The pci_get_class() call a few lines above will get a refcount that
> > we will now never release.
>
> We will ... on the next loop iteration when we call pci_get_class a
> After it does that pci_dev_put on the from, it does another pci_dev_get
> on 'dev', which is what my put was releasing.
>
> Or am I terribly confused ?
Well, pci_get_class() put's the passed-in device and get's() the
returned one. So if you run it in a loop, you should never have to
either get
>
> This part I'm not so sure about.
> The pci_get_class() call a few lines above will get a refcount that
> we will now never release.
We will ... on the next loop iteration when we call pci_get_class again.
> Thanks for taking a look at this. The absense of hardware to test
> on means I prett
On Thu, 10 Mar 2005, Dave Jones wrote:
>
> >/* ARQSZ - Set the value to the maximum one.
> > @@ -642,11 +638,6 @@
> >return 0;
> >}
> >cap_ptr = pci_find_capability(device, PCI_CAP_ID_AGP);
> > - if (!cap_ptr) {
> > -
On Fri, 11 Mar 2005, Paul Mackerras wrote:
>
> The point is that pci_get_class does a pci_dev_put() on the "from"
> parameter, so your code ended up doing a double put.
Ahh, I missed that too.
Hmm.. We seem to not have any tests for the counts becoming negative, and
this would seem to be an e
Dave Jones writes:
> >cap_ptr = pci_find_capability(device, PCI_CAP_ID_AGP);
> > - if (!cap_ptr) {
> > - pci_dev_put(device);
> > - continue;
> > - }
> > - cap_ptr = 0;
> >}
>
> This part I'm not so sure a
On Thursday, March 10, 2005 6:11 pm, Paul Mackerras wrote:
> What is the relationship in the PCI device tree between the video
> cards and their bridges? Is there for instance only one AGP bridge
> per host bridge?
I *think* a TIO (numalink<->agp & numalink<->pci) has two AGP busses coming
off of
On Fri, Mar 11, 2005 at 01:18:36PM +1100, Paul Mackerras wrote:
> Dave Jones writes:
>
> > > cap_ptr = pci_find_capability(device, PCI_CAP_ID_AGP);
> > > - if (!cap_ptr) {
> > > - pci_dev_put(device);
> > > - conti
On Fri, Mar 11, 2005 at 12:24:54PM +1100, Paul Mackerras wrote:
> In fact there are other bogosities in drivers/char/agp/generic.c. I
> can't believe Dave ever tested that code with an AGP 3.0 device.
Hrmm, I'm fairly sure I did. It's also been sat in -mm without complaint
for a few weeks, whi
Jesse Barnes writes:
> I have a system in my office with several gfx pipes on different AGP busses,
> and I'd like that to work well too! :)
Interesting, could you post the output from lspci -v on that system?
What is the relationship in the PCI device tree between the video
cards and their bri
On Thursday, March 10, 2005 5:24 pm, Paul Mackerras wrote:
> The patch below fixes these problems. It will work in the 99.99% of
> cases where we have one AGP bridge and one AGP video card. We should
> eventually cope with multiple AGP bridges, but doing the matching of
> bridges to video cards i
On Fri, 11 Mar 2005, Paul Mackerras wrote:
>
> Oh, and by the way, I have 3D working relatively well on my G5 with a
> 64-bit kernel (and 32-bit X server and clients), which is why I care
> about AGP 3.0 support. :)
Ok, I can't even compile it on my G5, so you're obviously withholding some
pat
Linus,
I see that you did a cset -x on a changeset from Dave Jones that added
a bogus test for which AGP bridge a device is under. That has left us
with code in agp_collect_device_status that will never find any device
(just take a look and you'll see).
In fact there are other bogosities in driv
82 matches
Mail list logo
