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
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
> >
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
with Longhorn.
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 magicall
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
> > 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
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
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 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.
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 can
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 be
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 slurp
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
all the
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 reclaimed as its
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
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
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
> >
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
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
> >
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
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 that
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
longer than
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 takes so much
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
longer than
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 optimally
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
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
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
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
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 can
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
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
> 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
[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
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
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
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
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
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
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
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.
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
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
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 considering
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
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. Does no-one read
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 regression
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 lines of dmesg
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 thing
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 okay should
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
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 up every
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 really
[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
verbose,
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
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
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 backward here
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
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.
> >
> >
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
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
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
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.
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 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.
Actually I just
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 files to
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
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. atomic values
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 testing it
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 terribly confused
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 the
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
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)
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
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
> 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),
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
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
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
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
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
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
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");
> > +
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
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.
>
>
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
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
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
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
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
> > 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!
1 - 100 of 163 matches
Mail list logo
