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 drivers/char/agp/generic.c. I
can't believe Dave ever tested that code with an AGP 3.0 device. If
you pass in a mode that has the AGP 3.0 bit set, agp_v3_parse_one()
will first clear that bit (and print a message), and then complain
because you haven't got that bit set in the mode, with a message that
the caller is broken. Furthermore, if the mode passed in has both the
4x and 8x bits set, the new code will give you 4x where the old code
would give you 8x (which is what the caller wanted).
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 is a hard problem because the video card is not
necessarily a child or sibling of the PCI device that we use for
controlling the AGP bridge. I think we need to see an actual example
of a system with multiple AGP bridges first.
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. :)
Paul.
diff -urN linux-2.5/drivers/char/agp/agp.h g5-bad/drivers/char/agp/agp.h
--- linux-2.5/drivers/char/agp/agp.h 2005-03-07 14:01:44.000000000 +1100
+++ g5/drivers/char/agp/agp.h 2005-03-11 11:54:54.000000000 +1100
@@ -322,7 +322,7 @@
#define AGPCTRL_GTLBEN (1<<7)
#define AGP2_RESERVED_MASK 0x00fffcc8
-#define AGP3_RESERVED_MASK 0x00ff00cc
+#define AGP3_RESERVED_MASK 0x00ff00c4
#define AGP_ERRATA_FASTWRITES 1<<0
#define AGP_ERRATA_SBA 1<<1
diff -urN linux-2.5/drivers/char/agp/generic.c g5-bad/drivers/char/agp/generic.c
--- linux-2.5/drivers/char/agp/generic.c 2005-03-11 11:47:37.000000000 +1100
+++ g5/drivers/char/agp/generic.c 2005-03-11 12:08:29.000000000 +1100
@@ -515,13 +515,9 @@
printk (KERN_INFO PFX "%s tried to set rate=x0. Setting to AGP3 x4 mode.\n", current->comm);
*requested_mode |= AGPSTAT3_4X;
}
- if (tmp == 3) {
- printk (KERN_INFO PFX "%s tried to set rate=x3. Setting to AGP3 x4 mode.\n", current->comm);
- *requested_mode |= AGPSTAT3_4X;
- }
- if (tmp >3) {
- printk (KERN_INFO PFX "%s tried to set rate=x%d. Setting to AGP3 x8 mode.\n", current->comm, tmp);
- *requested_mode |= AGPSTAT3_8X;
+ if (tmp >= 3) {
+ printk (KERN_INFO PFX "%s tried to set rate=x%d. Setting to AGP3 x8 mode.\n", current->comm, tmp * 4);
+ *requested_mode = (*requested_mode & ~7) | AGPSTAT3_8X;
}
/* 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) {
- pci_dev_put(device);
- continue;
- }
- cap_ptr = 0;
}
/*
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
patches you shouldn't ;)
Anyway, I fixed up the AGP discovery differently from your patch, so you
should check that my version works for you. DaveJ, please give it a
once-over too, since my G5 doesn't do the AGP thing yet.
Linus
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 is a hard problem because the video card is not
> necessarily a child or sibling of the PCI device that we use for
> controlling the AGP bridge. I think we need to see an actual example
> of a system with multiple AGP bridges first.
We have real systems with multiple AGP bridges out there already, so we'd like
to see this fixed properly. I think this is Mike's code, Mike?
> 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! :)
Jesse
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, which is odd.
> you pass in a mode that has the AGP 3.0 bit set, agp_v3_parse_one()
> will first clear that bit (and print a message), and then complain
> because you haven't got that bit set in the mode, with a message that
> the caller is broken. Furthermore, if the mode passed in has both the
> 4x and 8x bits set, the new code will give you 4x where the old code
> would give you 8x (which is what the caller wanted).
>
> 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 is a hard problem because the video card is not
> necessarily a child or sibling of the PCI device that we use for
> controlling the AGP bridge. I think we need to see an actual example
> of a system with multiple AGP bridges first.
>
> 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. :)
>
> Paul.
>
> diff -urN linux-2.5/drivers/char/agp/agp.h g5-bad/drivers/char/agp/agp.h
> --- linux-2.5/drivers/char/agp/agp.h 2005-03-07 14:01:44.000000000 +1100
> +++ g5/drivers/char/agp/agp.h 2005-03-11 11:54:54.000000000 +1100
> @@ -322,7 +322,7 @@
> #define AGPCTRL_GTLBEN (1<<7)
>
> #define AGP2_RESERVED_MASK 0x00fffcc8
> -#define AGP3_RESERVED_MASK 0x00ff00cc
> +#define AGP3_RESERVED_MASK 0x00ff00c4
>
> #define AGP_ERRATA_FASTWRITES 1<<0
> #define AGP_ERRATA_SBA 1<<1
> diff -urN linux-2.5/drivers/char/agp/generic.c g5-bad/drivers/char/agp/generic.c
> --- linux-2.5/drivers/char/agp/generic.c 2005-03-11 11:47:37.000000000 +1100
> +++ g5/drivers/char/agp/generic.c 2005-03-11 12:08:29.000000000 +1100
> @@ -515,13 +515,9 @@
> printk (KERN_INFO PFX "%s tried to set rate=x0. Setting to AGP3 x4 mode.\n", current->comm);
> *requested_mode |= AGPSTAT3_4X;
> }
> - if (tmp == 3) {
> - printk (KERN_INFO PFX "%s tried to set rate=x3. Setting to AGP3 x4 mode.\n", current->comm);
> - *requested_mode |= AGPSTAT3_4X;
> - }
> - if (tmp >3) {
> - printk (KERN_INFO PFX "%s tried to set rate=x%d. Setting to AGP3 x8 mode.\n", current->comm, tmp);
> - *requested_mode |= AGPSTAT3_8X;
> + if (tmp >= 3) {
> + printk (KERN_INFO PFX "%s tried to set rate=x%d. Setting to AGP3 x8 mode.\n", current->comm, tmp * 4);
> + *requested_mode = (*requested_mode & ~7) | AGPSTAT3_8X;
> }
This seems to make sense.
> /* 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) {
> - pci_dev_put(device);
> - continue;
> - }
> - cap_ptr = 0;
> }
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.
Thanks for taking a look at this. The absense of hardware to test
on means I pretty much rely on feedback from inclusion in -mm
to hear about problems like this before it hits mainline.
Unfortunatly, no-one with ppc64 tested it there it seems :-(
Dave
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 bridges? Is there for instance only one AGP bridge
per host bridge?
Paul.
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 about.
> The pci_get_class() call a few lines above will get a refcount that
> we will now never release.
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.
> Unfortunatly, no-one with ppc64 tested it there it seems :-(
I have only recently got AGP and DRI working on my G5. I'll post a
patch for AGP support on the G5 shortly.
Paul.
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 it...
> Interesting, could you post the output from lspci -v on that system?
flatearth:~ # lspci -v
0000:01:01.0 Co-processor: Silicon Graphics, Inc. IOC4 I/O controller (rev 4f)
Flags: bus master, 66Mhz, medium devsel, latency 255, IRQ 60
Memory at c00000080f200000 (32-bit, non-prefetchable)
0000:01:03.0 Class 0106: Vitesse Semiconductor VSC7174 PCI/PCI-X Serial ATA Host Bus Controller (rev 01)
Subsystem: Vitesse Semiconductor VSC7174 PCI/PCI-X Serial ATA Host Bus Controller
Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 61
Memory at c00000080f300000 (64-bit, non-prefetchable)
Capabilities: [e0] PCI-X non-bridge device.
Capabilities: [e8] Power Management version 2
Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/2 Enable-
0000:01:04.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5701 Gigabit Ethernet (rev 15)
Subsystem: Silicon Graphics, Inc. SGI IO9/IO10 Gigabit Ethernet (Copper)
Flags: bus master, 66Mhz, medium devsel, latency 48, IRQ 62
Memory at c00000080f310000 (64-bit, non-prefetchable)
Capabilities: [40] PCI-X non-bridge device.
Capabilities: [48] Power Management version 2
Capabilities: [50] Vital Product Data
Capabilities: [58] Message Signalled Interrupts: 64bit+ Queue=0/3 Enable-
0000:02:01.0 VGA compatible controller: ATI Technologies Inc Rage 128 RE/SG (prog-if 00 [VGA])
Subsystem: ATI Technologies Inc Xpert 128
Flags: bus master, stepping, medium devsel, latency 64, IRQ 63
Memory at c0000008a4000000 (32-bit, prefetchable) [size=c00000080fe20000]
I/O ports at c00000080fa00000 [size=256]
Memory at c00000080fe00000 (32-bit, non-prefetchable) [size=16K]
Expansion ROM at 0000000000020000 [disabled]
Capabilities: [5c] Power Management version 1
0000:02:02.0 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
Subsystem: Orange Micro Root Hub
Flags: bus master, medium devsel, latency 8, IRQ 64
Memory at c00000080fe04000 (32-bit, non-prefetchable)
Capabilities: [40] Power Management version 2
0000:02:02.1 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
Subsystem: Orange Micro Root Hub
Flags: bus master, medium devsel, latency 8, IRQ 65
Memory at c00000080fe05000 (32-bit, non-prefetchable)
Capabilities: [40] Power Management version 2
0000:02:02.2 USB Controller: NEC Corporation USB 2.0 (rev 02) (prog-if 20 [EHCI])
Subsystem: Orange Micro Root hub
Flags: bus master, medium devsel, latency 68, IRQ 65
Memory at c00000080fe06000 (32-bit, non-prefetchable)
Capabilities: [40] Power Management version 2
0000:17:00.0 VGA compatible controller: ATI Technologies Inc R350 NK [Fire GL X2] (rev 80) (prog-if 00 [VGA])
Subsystem: ATI Technologies Inc: Unknown device 0152
Flags: bus master, stepping, 66Mhz, medium devsel, latency 0, IRQ 67
Memory at c0000041c8000000 (32-bit, prefetchable) [size=c0000041c0120000]
I/O ports at c000004023001000 [size=256]
Memory at c0000041c0100000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at 0000000000020000 [disabled]
Capabilities: [58] AGP version 3.0
Capabilities: [50] Power Management version 2
0000:17:00.1 Display controller: ATI Technologies Inc: Unknown device 4e6b (rev80)
Subsystem: ATI Technologies Inc: Unknown device 0153
Flags: bus master, stepping, 66Mhz, medium devsel, latency 0
Memory at c0000041d0000000 (32-bit, prefetchable) [size=c0000041c0000000]
Memory at c0000041c0110000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at <unassigned>
Capabilities: [50] Power Management version 2
0000:1b:00.0 VGA compatible controller: ATI Technologies Inc R350 NK [Fire GL X2] (rev 80) (prog-if 00 [VGA])
Subsystem: ATI Technologies Inc: Unknown device 0152
Flags: bus master, stepping, 66Mhz, medium devsel, latency 0, IRQ 66
Memory at c00000c1c8000000 (32-bit, prefetchable) [size=c00000c1c0120000]
I/O ports at c00000c023001000 [size=256]
Memory at c00000c1c0100000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at 0000000000020000 [disabled]
Capabilities: [58] AGP version 3.0
Capabilities: [50] Power Management version 2
0000:1b:00.1 Display controller: ATI Technologies Inc: Unknown device 4e6b (rev80)
Subsystem: ATI Technologies Inc: Unknown device 0153
Flags: bus master, stepping, 66Mhz, medium devsel, latency 0
Memory at c00000c1d0000000 (32-bit, prefetchable) [size=c00000c1c0000000]
Memory at c00000c1c0110000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at <unassigned>
Capabilities: [50] Power Management version 2
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);
> > > - continue;
> > > - }
> > > - cap_ptr = 0;
> > > }
> >
> > 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.
>
> 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.
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 ?
Dave
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) {
> > - pci_dev_put(device);
> > - continue;
> > - }
> > - cap_ptr = 0;
> > }
>
> 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.
That's the part I rewrote in my version, I think that one is good.
Linus
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 easy mistake to make considering that both I and
Dave did it.
Linus
>
> 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 pretty much rely on feedback from inclusion in -mm
> to hear about problems like this before it hits mainline.
> Unfortunatly, no-one with ppc64 tested it there it seems :-(
And ppc32, and probably others... I have seen AGP layed out differently
in quite a few cases....
Ben.
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 again.
Ohhh, duh. Yes. now I follow.
Dave
> 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 or put. When you exit the loop with a valid pci_dev, though,
you should definitely put() it after you're done with it, but this is
something that should be done only for that specific instance and after
you are finished with it...
Ben.
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 (numalink<->agp & numalink<->pci) has two AGP busses coming
> off of it...
>
> > Interesting, could you post the output from lspci -v on that system?
>
> flatearth:~ # lspci -v
.../...
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...
Are you sure there is any real AGP slot in there ?
I'm afraid we may have to do the card <-> bridge machine as a bridge
specific function. At least the bridge driver can "know" how the HW for
that specific bridge lays out the PCI view of the AGP slot.
Ben.
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 and get's() the
> returned one. So if you run it in a loop, you should never have to
> either get or put. When you exit the loop with a valid pci_dev, though,
> you should definitely put() it after you're done with it, but this is
> something that should be done only for that specific instance and after
> you are finished with it...
Yeah. Makes perfect sense now I've had it spelled out for me :-)
I think Linus is right though that some extra bullet-proofing in kref_put
to BUG() if it goes negative would've caught this. I wonder if anyone
else has fallen into this trap.
Dave
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 hooked up to
host to agp bridges.
> Are you sure there is any real AGP slot in there ?
Yes :)
Jesse
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...
>
> Both of the video cards are sitting on agp busses in agp slots hooked up to
> host to agp bridges.
>
> > Are you sure there is any real AGP slot in there ?
>
> Yes :)
Well, according to your lspci, none of the bridges exposes a device with
AGP capabilities... It looks like you aren't exposing the host "self"
device on the bus. Do you have an AGP driver ? If yes, it certainly
can't use any of the generic code anyway ...
I still think that the matching between a bridge and a card should be a
bridge callback (with eventually a generic one that works for whatever
x86 are around) so that the bridge driver can deal with funky layouts. I
have no time to toy with this at the moment though ;)
Ben.
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 capability at all, and the various AGP devices
> > > are all siblings...
> >
> > Both of the video cards are sitting on agp busses in agp slots hooked up
> > to host to agp bridges.
> >
> > > Are you sure there is any real AGP slot in there ?
> >
> > Yes :)
>
> Well, according to your lspci, none of the bridges exposes a device with
> AGP capabilities...
There are no bridges listed in my lspci output, that's probably why. :)
> It looks like you aren't exposing the host "self"
> device on the bus. Do you have an AGP driver ? If yes, it certainly
> can't use any of the generic code anyway ...
Right, it's a special agp driver, sgi-agp.c.
> I still think that the matching between a bridge and a card should be a
> bridge callback (with eventually a generic one that works for whatever
> x86 are around) so that the bridge driver can deal with funky layouts. I
> have no time to toy with this at the moment though ;)
Mike, does this sound ok? Maybe you could hack something together?
Thanks,
Jesse
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 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 hooked up
> > > to host to agp bridges.
> > >
> > > > Are you sure there is any real AGP slot in there ?
> > >
> > > Yes :)
> >
> > Well, according to your lspci, none of the bridges exposes a device with
> > AGP capabilities...
>
> There are no bridges listed in my lspci output, that's probably why. :)
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.
> > It looks like you aren't exposing the host "self"
> > device on the bus. Do you have an AGP driver ? If yes, it certainly
> > can't use any of the generic code anyway ...
>
> 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.
> > 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! :)
Where can you get one of these systems?
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't submitted it to Dave yet since it needed
another change that only just made it into the ia64 tree.
Jesse
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 different AGP
> > busses, and I'd like that to work well too! :)
>
> Where can you get one of these systems?
http://www.sgi.com/prism is the site, you probably have to call a sales office
to order one.
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
agpgart keeps saying this:
Mar 11 23:00:28 werewolf dm: Display manager startup succeeded
Mar 11 23:00:29 werewolf kernel: agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
Mar 11 23:00:29 werewolf kernel: agpgart: reserved bits set in mode 0xa. Fixed.
Mar 11 23:00:29 werewolf kernel: agpgart: X passes broken AGP2 flags (2) in AGP3 mode. Fixed.
Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 0000:00:00.0 into 4x mode
Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 0000:01:00.0 into 4x mode
Mar 11 23:00:29 werewolf kernel: agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
Mar 11 23:00:29 werewolf kernel: agpgart: reserved bits set in mode 0xa. Fixed.
Mar 11 23:00:29 werewolf kernel: agpgart: X passes broken AGP2 flags (2) in AGP3 mode. Fixed.
Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 0000:00:00.0 into 4x mode
Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 0000:01:00.0 into 4x mode
The nvidia driver (brand new 1.0-7167, now works with stock -mm) tells me
it is in x8 mode, but i suspect it lies....
Will try your patch right now.
--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandrakelinux release 10.2 (Cooker) for i586
Linux 2.6.11-jam3 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-6mdk)) #2
On Fri, Mar 11, 2005 at 10:11:08PM +0000, 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.0 support. :)
> >
>
> I think it is not a G5 only problem. I have a x8 card, a x8 slot, but
> agpgart keeps saying this:
>
> Mar 11 23:00:28 werewolf dm: Display manager startup succeeded
> Mar 11 23:00:29 werewolf kernel: agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
> Mar 11 23:00:29 werewolf kernel: agpgart: reserved bits set in mode 0xa. Fixed.
> Mar 11 23:00:29 werewolf kernel: agpgart: X passes broken AGP2 flags (2) in AGP3 mode. Fixed.
> Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 0000:00:00.0 into 4x mode
> Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 0000:01:00.0 into 4x mode
> Mar 11 23:00:29 werewolf kernel: agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
> Mar 11 23:00:29 werewolf kernel: agpgart: reserved bits set in mode 0xa. Fixed.
> Mar 11 23:00:29 werewolf kernel: agpgart: X passes broken AGP2 flags (2) in AGP3 mode. Fixed.
> Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 0000:00:00.0 into 4x mode
> Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 0000:01:00.0 into 4x mode
>
> The nvidia driver (brand new 1.0-7167, now works with stock -mm) tells me
> it is in x8 mode, but i suspect it lies....
>
> Will try your patch right now.
Testing latest -bk would be useful.
It has Paul's patch, and a few others.
Dave
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 <[email protected]>
The patch below will detect atomic counter underflows. This has been
test-driven in the -RT patchset for some time. qdisc_destroy() triggered
it sometimes (in a seemingly nonfatal way, during device shutdown) - with
DaveM suggesting that it is most likely a bug in the networking code. So
it would be nice to have this in -mm for some time to validate all atomic
counters on a broader base.
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---
25-akpm/include/asm-i386/atomic.h | 4 ++++
1 files changed, 4 insertions(+)
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 15:27:37 2004
@@ -132,6 +132,10 @@ static __inline__ int atomic_dec_and_tes
{
unsigned char c;
+ if (!atomic_read(v)) {
+ printk("BUG: atomic counter underflow at:\n");
+ dump_stack();
+ }
__asm__ __volatile__(
LOCK "decl %0; sete %1"
:"=m" (v->counter), "=qm" (c)
_
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 stole this from -mm.
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 dmesg output any more ?
Maybe OSDL can add an automated test to send diffs of dmesg
between kernels like they do the automated warning announcements 8-)
Dave
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 *need* to know. We could
retain most of the other stuff at a different log-level which would be
exposed by a kernel command line parameter or something during boot
for when people have problems.
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
> this check during boot. Does no-one read dmesg output any more ?
I don't think it actuially causes a barf, because the counts start at 1,
and they go down to zero due to the double-free, but they don't become
negative until you do that whole detection loop _twice_. I think-
Linus
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 registers
in PCI config space for controlling the target (host) side of the AGP
bus. In other words you are required to have a PCI device to
represent the host side of the AGP bus, with a capability structure in
its config space which contains the standard AGP registers.
The lspci that was posted showed no such device, which was why Ben was
querying it. Maybe your systems aren't fully AGP-compliant, in which
case much of the generic code won't be usable on your systems.
Paul.
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");
> > + dump_stack();
> > + }
>
> I wonder if adding "unlikely" might be beneficial here.
Oh, it's just a debugging patch, nevermind...
--
Dmitry
On 03.11, Dave Jones wrote:
> On Fri, Mar 11, 2005 at 10:11:08PM +0000, 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.0 support. :)
> > >
> >
> > I think it is not a G5 only problem. I have a x8 card, a x8 slot, but
> > agpgart keeps saying this:
> >
> > Mar 11 23:00:28 werewolf dm: Display manager startup succeeded
> > Mar 11 23:00:29 werewolf kernel: agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
> > Mar 11 23:00:29 werewolf kernel: agpgart: reserved bits set in mode 0xa. Fixed.
> > Mar 11 23:00:29 werewolf kernel: agpgart: X passes broken AGP2 flags (2) in AGP3 mode. Fixed.
> > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 0000:00:00.0 into 4x mode
> > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 0000:01:00.0 into 4x mode
> > Mar 11 23:00:29 werewolf kernel: agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
> > Mar 11 23:00:29 werewolf kernel: agpgart: reserved bits set in mode 0xa. Fixed.
> > Mar 11 23:00:29 werewolf kernel: agpgart: X passes broken AGP2 flags (2) in AGP3 mode. Fixed.
> > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 0000:00:00.0 into 4x mode
> > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 0000:01:00.0 into 4x mode
> >
> > The nvidia driver (brand new 1.0-7167, now works with stock -mm) tells me
> > it is in x8 mode, but i suspect it lies....
> >
> > Will try your patch right now.
>
Looks fine, now I got:
agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
werewolf:~> lspci
00:00.0 Host bridge: Intel Corporation 82875P/E7210 Memory Controller Hub (rev 02)
00:01.0 PCI bridge: Intel Corporation 82875P Processor to AGP Controller (rev 02)
...
01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1)
BTW, I had to patch the nVidia driver. It just tries up to x4 AGP...
Thanks.
--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandrakelinux release 10.2 (Cooker) for i586
Linux 2.6.11-jam3 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-6mdk)) #2
On 03.12, Martin Schlemmer wrote:
> On Fri, 2005-03-11 at 22:46 +0000, J.A. Magallon wrote:
> > On 03.11, Dave Jones wrote:
> > > On Fri, Mar 11, 2005 at 10:11:08PM +0000, 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.0 support. :)
> > > > >
> > > >
> > > > I think it is not a G5 only problem. I have a x8 card, a x8 slot, but
> > > > agpgart keeps saying this:
> > > >
> > > > Mar 11 23:00:28 werewolf dm: Display manager startup succeeded
> > > > Mar 11 23:00:29 werewolf kernel: agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
> > > > Mar 11 23:00:29 werewolf kernel: agpgart: reserved bits set in mode 0xa. Fixed.
> > > > Mar 11 23:00:29 werewolf kernel: agpgart: X passes broken AGP2 flags (2) in AGP3 mode. Fixed.
> > > > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 0000:00:00.0 into 4x mode
> > > > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 0000:01:00.0 into 4x mode
> > > > Mar 11 23:00:29 werewolf kernel: agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
> > > > Mar 11 23:00:29 werewolf kernel: agpgart: reserved bits set in mode 0xa. Fixed.
> > > > Mar 11 23:00:29 werewolf kernel: agpgart: X passes broken AGP2 flags (2) in AGP3 mode. Fixed.
> > > > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 0000:00:00.0 into 4x mode
> > > > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 0000:01:00.0 into 4x mode
> > > >
> > > > The nvidia driver (brand new 1.0-7167, now works with stock -mm) tells me
> > > > it is in x8 mode, but i suspect it lies....
> > > >
> > > > Will try your patch right now.
> > >
> >
> > Looks fine, now I got:
> >
> > agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
> > agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
> > agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
> > agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
> > agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
> > agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
> >
> > werewolf:~> lspci
> > 00:00.0 Host bridge: Intel Corporation 82875P/E7210 Memory Controller Hub (rev 02)
> > 00:01.0 PCI bridge: Intel Corporation 82875P Processor to AGP Controller (rev 02)
> > ...
> > 01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1)
> >
> > BTW, I had to patch the nVidia driver. It just tries up to x4 AGP...
> >
>
> New and old one works fine with Paul's patch:
>
> --old--
> agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
> agpgart: X tried to set rate=x12. Setting to AGP3 x8 mode.
> agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
> agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
> -------
>
> (ok, so old driver is a bit dodgy)
>
> --new--
> agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
> agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
> agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
> -------
>
Just curiosity, what says your /proc/driver/nvidia/agp/status ?
--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandrakelinux release 10.2 (Cooker) for i586
Linux 2.6.11-jam3 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-6mdk)) #3
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 are required to have a PCI device to
> represent the host side of the AGP bus, with a capability structure in
> its config space which contains the standard AGP registers.
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 the bridge.
HP boxes certainly don't have that (zx6000 sample below). I guess
it wouldn't be the first time we deviated from a spec ;-)
Can you point me to the relevant section?
0000:00:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] (prog-if 00 [VGA])
Subsystem: ATI Technologies Inc: Unknown device 010a
Flags: bus master, stepping, 66MHz, medium devsel, latency 192, IRQ 255
Memory at 0000000080000000 (32-bit, prefetchable) [size=128M]
I/O ports at 0d00 [size=256]
Memory at 0000000088020000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at 0000000088000000 [disabled] [size=128K]
Capabilities: [58] AGP version 2.0
Capabilities: [50] Power Management version 2
0000:80:03.0 PCI bridge: Intel Corp. 21154 PCI-to-PCI Bridge (prog-if 00 [Normal decode])
Flags: bus master, 66MHz, medium devsel, latency 128
Bus: primary=80, secondary=81, subordinate=81, sec-latency=128
I/O behind bridge: 00004000-00004fff
Memory behind bridge: a0000000-a40fffff
Capabilities: [dc] Power Management version 1
0000:81:04.0 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
Subsystem: Hewlett-Packard Company: Unknown device 1293
Flags: bus master, medium devsel, latency 128
Memory at 00000000a4032000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2
0000:81:04.1 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
Subsystem: Hewlett-Packard Company: Unknown device aa55
Flags: bus master, medium devsel, latency 128
Memory at 00000000a4031000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2
0000:81:04.2 USB Controller: NEC Corporation USB 2.0 (rev 02) (prog-if 20 [EHCI])
Subsystem: Hewlett-Packard Company: Unknown device aa55
Flags: bus master, medium devsel, latency 128
Memory at 00000000a4030000 (32-bit, non-prefetchable) [size=256]
Capabilities: [40] Power Management version 2
0000:81:05.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] (prog-if 00 [VGA])
Subsystem: Hewlett-Packard Company: Unknown device 1292
Flags: bus master, stepping, medium devsel, latency 128, IRQ 255
Memory at 00000000a0000000 (32-bit, prefetchable) [size=64M]
I/O ports at 4000 [disabled] [size=256]
Memory at 00000000a4020000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at 00000000a4000000 [disabled] [size=128K]
Capabilities: [50] Power Management version 2
0000:a0:01.0 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
Subsystem: NEC Corporation USB
Flags: bus master, medium devsel, latency 128
Memory at 00000000d0022000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2
0000:a0:01.1 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
Subsystem: NEC Corporation USB
Flags: bus master, medium devsel, latency 128
Memory at 00000000d0021000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2
0000:a0:01.2 USB Controller: NEC Corporation USB 2.0 (rev 02) (prog-if 20 [EHCI])
Subsystem: NEC Corporation USB 2.0
Flags: bus master, medium devsel, latency 128
Memory at 00000000d0020000 (32-bit, non-prefetchable) [size=256]
Capabilities: [40] Power Management version 2
0000:a0:02.0 IDE interface: Silicon Image, Inc. (formerly CMD Technology Inc) PCI0649 (rev 02) (prog-if 8f [Master SecP SecO PriP PriO])
Subsystem: Silicon Image, Inc. (formerly CMD Technology Inc) PCI0649
Flags: bus master, medium devsel, latency 64, IRQ 52
I/O ports at a0e8 [size=8]
I/O ports at a0f4 [size=4]
I/O ports at a0e0 [size=8]
I/O ports at a0f0 [size=4]
I/O ports at a0d0 [size=16]
Capabilities: [60] Power Management version 2
0000:a0:03.0 Ethernet controller: Intel Corp. 82540EM Gigabit Ethernet Controller (rev 02)
Subsystem: Hewlett-Packard Company: Unknown device 1274
Flags: bus master, 66MHz, medium devsel, latency 128, IRQ 51
Memory at 00000000d0000000 (32-bit, non-prefetchable) [size=128K]
I/O ports at a080 [size=64]
Capabilities: [dc] Power Management version 2
Capabilities: [e4] PCI-X non-bridge device.
Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
0000:a0:04.0 Multimedia audio controller: Fortemedia, Inc Xwave QS3000A [FM801] (rev b2)
Subsystem: Fortemedia, Inc: Unknown device 1319
Flags: bus master, medium devsel, latency 128
I/O ports at a000 [size=128]
Capabilities: [dc] Power Management version 1
0000:a0:04.1 Input device controller: Fortemedia, Inc Xwave QS3000A [FM801 game port] (rev b2)
Subsystem: Fortemedia, Inc: Unknown device 1319
Flags: bus master, medium devsel, latency 128
I/O ports at a0c0 [size=16]
Capabilities: [dc] Power Management version 1
0000:c0:01.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1010 66MHz Ultra3 SCSI Adapter (rev 01)
Subsystem: Hewlett-Packard Company: Unknown device 1330
Flags: bus master, 66MHz, medium devsel, latency 192, IRQ 53
I/O ports at c000 [size=256]
Memory at 00000000e0022000 (64-bit, non-prefetchable) [size=1K]
Memory at 00000000e0020000 (64-bit, non-prefetchable) [size=8K]
Expansion ROM at 00000000e0000000 [disabled] [size=128K]
Capabilities: [40] Power Management version 2
On 03.12, Martin Schlemmer wrote:
> On Fri, 2005-03-11 at 23:17 +0000, J.A. Magallon wrote:
> > On 03.12, Martin Schlemmer wrote:
> > > On Fri, 2005-03-11 at 22:46 +0000, J.A. Magallon wrote:
> > > > On 03.11, Dave Jones wrote:
> > > > > On Fri, Mar 11, 2005 at 10:11:08PM +0000, J.A. Magallon wrote:
> > > > > >
...
> > >
> >
> > Just curiosity, what says your /proc/driver/nvidia/agp/status ?
> >
>
> -----
> # cat /proc/driver/nvidia/agp/status
> Status: Enabled
> Driver: AGPGART
> AGP Rate: 8x
> Fast Writes: Enabled
> SBA: Enabled
> -----
>
Ah, I got it. The AGPRate is a _limit_ and is not active by default. It is
not the rates to probe...
If you activate it and dont change to 15 you limit the driver to x4.
If you do nothing, no limit.
Thanks.
--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandrakelinux release 10.2 (Cooker) for i586
Linux 2.6.11-jam3 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-6mdk)) #3
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. Does no-one read dmesg output any more ?
That loop would only get executed when you enable AGP, which I think
would generally only happen when starting X with DRI enabled.
Paul.
On Fri, 2005-03-11 at 23:17 +0000, J.A. Magallon wrote:
> On 03.12, Martin Schlemmer wrote:
> > On Fri, 2005-03-11 at 22:46 +0000, J.A. Magallon wrote:
> > > On 03.11, Dave Jones wrote:
> > > > On Fri, Mar 11, 2005 at 10:11:08PM +0000, 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.0 support. :)
> > > > > >
> > > > >
> > > > > I think it is not a G5 only problem. I have a x8 card, a x8 slot, but
> > > > > agpgart keeps saying this:
> > > > >
> > > > > Mar 11 23:00:28 werewolf dm: Display manager startup succeeded
> > > > > Mar 11 23:00:29 werewolf kernel: agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
> > > > > Mar 11 23:00:29 werewolf kernel: agpgart: reserved bits set in mode 0xa. Fixed.
> > > > > Mar 11 23:00:29 werewolf kernel: agpgart: X passes broken AGP2 flags (2) in AGP3 mode. Fixed.
> > > > > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 0000:00:00.0 into 4x mode
> > > > > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 0000:01:00.0 into 4x mode
> > > > > Mar 11 23:00:29 werewolf kernel: agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
> > > > > Mar 11 23:00:29 werewolf kernel: agpgart: reserved bits set in mode 0xa. Fixed.
> > > > > Mar 11 23:00:29 werewolf kernel: agpgart: X passes broken AGP2 flags (2) in AGP3 mode. Fixed.
> > > > > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 0000:00:00.0 into 4x mode
> > > > > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 0000:01:00.0 into 4x mode
> > > > >
> > > > > The nvidia driver (brand new 1.0-7167, now works with stock -mm) tells me
> > > > > it is in x8 mode, but i suspect it lies....
> > > > >
> > > > > Will try your patch right now.
> > > >
> > >
> > > Looks fine, now I got:
> > >
> > > agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
> > > agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
> > > agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
> > > agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
> > > agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
> > > agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
> > >
> > > werewolf:~> lspci
> > > 00:00.0 Host bridge: Intel Corporation 82875P/E7210 Memory Controller Hub (rev 02)
> > > 00:01.0 PCI bridge: Intel Corporation 82875P Processor to AGP Controller (rev 02)
> > > ...
> > > 01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1)
> > >
> > > BTW, I had to patch the nVidia driver. It just tries up to x4 AGP...
> > >
> >
> > New and old one works fine with Paul's patch:
> >
> > --old--
> > agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
> > agpgart: X tried to set rate=x12. Setting to AGP3 x8 mode.
> > agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
> > agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
> > -------
> >
> > (ok, so old driver is a bit dodgy)
> >
> > --new--
> > agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
> > agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
> > agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
> > -------
> >
>
> Just curiosity, what says your /proc/driver/nvidia/agp/status ?
>
-----
# cat /proc/driver/nvidia/agp/status
Status: Enabled
Driver: AGPGART
AGP Rate: 8x
Fast Writes: Enabled
SBA: Enabled
-----
--
Martin Schlemmer
On Fri, 2005-03-11 at 22:46 +0000, J.A. Magallon wrote:
> On 03.11, Dave Jones wrote:
> > On Fri, Mar 11, 2005 at 10:11:08PM +0000, 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.0 support. :)
> > > >
> > >
> > > I think it is not a G5 only problem. I have a x8 card, a x8 slot, but
> > > agpgart keeps saying this:
> > >
> > > Mar 11 23:00:28 werewolf dm: Display manager startup succeeded
> > > Mar 11 23:00:29 werewolf kernel: agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
> > > Mar 11 23:00:29 werewolf kernel: agpgart: reserved bits set in mode 0xa. Fixed.
> > > Mar 11 23:00:29 werewolf kernel: agpgart: X passes broken AGP2 flags (2) in AGP3 mode. Fixed.
> > > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 0000:00:00.0 into 4x mode
> > > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 0000:01:00.0 into 4x mode
> > > Mar 11 23:00:29 werewolf kernel: agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
> > > Mar 11 23:00:29 werewolf kernel: agpgart: reserved bits set in mode 0xa. Fixed.
> > > Mar 11 23:00:29 werewolf kernel: agpgart: X passes broken AGP2 flags (2) in AGP3 mode. Fixed.
> > > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 0000:00:00.0 into 4x mode
> > > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 0000:01:00.0 into 4x mode
> > >
> > > The nvidia driver (brand new 1.0-7167, now works with stock -mm) tells me
> > > it is in x8 mode, but i suspect it lies....
> > >
> > > Will try your patch right now.
> >
>
> Looks fine, now I got:
>
> agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
> agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
> agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
> agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
> agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
> agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
>
> werewolf:~> lspci
> 00:00.0 Host bridge: Intel Corporation 82875P/E7210 Memory Controller Hub (rev 02)
> 00:01.0 PCI bridge: Intel Corporation 82875P Processor to AGP Controller (rev 02)
> ...
> 01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1)
>
> BTW, I had to patch the nVidia driver. It just tries up to x4 AGP...
>
New and old one works fine with Paul's patch:
--old--
agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
agpgart: X tried to set rate=x12. Setting to AGP3 x8 mode.
agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
-------
(ok, so old driver is a bit dodgy)
--new--
agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
-------
--
Martin Schlemmer
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 effort to trim the
>dmesg boot text down to what users really *need* to know. We could
>retain most of the other stuff at a different log-level which would
> be exposed by a kernel command line parameter or something during
> boot for when people have problems.
With all due respect to the people that it will take to make that
happen, thats a heck of a good idea. However, what I'd like to see
is a difference between whats output to the screen during bootup (set
that to relatively quiet unless a problem is hit) but to continue to
log the full output to /var/log/dmesg-$date when the ring is dumped
and syslog can then take the rest of it.
Overwriting /var/log/dmesg at every boot removes a lot of forensic
info that could come in handier than sliced bread and bottled beer at
times. Let rotatelog take care of deleting anything more than a week
out of date so they don't take up space once their usefullness has
expired.
How many 'aye's do I hear?
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
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 have barfed loudly when it hit
>> this check during boot. Does no-one read dmesg output any more ?
>
>That loop would only get executed when you enable AGP, which I think
>would generally only happen when starting X with DRI enabled.
>
>Paul.
Which I am doing here I believe, and my current dmesg ring does go
back to the tail end of whats in /var/log/dmesg, but: Its got a lot
of crap about tainted kernels, AND its not by any means all from the
stuff that pcHDTV-1.6 builds and inserts into the /var/modules/`name
-r`/kernel/drivers etc etc directories. Its also bitching about
nearly every i2c module loaded! With lines along the general theme
of this:
--------------
i2c_core: No versions for exported symbols. Tainting kernel.
i2c_algo_bit: No versions for exported symbols. Tainting kernel.
kobject_register failed for i2c_algo_bit (-17)
[<c020d487>] kobject_register+0x57/0x60
[<c012c3a0>] mod_sysfs_setup+0x50/0xb0
[<c012d589>] load_module+0x889/0xb70
[<c012d8c6>] sys_init_module+0x56/0x220
[<c01026d9>] sysenter_past_esp+0x52/0x75
-----------
and yet, gkrellm, and sensors are both working quite nicely. WTH?
I am rather certain that versioning info in the modules IS turned on
in the .config:
However, a grep of .config makes a liar out of me, it is NOT set:
[root@coyote linux-2.6.11.2]# grep VERSION .config
CONFIG_LOCALVERSION=""
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
Rebuild coming up. :(
>-
>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/
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
> 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 the bridge.
>
> HP boxes certainly don't have that (zx6000 sample below). I guess
> it wouldn't be the first time we deviated from a spec ;-)
We are basically hitting a "hole" in the PCI spec itself :) It doesn't
really defines how a host bridge can expose itself as a device. That
means that in most cases, the host bridge either isn't visible at all,
or is as a random device at the first level (which makes it a sibling of
other devices, quite broken ....). Also, there is no standard "devfn"
for it, so it can be anywhere and there is no "simple" way of knowing
which devie is actually the host in a generic way. Most of the time,
looking for a devie with the class "host bridge" will work, but it's not
guaranteed. Some hosts also expose the AGP stuff differently.
In some cases, like Apple U3 HT host, it also has a set of registers
that mimmic a PCI config space, but aren't implemented in the PCI config
space proper, and thus, unless you add special case to your pci_ops, you
won't see it on the bus. (Apple's AGP host appears as a device on it's
own bus though).
So while AGP requires a set of PCI config space registers with the AGP
capabilities for the host, it's very possible that you have those in a
space that don't appear on the PCI (just as MMIO registers on your
bridge somewhere), or whatever other fancy setup. In fact, that part of
the spec hits the above hole, so I wouldn't be surprised if vendors
decided to ignore it and do fancy things.
Ben.
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 the
AGP interface circuitry as a PCI-to-PCI bridge. You don't have to do
it that way, but in any case you need some sort of PCI device to
represent the target (host) end of the AGP link.
> have TWO PCI devices that have the AGP capability, one for the AGP
> device and one for the bridge.
Yes, exactly.
> HP boxes certainly don't have that (zx6000 sample below). I guess
> it wouldn't be the first time we deviated from a spec ;-)
>
> Can you point me to the relevant section?
In the AGP 2.0 spec, the clearest statement I can find is in section
6.1.5, on page 248, where it says "Configuration registers are used by
the operating system to initialize A.G.P. features. These features
must be supported by both A.G.P. master and target devices in the
following registers.", followed by a description of various PCI config
space registers. In the context, "configuration registers" means
registers in the config space of a PCI device. The AGP 3.0 spec is a
delta from the AGP 2.0 spec and doesn't revoke that requirement
anywhere that I could see.
Paul.
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 still seemed to
> > want that.
>
> I think Mike posted it but hasn't submitted it to Dave yet since it needed
> another change that only just made it into the ia64 tree.
>
> Jesse
>
Hi,
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.
Yours,
Mike
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) 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't submitted it to Dave yet since it needed
> > another change that only just made it into the ia64 tree.
> >
> > Jesse
> >
> Hi,
> 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 patch in my queue though, so I can push that along.
Are those headers in mainline yet ?
Dave
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 controlling the target (host) side of the AGP
> > bus. In other words you are required to have a PCI device to
> > represent the host side of the AGP bus, with a capability structure
> > in
> > its config space which contains the standard AGP registers.
>
> 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 the bridge.
Note that the PPC processor bus can connect to multiple
"north bridges" (or other PPCs) at the same time. It's
not a point-to-point bus. It sounds like the AGP bridge
in question sits directly on the processor bus, in which
case there would not necessarily be any equivalent to the
PCI configuration registers for the bridge itself.
Does anyone know offhand what part number this AGP bridge is or
who makes it?
ken
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 15:27:37 2004
> @@ -132,6 +132,10 @@ static __inline__ int atomic_dec_and_tes
> {
> unsigned char c;
>
> + if (!atomic_read(v)) {
> + printk("BUG: atomic counter underflow at:\n");
> + dump_stack();
> + }
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 simply aren't historically
well-defined for negative values (sparc used to limit them to 24 bits), so
a negative thing would always be a bug, I think.
Linus
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 simply aren't historically
> well-defined for negative values (sparc used to limit them to 24 bits), so
> a negative thing would always be a bug, I think.
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().
Thanks.
--
OGAWA Hirofumi <[email protected]>
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 out,
Linus
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 ?
> >
> > 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 or put. When you exit the loop with a valid pci_dev, though,
> > you should definitely put() it after you're done with it, but this is
> > something that should be done only for that specific instance and after
> > you are finished with it...
>
> Yeah. Makes perfect sense now I've had it spelled out for me :-)
> I think Linus is right though that some extra bullet-proofing in kref_put
> to BUG() if it goes negative would've caught this. I wonder if anyone
> else has fallen into this trap.
It can't go negative. If it hits zero, the object is freed and cleaned
up. If you have slab debugging enabled, the next time you try to access
this pointer, boom.
So no atomic negative checks will help with kref/kobject code, sorry.
thanks,
greg k-h
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 patch in my queue though, so I can push that along.
>
> Are those headers in mainline yet ?
Yeah, I think it's all there now. Looks like Linus did a pull from ia64
recently, so it *should* all build.
Thanks,
Jesse
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 got swamped with other stuff, and dropped the ball.
> > I still have the patch in my queue though, so I can push that along.
> >
> > Are those headers in mainline yet ?
>
> Yeah, I think it's all there now. Looks like Linus did a pull from ia64
> recently, so it *should* all build.
Ok, pushed out to bk://linux-djb.bkbits.net/agpgart
Linus, please pull.
Dave
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 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 patch in my queue though, so I can push that along.
> > >
> > > Are those headers in mainline yet ?
> >
> > Yeah, I think it's all there now. Looks like Linus did a pull from ia64
> > recently, so it *should* all build.
>
> Ok, pushed out to bk://linux-djb.bkbits.net/agpgart
Erk, Personality crisis, or an unfortunate typo. s/djb/dj/ obviously.
Dave
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 that both I and
> > > Dave did it.
> >
> > I stole this from -mm.
>
> 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 dmesg output any more ?
Its way too long these days. Like "so long it overflows even enlarged
buffer". We should prune these messages down to "one line per hw
device or serious problems only".
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
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 during boot. Does no-one read dmesg output any more ?
>
> Its way too long these days. Like "so long it overflows even enlarged
> buffer". We should prune these messages down to "one line per hw
> device or serious problems only".
especially if you turn on encryption options. I can understand that output
being useful for debugging, but there should be a way to not deal with it
in the normal case.
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
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 dmesg output any more ?
> >
> >Its way too long these days. Like "so long it overflows even enlarged
> >buffer". We should prune these messages down to "one line per hw
> >device or serious problems only".
>
> especially if you turn on encryption options. I can understand that output
> being useful for debugging, but there should be a way to not deal with it
> in the normal case.
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 testing.
"New kernel 2.8.17 came: 3 errors, 135 warnings, 1890 lines of dmesg
junk".
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
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 testing.
>
> "New kernel 2.8.17 came: 3 errors, 135 warnings, 1890 lines of dmesg
> junk".
> Pavel
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...
Jesse
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
> > junk".
> > Pavel
>
> 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...
I know about "quiet". You can 2> /dev/null on warnings, too ;-), and
quiet is quite equivalent... And I'm about fed enough to start that
personal crusade. OTOH "POSIX conformance testing by UniFix" is gone
now ;-).
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
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 is, this comes up every once in a while (pretty often,
actually), but the bulk of those messages _do_ end up being useful. For
certain classes of bugs, I almost invariably ask for the bootup messages:
the PCI interrupt routing printou stuff is absolutely invaluable.
In fact, even the ones that have no "information" end up often being a big
clue about where the hang happened.
So yes, when things work (and hey, that's happily 99.9% of the time) they
are almost all worthless. But just _one_ case where they help is a big
deal. So don't say "most people don't care", because that is a totally
irrelevant argument. It's not "most people" who matter. It's not even
kernel developers who matter - they can know how to enable the stuff if
they ever see a problem. The _only_ people who matter are the very
occasional regular users that see problems.
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 then hide it with the graphical bootup
for "most people".
Linus
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 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
> > junk".
> > Pavel
>
> 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...
As long as the patches to remove/quiten various texts go through the
various subsystem maintainers, this shouldn't be a problem, though
I imagine there will be some resistance to some parts.
One of the biggest offenders is ACPI. On my desktop, that alone
accounts for 10% of the messages since boot.
(12:05:09:davej@delerium:~)$ dmesg -s 128000 | grep ^ACPI | wc -l
50
(12:05:18:davej@delerium:~)$ dmesg -s 128000 | wc -l
500
On SMP there's way too much noise.
We could do some checks in the CPU init code to not print any
of the init junk if its the same as the boot CPU.
That should be fairly trivial, and would reduce quite a few messages.
Of the 500 messages in my dmesg scrollback right now, 412 of them
are unique. Removing some of this duplication sounds like an
excellent place to begin.
Another way to save some text could be to cluster multiple lines
so that instead of..
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
we have
ACPI: IRQs 0,2,9 used by override.
(Whatever the hell that message means anyway -- this one just used
as an example).
Dave
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 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 then hide it with the graphical bootup
> for "most people".
Ok, and for the development kernel that makes a lot of sense. But as we've
seen from this thread, leaving in old printks that were once useful but no
longer are tends to clutter things up and hide real errors. I'd like to see
us get better about that--reporting real errors better and keeping the junk
to a minimum.
Jesse
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 once in a while (pretty often,
> actually), but the bulk of those messages _do_ end up being useful. For
> certain classes of bugs, I almost invariably ask for the bootup messages:
> the PCI interrupt routing printou stuff is absolutely invaluable.
>
> In fact, even the ones that have no "information" end up often being a big
> clue about where the hang happened.
Problem is that by now we have so much information that valuable
scrolls up. Users start to missing trace dumps in bootup phase because
it just scrolls away too quickly.
I know that "no information" messages can be valuable, but they make
messages with usefull information less likely to be noticed. And
people start doing ugly stuff like
*** This is really
*** important message
when they want their messages to be actually seen. Perhaps we should
reduce ammount of that "no information" messages? I particulary hate
"XXX driver registered" even when that driver has no hardware. Kernel
is quite unlikely to hang at that point.
> 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 then hide it with the graphical bootup
> for "most people".
Does it mean that fbsplash done right would be ok for mainline? ;-).
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
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 gets better
> though...
But people who wants to know what has been and what hasn't been detected should
start looking at sysfs, shouldn't them?. dmesg is not reliable *at all*, sometimes
when you rmmod something, it doesn't put anything in dmesg, but it did when it was
loaded, so you'll see some messaje in the printk saying "foo was loaded", but it isn't really
loaded
Personally I don't use dmesg anymore to look "what devices are being handled by the
kernel", just sysfs and /proc files. I only look at dmesg when "something goes wrong"
and it doesn't works properly. IMHO dmesg in linux is just a "debug tool" (unlike the BSDs,
who seem to have very strict rules for dmesg messages) and it's nice that it's verbose,
and it could even be "quiet" by default - people who have problems and can't look at sysfs
could add a "noquiet" boot option or run dmesg if it boots. IIRC is what solaris and other
people do by default. Why should people look at all that "horrid" debug info everytime
they boot, except when they have a problem?
[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, people would start to wonder more about why Linux takes so much
longer than XP to boot.
Lee
> 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 radeonfb which will be
very verbose in a first release, but that will be necessary to track
down all the various issues with monitor detection, BIOSes telling crap
about connectors etc...
Ben.
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 admit going backward here with my new radeonfb which will be
> very verbose in a first release, but that will be necessary to track
> down all the various issues with monitor detection, BIOSes telling crap
> about connectors etc...
This isn't the problem, the fact that if I have all the encryption modes
turned on I get several hundred lines of output telling me that it tested
the encryption and got the result it expected is.
you are turning up the verbosity becouse it's needed, if you don't turn it
down in a few releases (assuming you fix the problems by then ;-) then you
would become part of the problem.
back in the 1.3/2.0 days when I started useing linux I was a PC repair
technition and when working on the windows PC's I would use a linux boot
disk to identify the hardware that was in the machine based on the dmesg
output (and the ports things were on) so that I could configure the
windows drivers. So it's not that I can't understand the value of the
dmesg output, it's that there is now so much additional data that it's no
longer reasonable to see what's going on.
when the boot dmesg output overflows the 500 line buffer of a VGA console
so that you can not scroll back and see the messages by the time the
system starts things have gotten too verbose.
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
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 with my new radeonfb which will be
> very verbose in a first release, but that will be necessary to track
> down all the various issues with monitor detection, BIOSes telling crap
> about connectors etc...
I'd say that's okay, as long as you remove the messages
afterwards. Perhaps "cleanup printks just before you remove dependency
on CONFIG_EXPERIMENTAL is right thing to require"?
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
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 then hide it with the graphical bootup
> for "most people".
Loading the usb drivers on my machine dumps 155 lines into dmesg. Surely
that's a bit excessive?
But really for me it's the network drivers that actually annoy me. They dump
stuff into dmesg during the regular course of operation. As a result it
doesn't take long until the boot messages leave the buffer. Of course they're
in the log files, but running dmesg and getting screenfulls of the same
messages about boring network events over and over just annoys me.
--
greg
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 start to wonder more about why Linux takes so much
> longer than XP to boot.
two things
1. linux shouldn't take longer to boot then windows (and if properly
configured it doesn't)
2. there's a _long_ way between the current situation where a driver can
spew 500+ lines of logging and there being so little logging that people
don't know what's going on.
if you are on a slow console (say a serial console) just letting the boot
messages scroll by can take quite a while today.
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
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 boot time will be reduced to the half
with Longhorn. While we already know how ms marketing team works, 50% looks
like a lot. Is there a good place to discuss what could be done in the linuxland to
improve things? It doesn't looks like a couple of optimizations will be enought...
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 XP to boot.
>
> By the way, Microsoft seems to be claiming that boot time will be reduced to the half
> with Longhorn. While we already know how ms marketing team works, 50% looks
> like a lot. Is there a good place to discuss what could be done in the linuxland to
> improve things? It doesn't looks like a couple of optimizations will be enought...
>
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 do
NOW.
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 based on this information so on the next boot you just
do one big streaming read. The patent side has been discussed and there
seems to be plenty of prior art.
Someone needs to just do it. All the required information is right
there.
Lee
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 XP to boot.
>
> By the way, Microsoft seems to be claiming that boot time will be reduced to the half
> with Longhorn. While we already know how ms marketing team works, 50% looks
> like a lot. Is there a good place to discuss what could be done in the linuxland to
> improve things? It doesn't looks like a couple of optimizations will be enought...
Make software suspend work 100% of the time and rename "resume" to
"fastboot".
--
Zan Lynx <[email protected]>
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
>> longer than XP to boot.
>
>By the way, Microsoft seems to be claiming that boot time will be reduced to the half
>with Longhorn. While we already know how ms marketing team works, 50% looks
>like a lot. Is there a good place to discuss what could be done in the linuxland to
>improve things? It doesn't looks like a couple of optimizations will be enought...
Considering msft don't do full options hardware detection until
after GUI shell is up, next speed up could simply be start from
hibernate? They already do a hardware signature, and if hardware
changed you may need a new license anyway :-) Pay per cold boot?
Noisy startup? 2.6 has good solution in default kernel build,
display milestones during startup or super quiet loader option
passed from boot? "dmesg -qq" thru "dmesg -vv" stir anyone?
Grant.
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 based on this information so on the next boot you just
> do one big streaming read. The patent side has been discussed and there
> seems to be plenty of prior art.
>
> Someone needs to just do it. All the required information is right
> there.
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. The results are
quite impressive, though the absense of any kind of tool to reorganise
the layout means that once a few packages are installed/removed, the layout is
no longer optimal.
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 ?
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.
Dave
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://www.zip.com.au/~akpm/ext3-reloc-page.patch
Against 2.4.18, untested ;)
> 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.
Fun project.
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.
What are the cons of using "all of" the RAM at boot time to
cache the boot disk?
--
Giuseppe "Oblomov" Bilotta
Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
(Roger Waters)
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 do
> NOW.
>
> 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 based on this information so on the next boot you just
> do one big streaming read. The patent side has been discussed and there
> seems to be plenty of prior art.
>
> Someone needs to just do it. All the required information is right
> there.
Hm. My previous WinXP box (this same machine, different hard
disk) was VERY fast in booting WinXP, out of the box. After two
years of usage, installations, uninstallations and whatnot it
had become slow as molasses. The Linux installation on the SAME
machine was not affected.
--
Giuseppe "Oblomov" Bilotta
Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
(Roger Waters)
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 too hard (a libc wrapper could do it, right?) But how could you get
track of "code page faults"? Perhaps it's not worth of it "preloading" the parts of the
executable (and linked libraries) used and it's much simpler to read everything? (Andrew
Morton suggested in the past using mincore(2) IIRC)
Altought even if you optimize the disk's layout and pre-read everything you need, a big
problem is the initscript scripts. I don't think it's init fault, handling absolutely _everything_
trough scripts is not going to help, specially when all^Wmost of linux systems use a
shell which claims to be "too big and too slow" in its own man page ;)
There're some shells (like zsh) which can "compile" scripts and generate "bytecode"
I wonder if that would help (zsh seems to handle bash scripts so it may be interesting
to try) Although like many people suggested, microsoft's "magic wand" to speed up
everything could have been "lets save a suspend image of the system just before
detecting new non-critical hardware and use it to boot the system". I guess its not
possible to save/load suspend images to/from a filesystem?
So, a list of steps needed (which doesn't means I'm voluntering to do all of them 8) could
be:
1- Be able to keep track of what a process does in its whole life, or in the first N
seconds (optimizing system's startup it's nice, but being able to speed up how
fast openoffice loads when the system is already up would be even better).
Using LD_PRELOAD=/something command could do this?
2- Get the on-disk info, port Andrew Morton's "move block" patch to 2.6, and use it
to reorganize the disk's layout periodically (specially when package managers install
something, ie: if people runs mozilla very often, mozilla files should be kept in the same
place of the disk than all its libraries), using stadistics from step 1
3 - Create a tool which looks at all the data got from step 1 and "preloads" optimally from
disk all the neccesary data (ie: using the path of one program, or several if you want
to run two programs at the same time), with the reorganization done in step 2 it'd be
even faster. Boot scripts would be just another user, and gnome and kde could use it
too for single programs. If the tool detects that a program has been changed (looking
at the "changed date" field for example) it could launch the process with the tools from
step 1, so the stadistics get regenerated again.
Is there something crazy in this idea?
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 the data off the disk
> > in one big chunk, and run almost entirely from cache.
>
> What are the cons of using "all of" the RAM at boot time to
> cache the boot disk?
It's memory that's otherwise unused. Once you start using the system
anything cached will get reclaimed as its needed.
Dave
> > 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 "loaded at boot" stuff in the first <amount of RAM>
bytes of the hard disk?
--
Giuseppe "Oblomov" Bilotta
Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
(Roger Waters)
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 needed.
>
> So there is no substantial loss? IOW, it would suffice to have
> all the "loaded at boot" stuff in the first <amount of RAM>
> bytes of the hard disk?
It very likely also needs to be contiguous on-disk (Ie, no in-file
fragmentation). You want to limit the amount of seeking that gets
done so the drive readahead just performs continuous reads.
Dave
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. While we already know how ms marketing team works, 50% looks
> > like a lot. Is there a good place to discuss what could be done in the linuxland to
> > improve things? It doesn't looks like a couple of optimizations will be enought...
> >
>
> 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 do
> NOW.
>
> 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 cure you'd want it to be.
Only solution seems to be "do less during boot".
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
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 cure you'd want it to be.
>
>Only solution seems to be "do less during boot".
What about the init scripts? They are all spawned from the master one,
they all spawn zillions of simple utilities. And udev startup time under
SuSE 9.2 is just awful. It might be the Unix way but it is killing the
boot process.
What I tried to do once, and I even contacted somebody from SuSE with a
working proof of concept code is the following:
Master init script written in Perl. All the service init scripts rewritten
in Perl which can be invoked independently, but they all follow the
convention and implement functions such as start() stop() reload() etc..
Then the master init script includes one at a time and "evals" them (well
just the function which it is interested in). Since everything is written
in Perl there is no need to invoke external greps, seds, cuts etc.. And
rc.status was also only processed once (by the master init script).
It was fast but I don't have any exact numbers because I only implemented
rc, rc.boot, rc.status and sshd (AFAIR) before giving up. I think I should
be able to dig that code from somewhere if someone is interested...