date:20050311

mike kravetz <[EMAIL PROTECTED]> wrote:
>
> Here is another version of the patch.  This one gets the cell sizes
>  before extracting the cells.  I have made this change to existing
>  code in the file, as well as the code I added.  This works fine on
>  my 720, but so did the previous patch. :)  I'd appreciate it if
>  someone could touch test this on a machine known to break with
>  the previous version (such as G5).

That works, thanks.
-
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/

Re: [ANNOUNCE][RFC] PlugSched-3.0.2 for 2.6.11

2005-03-11 Thread Peter Williams

Peter Williams wrote:
A patch of PlugSched-3.0.2 (containing ingosched, staircase, 
spa_no_frills and zaphod CPU schedulers) against a 2.6.11 kernel is
available for download from:

 

PlugSched's version number has been bumped to 3.0.2 as it contains minor 
bug fixes and a patch for this version against a 2.6.10 kernel is 
available at:

 

and against a CKRM modified 2.6.10 kernel at:
 
A bug fix update, PlugSched-3.0.2.1, of the 2.6.11 version is available at:

and an incremental patch from 3.0.2 to 3.0.2.1 is available at:

Peter
--
Peter Williams   [EMAIL PROTECTED]
"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
-
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/

Re: [RFC][PATCH] new timeofday arch specific hooks (v. A3)

On Fri, 2005-03-11 at 17:25 -0800, john stultz wrote:
> All,
>   This patch implements the minimal architecture specific hooks to enable
> the new time of day subsystem code for i386, x86-64, ia64, ppc32 and
> ppc64. It applies on top of my linux-2.6.11_timeofday-core_A3 patch and
> with this patch applied, you can test the new time of day subsystem. 
> 
> Basically it configs in the NEWTOD code and cuts alot of code out of the
> build via #ifdefs. I know, I know, #ifdefs' are ugly and bad, and the
> final patch will just remove the old code. For now this allows us to be
> flexible and easily switch between the two implementations with a single
> define.
> 
> New in this version:
> o ppc32 arch code (by Darrick Wong. Many thanks to him for this code!)
> o ia64 arch code (by Max Asbock. Many thanks to him for this code!)
> o minor cleanups moving code between the arch and timesource patches
> 
> Items still on the TODO list:
> o s390 arch port (hey Martin: nudge, nudge :)
> o arch specific vsyscall/fsyscall interface
> o other arch ports (volunteers wanted!)

I'm not what the impact will be with the vDSO implementation of
gettimeofday which relies on the bits in systemcfg (tb_to_xs etc...).

Currently, the userland code uses the exact same bits as the kernel
code, and thus, we have a garantee of getting the same results from
both. Also, our "special" ppc_adjtimex will also update our offset and
scale factor (with appropriate barriers) in a way that applies to both
the kernel/syscall gettimeofday and the vDSO implementation. I'm not
sure this is still true with your patch.

I suppose I'll have to dig into the details sometime next week..

Ben

-
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/

Re: Average power consumption in S3?

On Fri, 2005-03-11 at 23:58 -0500, Theodore Ts'o wrote:

> If this is true, then ATI probably won't be able to tell us anything
> useful, so we're only going to find out if people in the Thinkpad
> division are willing to tell us something useful (and their track
> record for being helpful has not been particularly stellar).
> 
> And what I was thinking about doing was having the CONFIG option only
> do it for machines that were detected as being IBM Thinkpads, not all
> Radeon chips.  The blacklist would be for specific IBM thinkpad
> models; what I'm guessing here is that it's likely that all or most
> modern IBM thinkpads are going to be wired the same way on the
> motherboard.  

Fine with me then.

-
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/

Re: 2.6.11: USB broken on nforce4, ipv6 still broken, centrino speedstep even more broken than in 2.6.10


(Restoring email headers.  Please always use reply-to-all)

Robert Hancock <[EMAIL PROTECTED]> wrote:
>
> Felix von Leitner wrote:
> > My new nForce 4 mainboard has 10 or so USB 2.0 outlets.  In Windows,
> > they all work.  In Linux, two of them work.  Putting my USB stick or
> > anything else in one of the others produces nothing in Linux.
> > Apparently no IRQ getting through or something?
> 
> Likely similar to the problem I reported in this thread on 
> linux-usb-devel - the patch that David Brownell posted fixed the problem 
> for me..
> 
> http://sourceforge.net/mailarchive/message.php?msg_id=10755097
> 
> 
> -
> 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/
-
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/

A custom Logo that expresses your company! (593811620)

2005-03-11 Thread Tod Crabtree

Our art team creates a custom logo for you, based on your needs.  



Years of experience have taught us how to create a logo that makes a statement 
that is unique to you. 

 In a professional manner we learn about your image and how you would like the 
world to perceive you and your company.
With this in formation we then create a logo that is not only unique but 
reflects the purpose of you and your company. 
 
For value and a logo that reflects your image, take a few minutes and visit Try 
Logos!
http://www.try-logos-design.com/



 
S incerely   
Logo Design Team 







-
{UNSUBSCRIBE_PREFIX}
http://www.try-logos-design.com/uns.php
-
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/

Re: 2.6.11: USB broken on nforce4, ipv6 still broken, centrino speedstep even more broken than in 2.6.10

2005-03-11 Thread Robert Hancock

Felix von Leitner wrote:
My new nForce 4 mainboard has 10 or so USB 2.0 outlets.  In Windows,
they all work.  In Linux, two of them work.  Putting my USB stick or
anything else in one of the others produces nothing in Linux.
Apparently no IRQ getting through or something?
Likely similar to the problem I reported in this thread on 
linux-usb-devel - the patch that David Brownell posted fixed the problem 
for me..

http://sourceforge.net/mailarchive/message.php?msg_id=10755097
-
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/

Re: Average power consumption in S3?

2005-03-11 Thread Theodore Ts'o

On Sat, Mar 12, 2005 at 10:48:21AM +1100, Benjamin Herrenschmidt wrote:
> 
> I'm hesitant to switch a whitelist because of a couple of settings in
> there that are specific to the way the chip is wired on the mobo.
> Apparently, thinkpads are similar enough to Macs, but I wouldn't bet on
> this beeing "commmon"...

If this is true, then ATI probably won't be able to tell us anything
useful, so we're only going to find out if people in the Thinkpad
division are willing to tell us something useful (and their track
record for being helpful has not been particularly stellar).

And what I was thinking about doing was having the CONFIG option only
do it for machines that were detected as being IBM Thinkpads, not all
Radeon chips.  The blacklist would be for specific IBM thinkpad
models; what I'm guessing here is that it's likely that all or most
modern IBM thinkpads are going to be wired the same way on the
motherboard.  

- Ted
-
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/

Re: A new 10GB Ethernet Driver by Chelsio Communications

2005-03-11 Thread Jeff Garzik

Andrew Morton wrote:
Christoph Lameter <[EMAIL PROTECTED]> wrote:
A Linux driver for the Chelsio 10Gb Ethernet Network Controller by
Chelsio (http://www.chelsio.com). This driver supports the Chelsio N210
NIC and is backward compatible with the Chelsio N110 model 10Gb NICs.

Thanks, Christoph.
The 400k patch was too large for the vger email server so I have uploaded it to
 http://www.zip.com.au/~akpm/linux/patches/stuff/a-new-10gb-ethernet-driver-by-chelsio-communications.patch
step 1:  kill all the OS wrappers.
And do you really need hooks for multiple MACs, when only one MAC is 
really supported?  Typically these hooks are at a higher level anyway -- 
struct net_device.

Jeff
-
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/

Re: [PATCH] break_lock forever broken

Hugh Dickins <[EMAIL PROTECTED]> wrote:
>
> lock->break_lock is set when a lock is contended, but cleared only in
>  cond_resched_lock.  Users of need_lockbreak (journal_commit_transaction,
>  copy_pte_range, unmap_vmas) don't necessarily use cond_resched_lock on it.
> 
>  So, if the lock has been contended at some time in the past, break_lock
>  remains set thereafter, and the fastpath keeps dropping lock unnecessarily.
>  Hanging the system if you make a change like I did, forever restarting a
>  loop before making any progress.
> 
>  Should it be cleared when contending to lock, just the other side of the
>  cpu_relax loop?  No, that loop is preemptible, we don't want break_lock
>  set all the while the contender has been preempted.  It should be cleared
>  when we unlock - any remaining contenders will quickly set it again.
> 
>  So cond_resched_lock's spin_unlock will clear it, no need for it to do
>  that; and use need_lockbreak there too, preferring optimizer to #ifdefs.
> 
>  Or would you prefer the few need_lockbreak users to clear it in advance?
>  Less overhead, more errorprone.

This patch causes a CONFIG_PREEMPT=y, CONFIG_PREEMPT_BKL=y,
CONFIG_DEBUG_PREEMPT=y kernel on a ppc64 G5 to hang immediately after
displaying the penguins, but apparently not before having set the hardware
clock backwards 101 years.

After having carefully reviewed the above description and having decided
that these effects were not a part of the patch's design intent I have
temporarily set it aside, thanks.

-
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/

[BK PATCHES] 2.6.x net driver fixes

2005-03-11 Thread Jeff Garzik

 Please do a

bk pull bk://gkernel.bkbits.net/net-drivers-2.6

This will update the following files:

 drivers/net/lance.c|1 +
 drivers/net/r8169.c|   17 ++---
 drivers/net/sk98lin/skge.c |2 +-
 drivers/net/tulip/media.c  |4 ++--
 drivers/net/tulip/tulip_core.c |   21 -
 drivers/net/typhoon-firmware.h |2 +-
 6 files changed, 27 insertions(+), 20 deletions(-)

through these ChangeSets:

:
  o sk98lin driver: fix driver name string

Adrian Bunk:
  o drivers/net/typhoon: make a firmware image static

Alan Cox:
  o ac bits for ULI ethernet missing from 2.6.11

François Romieu:
  o Fix r8169: panic on 2.6.11

Matthew Wilcox:
  o Lance needs delay.h

diff -Nru a/drivers/net/lance.c b/drivers/net/lance.c
--- a/drivers/net/lance.c	2005-03-11 23:31:46 -05:00
+++ b/drivers/net/lance.c	2005-03-11 23:31:46 -05:00
@@ -47,6 +47,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff -Nru a/drivers/net/r8169.c b/drivers/net/r8169.c
--- a/drivers/net/r8169.c	2005-03-11 23:31:46 -05:00
+++ b/drivers/net/r8169.c	2005-03-11 23:31:46 -05:00
@@ -1683,16 +1683,19 @@
 	rtl8169_make_unusable_by_asic(desc);
 }
 
-static inline void rtl8169_return_to_asic(struct RxDesc *desc, int rx_buf_sz)
+static inline void rtl8169_mark_to_asic(struct RxDesc *desc, u32 rx_buf_sz)
 {
-	desc->opts1 |= cpu_to_le32(DescOwn + rx_buf_sz);
+	u32 eor = le32_to_cpu(desc->opts1) & RingEnd;
+
+	desc->opts1 = cpu_to_le32(DescOwn | eor | rx_buf_sz);
 }
 
-static inline void rtl8169_give_to_asic(struct RxDesc *desc, dma_addr_t mapping,
-	int rx_buf_sz)
+static inline void rtl8169_map_to_asic(struct RxDesc *desc, dma_addr_t mapping,
+   u32 rx_buf_sz)
 {
 	desc->addr = cpu_to_le64(mapping);
-	desc->opts1 |= cpu_to_le32(DescOwn + rx_buf_sz);
+	wmb();
+	rtl8169_mark_to_asic(desc, rx_buf_sz);
 }
 
 static int rtl8169_alloc_rx_skb(struct pci_dev *pdev, struct sk_buff **sk_buff,
@@ -1712,7 +1715,7 @@
 	mapping = pci_map_single(pdev, skb->tail, rx_buf_sz,
  PCI_DMA_FROMDEVICE);
 
-	rtl8169_give_to_asic(desc, mapping, rx_buf_sz);
+	rtl8169_map_to_asic(desc, mapping, rx_buf_sz);
 
 out:
 	return ret;
@@ -2150,7 +2153,7 @@
 			skb_reserve(skb, NET_IP_ALIGN);
 			eth_copy_and_sum(skb, sk_buff[0]->tail, pkt_size, 0);
 			*sk_buff = skb;
-			rtl8169_return_to_asic(desc, rx_buf_sz);
+			rtl8169_mark_to_asic(desc, rx_buf_sz);
 			ret = 0;
 		}
 	}
diff -Nru a/drivers/net/sk98lin/skge.c b/drivers/net/sk98lin/skge.c
--- a/drivers/net/sk98lin/skge.c	2005-03-11 23:31:46 -05:00
+++ b/drivers/net/sk98lin/skge.c	2005-03-11 23:31:46 -05:00
@@ -5155,7 +5155,7 @@
 MODULE_DEVICE_TABLE(pci, skge_pci_tbl);
 
 static struct pci_driver skge_driver = {
-	.name		= "skge",
+	.name		= "sk98lin",
 	.id_table	= skge_pci_tbl,
 	.probe		= skge_probe_one,
 	.remove		= __devexit_p(skge_remove_one),
diff -Nru a/drivers/net/tulip/media.c b/drivers/net/tulip/media.c
--- a/drivers/net/tulip/media.c	2005-03-11 23:31:46 -05:00
+++ b/drivers/net/tulip/media.c	2005-03-11 23:31:46 -05:00
@@ -88,7 +88,7 @@
 		value = ioread32(ioaddr + CSR9);
 		iowrite32(value & 0xFFEF, ioaddr + CSR9);
 		
-		value = (phy_id << 21) | (location << 16) | 0x8000;
+		value = (phy_id << 21) | (location << 16) | 0x0800;
 		iowrite32(value, ioaddr + CSR10);
 		
 		while(--i > 0) {
@@ -166,7 +166,7 @@
 		value = ioread32(ioaddr + CSR9);
 		iowrite32(value & 0xFFEF, ioaddr + CSR9);
 		
-		value = (phy_id << 21) | (location << 16) | 0x4000 | (val & 0x);
+		value = (phy_id << 21) | (location << 16) | 0x0400 | (val & 0x);
 		iowrite32(value, ioaddr + CSR10);
 		
 		while(--i > 0) {
diff -Nru a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c
--- a/drivers/net/tulip/tulip_core.c	2005-03-11 23:31:46 -05:00
+++ b/drivers/net/tulip/tulip_core.c	2005-03-11 23:31:46 -05:00
@@ -1102,15 +1102,18 @@
 			entry = tp->cur_tx++ % TX_RING_SIZE;
 
 			if (entry != 0) {
-/* Avoid a chip errata by prefixing a dummy entry. */
-tp->tx_buffers[entry].skb = NULL;
-tp->tx_buffers[entry].mapping = 0;
-tp->tx_ring[entry].length =
-	(entry == TX_RING_SIZE-1) ? cpu_to_le32(DESC_RING_WRAP) : 0;
-tp->tx_ring[entry].buffer1 = 0;
-/* Must set DescOwned later to avoid race with chip */
-dummy = entry;
-entry = tp->cur_tx++ % TX_RING_SIZE;
+/* Avoid a chip errata by prefixing a dummy entry. Don't do
+   this on the ULI526X as it triggers a different problem */
+if (!(tp->chip_id == ULI526X && (tp->revision = 0x40 || tp->revision == 0x50))) {
+	tp->tx_buffers[entry].skb = NULL;
+	tp->tx_buffers[entry].mapping = 0;
+	tp->tx_ring[entry].length =
+		(entry == TX_RING_SIZE-1) ? cpu_to_le32(DESC_RING_WRAP) : 0;
+	tp->tx_ring[entry].buffer1 = 0;
+	/* Must set DescOwned later to avoid race with chip */
+	dummy = entry;
+	entry = tp->cur_tx++ % TX_RING_SIZE;
+}
 			}
 
 			tp->tx_buffers[entry].skb = NULL;
diff

[BK PATCHES] 2.6.x libata fixes

2005-03-11 Thread Jeff Garzik

 Please do a

bk pull bk://gkernel.bkbits.net/libata-2.6

This will update the following files:

 drivers/scsi/ahci.c |   15 +--
 1 files changed, 13 insertions(+), 2 deletions(-)

through these ChangeSets:

Brett Russ:
  o AHCI: fix fatal error int handling

Jeff Garzik:
  o [libata ahci] support ->tf_read hook

diff -Nru a/drivers/scsi/ahci.c b/drivers/scsi/ahci.c
--- a/drivers/scsi/ahci.c	2005-03-11 23:30:59 -05:00
+++ b/drivers/scsi/ahci.c	2005-03-11 23:30:59 -05:00
@@ -177,6 +177,7 @@
 static int ahci_port_start(struct ata_port *ap);
 static void ahci_port_stop(struct ata_port *ap);
 static void ahci_host_stop(struct ata_host_set *host_set);
+static void ahci_tf_read(struct ata_port *ap, struct ata_taskfile *tf);
 static void ahci_qc_prep(struct ata_queued_cmd *qc);
 static u8 ahci_check_status(struct ata_port *ap);
 static u8 ahci_check_err(struct ata_port *ap);
@@ -210,6 +211,8 @@
 	.check_err		= ahci_check_err,
 	.dev_select		= ata_noop_dev_select,
 
+	.tf_read		= ahci_tf_read,
+
 	.phy_reset		= ahci_phy_reset,
 
 	.qc_prep		= ahci_qc_prep,
@@ -463,6 +466,14 @@
 	return (readl(mmio + PORT_TFDATA) >> 8) & 0xFF;
 }
 
+static void ahci_tf_read(struct ata_port *ap, struct ata_taskfile *tf)
+{
+	struct ahci_port_priv *pp = ap->private_data;
+	u8 *d2h_fis = pp->rx_fis + RX_FIS_D2H_REG;
+
+	ata_tf_from_fis(d2h_fis, tf);
+}
+
 static void ahci_fill_sg(struct ata_queued_cmd *qc)
 {
 	struct ahci_port_priv *pp = qc->ap->private_data;
@@ -539,7 +550,7 @@
 
 	/* stop DMA */
 	tmp = readl(port_mmio + PORT_CMD);
-	tmp &= PORT_CMD_START | PORT_CMD_FIS_RX;
+	tmp &= ~PORT_CMD_START;
 	writel(tmp, port_mmio + PORT_CMD);
 
 	/* wait for engine to stop.  TODO: this could be
@@ -571,7 +582,7 @@
 
 	/* re-start DMA */
 	tmp = readl(port_mmio + PORT_CMD);
-	tmp |= PORT_CMD_START | PORT_CMD_FIS_RX;
+	tmp |= PORT_CMD_START;
 	writel(tmp, port_mmio + PORT_CMD);
 	readl(port_mmio + PORT_CMD); /* flush */

Re: AGP bogosities

2005-03-11 Thread Ken Ryan

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


-
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/

Re: AGP bogosities

2005-03-11 Thread Dave Jones

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

-
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/

Re: 2.6.11: USB broken on nforce4, ipv6 still broken, centrino speedstep even more broken than in 2.6.10

On Fri, 2005-03-11 at 17:35 -0800, Andrew Morton wrote:
> Felix von Leitner <[EMAIL PROTECTED]> wrote:
> >
> > Finally Centrino SpeedStep.
> > I have a "Intel(R) Pentium(R) M processor 1.80GHz" in my notebook.
> > Linux does not support it.  This architecture has been out there for
> > months now, and there even was a patch to support it posted here a in
> > October last year or so.  Linux still does not include it.  Until
> > 2.6.11-rc4-bk8 or so, the old patched file from back then still worked.
> > Now it doesn't.  Because some interface changed.  Now what?  Using a
> > Centrino notebook without CPU throttling is completely out of the
> > question.  Linux might as well not boot on it at all.
> 
> Could you please dig out the old patch, send it?

Why not use ACPI for CPU scaling?

Thanks,
Adam


-
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/

Re: 2.6.11: USB broken on nforce4, ipv6 still broken, centrino speedstep even more broken than in 2.6.10

On Fri, 2005-03-11 at 20:21 +, Felix von Leitner wrote:
> Linux is getting less and less usable for me. :-(
> 
> 
> My new nForce 4 mainboard has 10 or so USB 2.0 outlets.  In Windows,
> they all work.  In Linux, two of them work.  Putting my USB stick or
> anything else in one of the others produces nothing in Linux.
> Apparently no IRQ getting through or something?

Could you also include lspci -vv.

Thanks,
Adam


-
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/

Re: [PATCH] Prefaulting

Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> There is even a slight performance win in the
>  uniprocessor case:
> 
>  w/o any patch:
> 
>   Mb Rep Thr CLine  User  System   Wall  flt/cpu/s fault/wsec
>  200  31   10.01s  0.15s   0.01s846860.493 848882.424
>  200  31   10.01s  0.16s   0.01s827724.160 830841.482
>  200  31   10.00s  0.16s   0.01s827724.160 827364.176
> 
>  w/prefault patch
> 
>  200 MB allocation
> 
>   Mb Rep Thr CLine  User  System   Wall  flt/cpu/s fault/wsec
>  200  31   10.02s  0.48s   0.05s860119.275 859918.989
>  200  31   10.02s  0.46s   0.04s886129.730 886551.621
>  200  31   10.01s  0.47s   0.04s887920.166 886855.775

But the system time went through the roof.  Would that be accounting
inaccuracy?

-
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/

Re: IBM Thinkpad G41 PCMCIA problems [Was: Yenta TI: ... no PCI interrupts. Fish. Please report.]

On Sun, 2005-02-20 at 09:23 -0800, Linus Torvalds wrote:
> 
> On Sun, 20 Feb 2005, Russell King wrote:
> > On Sat, Feb 19, 2005 at 08:36:12PM -0500, Steven Rostedt wrote:
> > >  BIOS-e820:  - 0009f000 (usable)
> > >  BIOS-e820: 0009f000 - 000a (reserved)
> > >  BIOS-e820: 000d - 000d4000 (reserved)
> > >  BIOS-e820: 000dc000 - 0010 (reserved)
> > >  BIOS-e820: 0010 - 0f6f (usable)
> > >  BIOS-e820: 0f6f - 0f70 (reserved)
> > >  BIOS-e820: 0f70 - 3fef (usable)
> > >  BIOS-e820: 3fef - 3fef8000 (ACPI data)
> > >  BIOS-e820: 3fef8000 - 3fefa000 (ACPI NVS)
> > >  BIOS-e820: 3ff0 - 4000 (reserved)
> > 
> > Your BIOS is broken.  You probably have 1GB of RAM which extends from
> > 0x to 0x4000.  However, there's a hole in the ACPI map
> > between 0x3fefa000 and 0x3ff0.
> 
> Good point. And dammit, we've had that problem too many times before.

ACPI will report the ranges available to a PCI root bridge, even on
single root machines.  I'm hoping to take advantage of this in my PCI
bus changes.  It should help with these sort of problems.

Thanks,
Adam


-
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/

Re: IBM Thinkpad G41 PCMCIA problems [Was: Yenta TI: ... no PCI interrupts. Fish. Please report.]

On Sat, 2005-02-19 at 20:02 -0800, Linus Torvalds wrote:
> 
> On Sat, 19 Feb 2005, Steven Rostedt wrote:
> >
> > On Sat, 2005-02-19 at 18:10 -0800, Linus Torvalds wrote:
> > 
> > > I _think_ it's the code in arch/i386/pci/fixup.c that does this. See the
> > > 
> > >   static void __devinit pci_fixup_transparent_bridge(struct pci_dev *dev)
> > > 
> > > thing, and try to disable it. Maybe that rule is wrong, and triggers much 
> > > too often?
> > > 
> > 
> > Linus,
> > 
> > Thank you very much! That was it.  The following patch made everything
> > look good.
> 
> Ok. I've fired off an email to some Intel people asking what the
> real rules are wrt Intel PCI-PCI bridges. It may be that it's not that 
> particular chip, but some generic rule (like "all Intel bridges act like 
> they are subtractive decode _except_ if they actually have the IO 
> start/stop ranges set" or something like that).
> 
> If anybody on the list can figure the Intel bridge decoding rules out, 
> please holler..
> 
>   Linus

Actually, I've ran into a similar situation on my hardware.  After
looking into it for a while, I'm pretty sure it's actually a transparent
bridge (despite it not indicating such in the programing interface class
code).  Have you heard anything more?

Thanks,
Adam


-
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/

Re: [PATCH] Prefaulting

2005-03-11 Thread Christoph Lameter

On Fri, 11 Mar 2005, Andrew Morton wrote:

> > Results that show the impact of this patch are available at
> > http://oss.sgi.com/projects/page_fault_performance/
>
> There are a lot of numbers there.  Was there an executive summary?

You are right there is none for prefaulting. What all of these patches
(prezero,atomic pte, prefault) have in common is that they improve
performance for large number crunching applications but there is barely
any improvement for kernel compiles and/or LMBench. The best I can do is
insure that they do no harm. These issues are likely to become more
pressing as memory sizes and appplication sizes grow.

> >From a quick peek it seems that the patch makes negligible difference for a
> kernel compilation when prefaulting 1-2 pages and slows the workload down
> quite a lot when prefaulting up to 16 pages.

Yes. Prefaulting up to 16 pages slows the kernel compile down by
5% due to overallocating pages.

> And for the uniprocessor "200 Megabyte allocation without prezeroing.
> Single thread." workload it appears that the prefault patch slowed it down
> by 4x.

You likely compared the prezeroing performance with the prefaulting
performance. Prezeroing yields a fourfold improvement gain:

 Mb Rep Thr CLine  User  System   Wall  flt/cpu/s fault/wsec
200  31   10.00s  0.02s   0.00s3756674.275 3712403.061
200  31   10.00s  0.03s   0.00s3488295.668 3501888.597
200  31   10.00s  0.03s   0.00s3407159.305 3420844.913

You need to compare the performance without any patches to the performance
with the prefault patch. There is even a slight performance win in the
uniprocessor case:

w/o any patch:

 Mb Rep Thr CLine  User  System   Wall  flt/cpu/s fault/wsec
200  31   10.01s  0.15s   0.01s846860.493 848882.424
200  31   10.01s  0.16s   0.01s827724.160 830841.482
200  31   10.00s  0.16s   0.01s827724.160 827364.176

w/prefault patch

200 MB allocation

 Mb Rep Thr CLine  User  System   Wall  flt/cpu/s fault/wsec
200  31   10.02s  0.48s   0.05s860119.275 859918.989
200  31   10.02s  0.46s   0.04s886129.730 886551.621
200  31   10.01s  0.47s   0.04s887920.166 886855.775

> Am I misreading the results?  If not, it's a bit disappointing.

Yes. The prefault patch actually improves UP performance of the
Microbenchmark slightly.
-
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/

Re: AGP bogosities

2005-03-11 Thread Mike Werner

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
-
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/

Re: [load balancing] F5 kernel source mods released

2005-03-11 Thread Shayne Stubbs


Can you still post it?

- shayne

On 3/11/05 3:57 PM, "Bill Whitson" <[EMAIL PROTECTED]> wrote:

> Before anyone gets too excited, the modifications to the GPL licensed code
> will not provide you with a working load-balancer, or anything remotely
> close.  The majority of the traffic processing in BIG-IP version 9.x is
> handled by the traffic management microkernel, which is unique code.
> 
> Sorry, you can't hack together your own version of BIG-IP ;).





-
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/

Re: [PATCH] clean up FIXME in do_timer_interrupt

2005-03-11 Thread George Anzinger

Andrew Morton wrote:
Lee Revell <[EMAIL PROTECTED]> wrote:
On Thu, 2005-03-10 at 00:42 -0800, George Anzinger wrote:
This patch changes the update of the cmos clock to be timer driven
rather than poll driven by the timer interrupt function.  If the clock
is not being synced to an outside source the timer is removed and thus
system overhead is nill in that case.  The update frequency is still ~11
minutes and missing the update window still causes a retry in 60
seconds.
No replies yet.  Are there any objections to this patch?

Nope.  I think it's neat.  I queued it up.
I had a nightmare about ntp coming in at the "wrong" time resulting in a 
deadlock.  Attached locking changes will make me sleep better :)

--
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Source: MontaVista Software, Inc.
Type: Defect Fix 
Disposition: Pending
Description:

I was not happy with the locking on this.  Two changes:
1) Turn off irq while setting the clock.
2) Call the timer code only through the timer interface 
   (set a short timer to do it from the ntp call).

Signed-off-by: George Anzinger 

 time.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

Index: linux-2.6.12-rc/arch/i386/kernel/time.c
===
--- linux-2.6.12-rc.orig/arch/i386/kernel/time.c
+++ linux-2.6.12-rc/arch/i386/kernel/time.c
@@ -176,12 +176,12 @@ static int set_rtc_mmss(unsigned long no
int retval;
 
/* gets recalled with irq locally disabled */
-   spin_lock(_lock);
+   spin_lock_irq(_lock);
if (efi_enabled)
retval = efi_set_rtc_mmss(nowtime);
else
retval = mach_set_rtc_mmss(nowtime);
-   spin_unlock(_lock);
+   spin_unlock_irq(_lock);
 
return retval;
 }
@@ -338,7 +338,7 @@ static void sync_cmos_clock(unsigned lon
 }
 void notify_arch_cmos_timer(void)
 {
-   sync_cmos_clock(0);
+   mod_timer(_cmos_timer, jiffies + 1);
 }
 static long clock_cmos_diff, sleep_start;

Re: 2.6.11: USB broken on nforce4, ipv6 still broken, centrino speedstep even more broken than in 2.6.10


(Added netdev cc)

Felix von Leitner <[EMAIL PROTECTED]> wrote:
>
> Now about IPv6: npush and npoll are two applications I wrote.  npush
> sends multicast announcements and opens a TCP socket.  npoll receives
> the multicast announcement and connects to the source IP/port/scope_id
> of the announcement.  If both are run on the same machine, npoll sees
> the link local address of eth0 as source IP, and the interface number of
> eth0 as scope_id.  So far so good.  Trying to connect() however hangs.
> Since this has been broken in different ways for as long as I can
> remember in Linux, and I keep complaining about it every half a year or
> so.  Can't someone fix this once and for all?  IPv4 checks whether we
> are connecting to our own address and reroutes through loopback, why
> can't IPv6?
> 
-
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/

Re: 2.6.11: USB broken on nforce4, ipv6 still broken, centrino speedstep even more broken than in 2.6.10

Felix von Leitner <[EMAIL PROTECTED]> wrote:
>
> Finally Centrino SpeedStep.
> I have a "Intel(R) Pentium(R) M processor 1.80GHz" in my notebook.
> Linux does not support it.  This architecture has been out there for
> months now, and there even was a patch to support it posted here a in
> October last year or so.  Linux still does not include it.  Until
> 2.6.11-rc4-bk8 or so, the old patched file from back then still worked.
> Now it doesn't.  Because some interface changed.  Now what?  Using a
> Centrino notebook without CPU throttling is completely out of the
> question.  Linux might as well not boot on it at all.

Could you please dig out the old patch, send it?

-
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/

Re: AGP bogosities

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.
-
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/

[RFC][PATCH] new timeofday arch specific timesource drivers (v. A3)

2005-03-11 Thread john stultz

All,
This patch implements most of the time sources for i386, x86-64, ppc32
and ppc64 (tsc, pit, cyclone, acpi-pm, hpet and timebase). There are
also initial untested sketches for the ia64 itc and sn2_rtc timesources.
It applies ontop of my linux-2.6.11_timeofday-arch_A3 patch. It provides
real hardware timesources (opposed to the example jiffies timesource)
that can be used for more realistic testing.

This patch is the shabbiest of the three. It needs to be broken up, and
cleaned. The i386_pit.c is broken. The hpet and cyclone code have been
attempted to be cleaned up so they can be shared between x86-64, i386
and ia64, but they still need testing. acpi_pm also needs to be made
arch generic, but for now it will get you going so you can test and play
with the core code.

New in this release:
o ppc32_timebase code (by Darrick Wong!)
o move cyclone code to TIMESOURCE_MMIO_32
o cleaned up hpet to work on i386 as well as x86-64
o untested/uncompiled ia64 timesources (these are mine, don't blame
Max!)
o other minor code cleanups

Items still on the TODO list:
o real ia64 timesources
o make cyclone/apci_pm arch generic 
o example interpolation timesource
o fix i386_pit timesource
o all other arch timesources (volunteers wanted!)
o lots of cleanups
o lots of testing

thanks
-john

linux-2.6.11_timeofday-timesources_A3.patch
===
diff -Nru a/arch/i386/kernel/Makefile b/arch/i386/kernel/Makefile
--- a/arch/i386/kernel/Makefile 2005-03-11 17:04:48 -08:00
+++ b/arch/i386/kernel/Makefile 2005-03-11 17:04:48 -08:00
@@ -7,10 +7,10 @@
 obj-y  := process.o semaphore.o signal.o entry.o traps.o irq.o vm86.o \
ptrace.o time.o ioport.o ldt.o setup.o i8259.o sys_i386.o \
pci-dma.o i386_ksyms.o i387.o dmi_scan.o bootflag.o \
-   doublefault.o quirks.o
+   doublefault.o quirks.o tsc.o
 
 obj-y  += cpu/
-obj-y  += timers/
+obj-$(!CONFIG_NEWTOD)  += timers/
 obj-$(CONFIG_ACPI_BOOT)+= acpi/
 obj-$(CONFIG_X86_BIOS_REBOOT)  += reboot.o
 obj-$(CONFIG_MCA)  += mca.o
diff -Nru a/arch/i386/kernel/acpi/boot.c b/arch/i386/kernel/acpi/boot.c
--- a/arch/i386/kernel/acpi/boot.c  2005-03-11 17:04:48 -08:00
+++ b/arch/i386/kernel/acpi/boot.c  2005-03-11 17:04:48 -08:00
@@ -547,7 +547,7 @@
 
 
 #ifdef CONFIG_HPET_TIMER
-
+#include 
 static int __init acpi_parse_hpet(unsigned long phys, unsigned long size)
 {
struct acpi_table_hpet *hpet_tbl;
@@ -570,18 +570,12 @@
 #ifdef CONFIG_X86_64
 vxtime.hpet_address = hpet_tbl->addr.addrl |
 ((long) hpet_tbl->addr.addrh << 32);
-
-printk(KERN_INFO PREFIX "HPET id: %#x base: %#lx\n",
-   hpet_tbl->id, vxtime.hpet_address);
+   hpet_address = vxtime.hpet_address;
 #else  /* X86 */
-   {
-   extern unsigned long hpet_address;
-
hpet_address = hpet_tbl->addr.addrl;
+#endif /* X86 */
printk(KERN_INFO PREFIX "HPET id: %#x base: %#lx\n",
hpet_tbl->id, hpet_address);
-   }
-#endif /* X86 */
 
return 0;
 }
diff -Nru a/arch/i386/kernel/i8259.c b/arch/i386/kernel/i8259.c
--- a/arch/i386/kernel/i8259.c  2005-03-11 17:04:48 -08:00
+++ b/arch/i386/kernel/i8259.c  2005-03-11 17:04:48 -08:00
@@ -387,6 +387,48 @@
}
 }
 
+#ifdef CONFIG_NEWTOD
+void setup_pit_timer(void)
+{
+   extern spinlock_t i8253_lock;
+   unsigned long flags;
+
+   spin_lock_irqsave(_lock, flags);
+   outb_p(0x34,PIT_MODE);  /* binary, mode 2, LSB/MSB, ch 0 */
+   udelay(10);
+   outb_p(LATCH & 0xff , PIT_CH0); /* LSB */
+   udelay(10);
+   outb(LATCH >> 8 , PIT_CH0); /* MSB */
+   spin_unlock_irqrestore(_lock, flags);
+}
+
+static int timer_resume(struct sys_device *dev)
+{
+   setup_pit_timer();
+   return 0;
+}
+
+static struct sysdev_class timer_sysclass = {
+   set_kset_name("timer_pit"),
+   .resume = timer_resume,
+};
+
+static struct sys_device device_timer = {
+   .id = 0,
+   .cls= _sysclass,
+};
+
+static int __init init_timer_sysfs(void)
+{
+   int error = sysdev_class_register(_sysclass);
+   if (!error)
+   error = sysdev_register(_timer);
+   return error;
+}
+
+device_initcall(init_timer_sysfs);
+#endif
+
 void __init init_IRQ(void)
 {
int i;
diff -Nru a/arch/i386/kernel/setup.c b/arch/i386/kernel/setup.c
--- a/arch/i386/kernel/setup.c  2005-03-11 17:04:48 -08:00
+++ b/arch/i386/kernel/setup.c  2005-03-11 17:04:48 -08:00
@@ -50,6 +50,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "setup_arch_pre.h"
 #include 
 
@@ -1527,6 +1528,7 @@
conswitchp = _con;
 #endif
 #endif
+   tsc_init();
 }
 
 #include "setup_arch_post.h"
diff -Nru a/arch/i386/kernel/time.c b/arch/i386/kernel/time.c
--- a/arch/i386/kernel/time.c   2005-03-11 17:04:48 -08:00
+++

Re: 2.6.11: USB broken on nforce4, ipv6 still broken, centrino speedstep even more broken than in 2.6.10

Felix von Leitner <[EMAIL PROTECTED]> wrote:
>
> My new nForce 4 mainboard has 10 or so USB 2.0 outlets.  In Windows,
> they all work.  In Linux, two of them work.  Putting my USB stick or
> anything else in one of the others produces nothing in Linux.
> Apparently no IRQ getting through or something?
> 
> This is what /proc/interrupts has to say:
> 
>   177:9503618   IO-APIC-level  ohci_hcd, eth0
> 
> These are the USB boot messages:
> 
>   usbcore: registered new driver usbfs
>   usbcore: registered new driver hub
>   ehci_hcd :00:02.1: new USB bus registered, assigned bus number 1
>   ehci_hcd :00:02.1: USB 2.0 initialized, EHCI 1.00, driver 26 Oct 2004
>   hub 1-0:1.0: USB hub found
>   ohci_hcd: 2004 Nov 08 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
>   ohci_hcd :00:02.0: new USB bus registered, assigned bus number 2
>   hub 2-0:1.0: USB hub found
>   usbcore: registered new driver usblp
>   drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
>   Initializing USB Mass Storage driver...
>   usb 2-4: new low speed USB device using ohci_hcd and address 2
>   usbcore: registered new driver usb-storage
>   USB Mass Storage support registered.
>   input: USB HID v1.10 Mouse [B16_b_02 USB-PS/2 Optical Mouse] on
>   usb-:00:02.0-4
>   usbcore: registered new driver usbhid
>   drivers/usb/input/hid-core.c: v2.0:USB HID core driver
>   HUB0 XVR0 XVR1 XVR2 XVR3 USB0 USB2 MMAC MMCI UAR1
> 
> As you can see, it appears to work in principle.

Did it work correctly on any earlier kernel?  If so, which one(s)?
-
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/

[RFC][PATCH] new timeofday arch specific hooks (v. A3)

2005-03-11 Thread john stultz

All,
This patch implements the minimal architecture specific hooks to enable
the new time of day subsystem code for i386, x86-64, ia64, ppc32 and
ppc64. It applies on top of my linux-2.6.11_timeofday-core_A3 patch and
with this patch applied, you can test the new time of day subsystem. 

Basically it configs in the NEWTOD code and cuts alot of code out of the
build via #ifdefs. I know, I know, #ifdefs' are ugly and bad, and the
final patch will just remove the old code. For now this allows us to be
flexible and easily switch between the two implementations with a single
define.

New in this version:
o ppc32 arch code (by Darrick Wong. Many thanks to him for this code!)
o ia64 arch code (by Max Asbock. Many thanks to him for this code!)
o minor cleanups moving code between the arch and timesource patches

Items still on the TODO list:
o s390 arch port (hey Martin: nudge, nudge :)
o arch specific vsyscall/fsyscall interface
o other arch ports (volunteers wanted!)

I look forward to your comments and feedback.

thanks
-john

linux-2.6.11_timeofday-arch_A3.patch
===
diff -Nru a/arch/i386/Kconfig b/arch/i386/Kconfig
--- a/arch/i386/Kconfig 2005-03-11 17:02:30 -08:00
+++ b/arch/i386/Kconfig 2005-03-11 17:02:30 -08:00
@@ -14,6 +14,10 @@
  486, 586, Pentiums, and various instruction-set-compatible chips by
  AMD, Cyrix, and others.
 
+config NEWTOD
+   bool
+   default y
+
 config MMU
bool
default y
diff -Nru a/arch/i386/kernel/apm.c b/arch/i386/kernel/apm.c
--- a/arch/i386/kernel/apm.c2005-03-11 17:02:30 -08:00
+++ b/arch/i386/kernel/apm.c2005-03-11 17:02:30 -08:00
@@ -224,6 +224,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1204,6 +1205,7 @@
device_suspend(PMSG_SUSPEND);
device_power_down(PMSG_SUSPEND);
 
+   timeofday_suspend_hook();
/* serialize with the timer interrupt */
write_seqlock_irq(_lock);
 
@@ -1231,6 +1233,7 @@
spin_unlock(_lock);
write_sequnlock_irq(_lock);
 
+   timeofday_resume_hook();
if (err == APM_NO_ERROR)
err = APM_SUCCESS;
if (err != APM_SUCCESS)
diff -Nru a/arch/i386/kernel/time.c b/arch/i386/kernel/time.c
--- a/arch/i386/kernel/time.c   2005-03-11 17:02:30 -08:00
+++ b/arch/i386/kernel/time.c   2005-03-11 17:02:30 -08:00
@@ -68,6 +68,8 @@
 
 #include "io_ports.h"
 
+#include 
+
 extern spinlock_t i8259A_lock;
 int pit_latch_buggy;  /* extern */
 
@@ -117,6 +119,7 @@
 }
 EXPORT_SYMBOL(rtc_cmos_write);
 
+#ifndef CONFIG_NEWTOD
 /*
  * This version of gettimeofday has microsecond resolution
  * and better than microsecond precision on fast x86 machines with TSC.
@@ -199,6 +202,7 @@
 }
 
 EXPORT_SYMBOL(do_settimeofday);
+#endif
 
 static int set_rtc_mmss(unsigned long nowtime)
 {
@@ -224,11 +228,13 @@
  * Note: This function is required to return accurate
  * time even in the absence of multiple timer ticks.
  */
+#ifndef CONFIG_NEWTOD
 unsigned long long monotonic_clock(void)
 {
return cur_timer->monotonic_clock();
 }
 EXPORT_SYMBOL(monotonic_clock);
+#endif
 
 #if defined(CONFIG_SMP) && defined(CONFIG_FRAME_POINTER)
 unsigned long profile_pc(struct pt_regs *regs)
@@ -268,6 +274,7 @@
 
do_timer_interrupt_hook(regs);
 
+#ifndef CONFIG_NEWTOD
/*
 * If we have an externally synchronized Linux clock, then update
 * CMOS clock accordingly every ~11 minutes. Set_rtc_mmss() has to be
@@ -286,6 +293,7 @@
} else if (set_rtc_mmss(xtime.tv_sec))
last_rtc_update -= 600;
}
+#endif
 
if (MCA_bus) {
/* The PS/2 uses level-triggered interrupts.  You can't
@@ -318,7 +326,9 @@
 */
write_seqlock(_lock);
 
+#ifndef CONFIG_NEWTOD
cur_timer->mark_offset();
+#endif
  
do_timer_interrupt(irq, NULL, regs);
 
@@ -343,6 +353,40 @@
return retval;
 }
 
+/* arch specific timeofday hooks */
+nsec_t read_persistent_clock(void)
+{
+   return (nsec_t)get_cmos_time() * NSEC_PER_SEC;
+}
+
+void sync_persistent_clock(struct timespec ts)
+{
+   /*
+* If we have an externally synchronized Linux clock, then update
+* CMOS clock accordingly every ~11 minutes. Set_rtc_mmss() has to be
+* called as close as possible to 500 ms before the new second starts.
+*/
+   if (ts.tv_sec > last_rtc_update + 660 &&
+   (ts.tv_nsec / 1000)
+   >= USEC_AFTER - ((unsigned) TICK_SIZE) / 2 &&
+   (ts.tv_nsec / 1000)
+   <= USEC_BEFORE + ((unsigned) TICK_SIZE) / 2) {
+   /* horrible...FIXME */
+   if (efi_enabled) {
+   if (efi_set_rtc_mmss(ts.tv_sec) == 0)
+   last_rtc_update = ts.tv_sec;
+   else
+   last_rtc_update = ts.tv_sec - 600;
+

[RFC][PATCH] new timeofday core subsystem (v. A3)

2005-03-11 Thread john stultz

All,
This patch implements the architecture independent portion of the time
of day subsystem. For a brief description on the rework, see here:
http://lwn.net/Articles/120850/ (Many thanks to the LWN team for that
clear writeup!)

The exciting new changes are ntp_scale() has been removed, speeding up
gettimeofday(), and the periodically run timekeeping code is now called
via soft-timer rather then at interrupt time. So timekeeping can now be
done every tick or every 10 ticks or whatever!

Included below is timeofday.c (which includes all the time of day
management and accessor functions), ntp.c (which includes the ntp
scaling calculation code, leapsecond processing, and ntp kernel state
machine code), timesource.c (for timesource specific management
functions), interface definition .h files, the example jiffies
timesource (lowest common denominator time source, mainly for use as
example code) and minimal hooks into arch independent code.

The patch does not function without minimal architecture specific hooks
(i386, x86-64, ppc32, ppc64, and ia64 examples to follow), and it should
be able to be applied to a tree without affecting the code.

New in this version:
o ntp_scale has been removed from the gettimeofday fastpath
o ntp_advance now pre-calculates the ntp scaling factor for the next
interval
o timeofday_periodic_hook is now called by a soft-timer and runs outside
of interrupt context
o comment cleanups

Items still on the TODO list:
o cyc2ns needs better remainder code
o Infrastructure for exporting time values for vsyscall/fsyscall 
o finer grianed ntp adjustments in ppb instead of ppm
o more flexible timesource management interface
o Testing, performance and cleanup work

I look forward to your comments and feedback.

thanks
-john

linux-2.6.11_timeofday-core_A3.patch

diff -Nru a/drivers/Makefile b/drivers/Makefile
--- a/drivers/Makefile  2005-03-11 17:00:02 -08:00
+++ b/drivers/Makefile  2005-03-11 17:00:02 -08:00
@@ -64,3 +64,4 @@
 obj-$(CONFIG_BLK_DEV_SGIIOC4)  += sn/
 obj-y  += firmware/
 obj-$(CONFIG_CRYPTO)   += crypto/
+obj-$(CONFIG_NEWTOD)   += timesource/
diff -Nru a/drivers/timesource/Makefile b/drivers/timesource/Makefile
--- /dev/null   Wed Dec 31 16:00:00 196900
+++ b/drivers/timesource/Makefile   2005-03-11 17:00:02 -08:00
@@ -0,0 +1 @@
+obj-y += jiffies.o
diff -Nru a/drivers/timesource/jiffies.c b/drivers/timesource/jiffies.c
--- /dev/null   Wed Dec 31 16:00:00 196900
+++ b/drivers/timesource/jiffies.c  2005-03-11 17:00:02 -08:00
@@ -0,0 +1,45 @@
+/*
+ * linux/drivers/timesource/jiffies.c
+ *
+ * Copyright (C) 2004 IBM
+ *
+ * This file contains the jiffies based time source.
+ *
+ */
+#include 
+#include 
+#include 
+
+/* The Jiffies based timesource is the lowest common
+ * denominator time source which should function on
+ * all systems. It has the same coarse resolution as
+ * the timer interrupt frequency HZ and it suffers
+ * inaccuracies caused by missed or lost timer
+ * interrupts and the inability for the timer
+ * interrupt hardware to accuratly tick at the
+ * requested HZ value. It is also not reccomended
+ * for "tick-less" systems.
+ */
+
+static cycle_t jiffies_read(void)
+{
+   cycle_t ret = get_jiffies_64();
+   return ret;
+}
+
+struct timesource_t timesource_jiffies = {
+   .name = "jiffies",
+   .priority = 0, /* lowest priority*/
+   .type = TIMESOURCE_FUNCTION,
+   .read_fnct = jiffies_read,
+   .mask = (cycle_t)~0,
+   .mult = NSEC_PER_SEC/HZ,
+   .shift = 0,
+};
+
+static int init_jiffies_timesource(void)
+{
+   register_timesource(_jiffies);
+   return 0;
+}
+module_init(init_jiffies_timesource);
diff -Nru a/include/linux/ntp.h b/include/linux/ntp.h
--- /dev/null   Wed Dec 31 16:00:00 196900
+++ b/include/linux/ntp.h   2005-03-11 17:00:02 -08:00
@@ -0,0 +1,22 @@
+/* linux/include/linux/ntp.h
+ *
+ * Copyright (C) 2003, 2004 IBM, John Stultz ([EMAIL PROTECTED])
+ *
+ * This file contains time of day helper functions
+ */
+
+#ifndef _LINUX_NTP_H
+#define _LINUX_NTP_H
+#include 
+#include 
+#include 
+
+/* timeofday interfaces */
+nsec_t ntp_scale(nsec_t value);
+int ntp_advance(nsec_t value);
+int ntp_adjtimex(struct timex*);
+int ntp_leapsecond(struct timespec now);
+void ntp_clear(void);
+int get_ntp_status(void);
+
+#endif
diff -Nru a/include/linux/time.h b/include/linux/time.h
--- a/include/linux/time.h  2005-03-11 17:00:02 -08:00
+++ b/include/linux/time.h  2005-03-11 17:00:02 -08:00
@@ -27,6 +27,10 @@
 
 #ifdef __KERNEL__
 
+/* timeofday base types */
+typedef u64 nsec_t;
+typedef u64 cycle_t;
+
 /* Parameters used to convert the timespec values */
 #ifndef USEC_PER_SEC
 #define USEC_PER_SEC (100L)
diff -Nru a/include/linux/timeofday.h b/include/linux/timeofday.h
--- /dev/null   Wed Dec 31 16:00:00 196900
+++ b/include/linux/timeofday.h 2005-03-11 17:00:02 -08:00
@@ -0,0

Re: [PATCH] Prefaulting

Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> This patch allows to aggregate multiple page faults into a single one. It
> does that by detecting that an application generates a sequence of page
> faults.
> 
> ...
> Results that show the impact of this patch are available at
> http://oss.sgi.com/projects/page_fault_performance/

There are a lot of numbers there.  Was there an executive summary?

>From a quick peek it seems that the patch makes negligible difference for a
kernel compilation when prefaulting 1-2 pages and slows the workload down
quite a lot when prefaulting up to 16 pages.

And for the uniprocessor "200 Megabyte allocation without prezeroing. 
Single thread." workload it appears that the prefault patch slowed it down
by 4x.

Am I misreading the results?  If not, it's a bit disappointing.
-
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/

Re: [PATCH 4/9] UML - Export gcov symbol based on gcc version

2005-03-11 Thread Jeff Dike

[EMAIL PROTECTED] said:
> No, my claim is that no sane gcc 3.3 defines __gcov_init. 

Ah, OK.  Thanks for the clarification.

Jeff

-
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/

Re: Problem with PPPD on dialup with 2.6.11-bk1 and later; 2.6.11 is OK

2005-03-11 Thread Steven Cole

On Friday 11 March 2005 01:13 pm, Bill Davidsen wrote:
> Stephen Hemminger wrote:
> >>Stephen Hemminger also wrote: (Someting's busted with serial in 2.6.11 
> >>latest)
> >>
> >>>Some checkin since 2.6.11 has caused the serial driver to
> >>>drop characters.  Console output is chopped and messages are garbled.
> >>>Even the shell prompt gets truncated.
> > 
> > 
> >>Searching lkml archive, I found:
> >>http://marc.theaimsgroup.com/?l=linux-kernel=111031501416334=2
> >>
> >>I also found that reverting that patch made the problem go away for 
> >>2.6.11-bk1.
> > 
> > 
> > 
> > Yes, this patch is the problem. A fix showed up today.
> > Current kernels work fine, thanks.
> 
> Could someone who has the patch broken out send it to -stable? Serial 
> not working is a non-trivial issue given the number of people who use 
> dialup either full time or as a fallback connection.
> 
The fix is in:
http://linus.bkbits.net:8080/linux-2.5/[EMAIL 
PROTECTED]|src/|src/drivers|src/drivers/serial|related/drivers/serial/8250.c

Since the breakage which this fix is for didn't appear until after 2.6.11,
a patch to 2.6.11.x is not required.

Steven
-
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/

Re: [2.6 patch] drivers/pnp/: possible cleanups


> So in short, I'd rather not remove them, because they take away from the
> original design of the PnP layer.

s/they/it would


-
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/

Re: [2.6 patch] drivers/pnp/: possible cleanups

On Fri, 2005-03-11 at 16:23 -0800, Andrew Morton wrote:
> Adam Belay <[EMAIL PROTECTED]> wrote:
> >
> > This patch essential makes it impossible for PnP protocols to be
> > modules.  Currently, they are all in-kernel.  If that is acceptable...,
> > then this patch looks fine to me.  Any comments?
> 
> You're the maintainer...

I've been holding off on making many changes to PnP at the moment,
because I have been considering replacing it with a new (more modern and
ACPI capable) ISA/LPC bridge driver.  This work would likely begin after
my PCI bridge driver rewrite is finished and merged (as the PCI work is
in some ways a prerequisite).

http://marc.theaimsgroup.com/?l=linux-kernel=111023821617705=2

Still, if there are changes to fix actual bugs, then I'm all for them.

Also a few features could be added.  Specifically PnPBIOS
hotplug/docking station support.  If anyone's interested, I may
implement it (and it would use some functions that were removed by this
patch).  Furthermore, ISAPnP could be made a module.  PnPBIOS probably
couldn't.

> 
> If someone converts a protocol to be moduar, presumably they will re-add
> the needed exports to support that.

Correct.

> 
> Are there likely to be any out-of-tree modular protocols in existence?
> 

Not that I'm aware of.

So in short, I'd rather not remove them, because they take away from the
original design of the PnP layer.

Thanks,
Adam

-
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/

Re: [PATCH] mm counter operations through macros

2005-03-11 Thread Christoph Lameter

On Fri, 11 Mar 2005, Andrew Morton wrote:

> > +#define set_mm_counter(mm, member, value) (mm)->member = (value)
> > +#define get_mm_counter(mm, member) ((mm)->member)
> > +#define update_mm_counter(mm, member, value) (mm)->member += (value)
> > +#define inc_mm_counter(mm, member) (mm)->member++
> > +#define dec_mm_counter(mm, member) (mm)->member--
> > +#define MM_COUNTER_T unsigned long
>
> Would prefer `mm_counter_t' here.
>
> Why not a typedef?

Ok typedef it is.

> > @@ -231,9 +237,13 @@ struct mm_struct {
> > unsigned long start_code, end_code, start_data, end_data;
> > unsigned long start_brk, brk, start_stack;
> > unsigned long arg_start, arg_end, env_start, env_end;
> > -   unsigned long rss, anon_rss, total_vm, locked_vm, shared_vm;
> > +   unsigned long total_vm, locked_vm, shared_vm;
> > unsigned long exec_vm, stack_vm, reserved_vm, def_flags, nr_ptes;
> >
> > +   /* Special counters protected by the page_table_lock */
> > +   MM_COUNTER_T rss;
> > +   MM_COUNTER_T anon_rss;
> > +
>
> Why were only two counters converted?

Because only these two counters are protected by the page table lock.

> Could I suggest that you rename all these counters, so that code which
> fails to use the macros won't compile?

Ok. will make them mm_xx as they were in previous patches.

-
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/

Re: [Linux-fbdev-devel] Re: [ACPI] inappropriate use of in_atomic()

On Fri, 2005-03-11 at 16:13 -0800, Andrew Morton wrote:
> (where'd my cc go?)
> 
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> >
> > On Fri, 2005-03-11 at 01:46 -0800, Andrew Morton wrote:
> > > Jan Kasprzak <[EMAIL PROTECTED]> wrote:
> > > >
> > > > This may be the cause of 
> > > > 
> > > >  http://bugme.osdl.org/show_bug.cgi?id=4150
> > > 
> > > Looks that way, yes.
> > 
> > Note that it would be interesting to fix that (I mean the reliability of
> > is_atomic() or an alternative). I agree it's quite bad to rely on that
> > in practice, but there are a few corner cases where it's useful (like
> > oops handling in fbdev's etc...)
> > 
> 
> That would require that we increment current->something on every
> spin/read/write_lock and decrement it in unlock, even with !CONFIG_PREEMPT.
> 
> iirc, Anton added an option to do that to the ppc64 build, decoupled from
> CONFIG_PREEMPT (which ppc64 doesn't support).

ppc64 _does_ support PREEMPT nowadays :)

> But it's an appreciable amount of overhead.
-- 
Benjamin Herrenschmidt <[EMAIL PROTECTED]>

-
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/

Re: [2.6 patch] drivers/pnp/: possible cleanups

Adam Belay <[EMAIL PROTECTED]> wrote:
>
> This patch essential makes it impossible for PnP protocols to be
> modules.  Currently, they are all in-kernel.  If that is acceptable...,
> then this patch looks fine to me.  Any comments?

You're the maintainer...

If someone converts a protocol to be moduar, presumably they will re-add
the needed exports to support that.

Are there likely to be any out-of-tree modular protocols in existence?

-
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/

Re: [Linux-fbdev-devel] Re: [ACPI] inappropriate use of in_atomic()

(where'd my cc go?)

Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2005-03-11 at 01:46 -0800, Andrew Morton wrote:
> > Jan Kasprzak <[EMAIL PROTECTED]> wrote:
> > >
> > > This may be the cause of 
> > > 
> > >  http://bugme.osdl.org/show_bug.cgi?id=4150
> > 
> > Looks that way, yes.
> 
> Note that it would be interesting to fix that (I mean the reliability of
> is_atomic() or an alternative). I agree it's quite bad to rely on that
> in practice, but there are a few corner cases where it's useful (like
> oops handling in fbdev's etc...)
> 

That would require that we increment current->something on every
spin/read/write_lock and decrement it in unlock, even with !CONFIG_PREEMPT.

iirc, Anton added an option to do that to the ppc64 build, decoupled from
CONFIG_PREEMPT (which ppc64 doesn't support).

But it's an appreciable amount of overhead.
-
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/

Re: AGP bogosities


> 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.

-
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/

Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB

2005-03-11 Thread Grzegorz Kulewski

On Fri, 11 Mar 2005, Bjorn Helgaas wrote:
Can you do an "lspci -vvn"?
# lspci -vvn
:00:00.0 Class 0600: 1022:700e (rev 13)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- 
Latency: 32
Region 0: Memory at f000 (32-bit, prefetchable)
Region 1: Memory at f7003000 (32-bit, prefetchable) [size=4K]
Region 2: I/O ports at c000 [disabled] [size=4]
Capabilities: [a0] AGP version 2.0
Status: RQ=16 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- 
HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW+ 
Rate=x4

:00:01.0 Class 0604: 1022:700f
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- 
Latency: 32
Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
Memory behind bridge: f400-f5ff
Prefetchable memory behind bridge: e800-efff
BridgeCtl: Parity- SERR+ NoISA+ VGA+ MAbort- >Reset- FastB2B-

:00:07.0 Class 0601: 1106:0686 (rev 40)
Subsystem: 147b:a702
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping+ SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- 
Latency: 0
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

:00:07.1 Class 0101: 1106:0571 (rev 06) (prog-if 8a [Master SecP 
PriP])
Subsystem: 1106:0571
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Latency: 32
Region 4: I/O ports at c400 [size=16]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

:00:07.2 Class 0c03: 1106:3038 (rev 1a)
Subsystem: 0925:1234
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- 
Latency: 32, cache line size 08
Interrupt: pin D routed to IRQ 9
Region 4: I/O ports at c800 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

:00:07.3 Class 0c03: 1106:3038 (rev 1a)
Subsystem: 0925:1234
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- 
Latency: 32, cache line size 08
Interrupt: pin D routed to IRQ 9
Region 4: I/O ports at cc00 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

:00:07.4 Class 0c05: 1106:3057 (rev 40)
Subsystem: 1106:3057
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Interrupt: pin ? routed to IRQ 11
Capabilities: [68] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

:00:09.0 Class 0400: 109e:036e (rev 11)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Latency: 32 (4000ns min, 1ns max)
Interrupt: pin A routed to IRQ 5
Region 0: Memory at f700 (32-bit, prefetchable)
Capabilities: [44] Vital Product Data
Capabilities: [4c] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

:00:09.1 Class 0480: 109e:0878 (rev 11)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Latency: 32 (1000ns min, 63750ns max)
Interrupt: pin A routed to IRQ 5
Region 0: Memory at f7001000 (32-bit, prefetchable)
Capabilities: [44]

Re: AGP bogosities

2005-03-11 Thread Gene Heskett

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)
 [] kobject_register+0x57/0x60
 [] mod_sysfs_setup+0x50/0xb0
 [] load_module+0x889/0xb70
 [] sys_init_module+0x56/0x220
 [] 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:

[EMAIL PROTECTED] 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.
-
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/

Re: AGP bogosities

2005-03-11 Thread Gene Heskett

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.
-
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/

Re: [2.6 patch] drivers/pnp/: possible cleanups

This patch essential makes it impossible for PnP protocols to be
modules.  Currently, they are all in-kernel.  If that is acceptable...,
then this patch looks fine to me.  Any comments?

Thanks,
Adam

On Fri, 2005-03-11 at 19:16 +0100, Adrian Bunk wrote:
> This patch contains the following possible cleanups:
> - make needlessly global code static
> - #if 0 the following unused global function:
>   - core.c: pnp_remove_device
> - remove the following unneeded EXPORT_SYMBOL's:
>   - card.c: pnp_add_card
>   - card.c: pnp_remove_card
>   - card.c: pnp_add_card_device
>   - card.c: pnp_remove_card_device
>   - card.c: pnp_add_card_id
>   - core.c: pnp_register_protocol
>   - core.c: pnp_unregister_protocol
>   - core.c: pnp_add_device
>   - core.c: pnp_remove_device
>   - pnpacpi/core.c: pnpacpi_protocol
>   - driver.c: pnp_add_id
>   - isapnp/core.c: isapnp_read_byte
>   - manager.c: pnp_auto_config_dev
>   - resource.c: pnp_register_dependent_option
>   - resource.c: pnp_register_independent_option
>   - resource.c: pnp_register_irq_resource
>   - resource.c: pnp_register_dma_resource
>   - resource.c: pnp_register_port_resource
>   - resource.c: pnp_register_mem_resource
> 
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> 


-
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/

Re: [load balancing] F5 kernel source mods released

2005-03-11 Thread Bill Whitson

Before anyone gets too excited, the modifications to the GPL licensed code
will not provide you with a working load-balancer, or anything remotely
close.  The majority of the traffic processing in BIG-IP version 9.x is
handled by the traffic management microkernel, which is unique code.

Sorry, you can't hack together your own version of BIG-IP ;).

-- 
Bill Whitson
Solutions Engineer
AskF5

Desk: 206-272-6587
Mobile: 206-604-7048
[EMAIL PROTECTED]

AskF5: http://tech.f5.com/


On 3/8/05 1:29 AM, "Hamie" <[EMAIL PROTECTED]> wrote:

> 
> F5 (Manufacturers of the BigIP load balancers) have released their
> modified kernel sources & any other bits that are obliged under the GPL
> for their Linux (2.4.21 it looks like) based version 9.x of bigIP. If
> customers wish to get hold of the sources, then there is a solution note
> on theoir website with instructions on how to get the code.
> 
> I haven't tried compiling it yet to see that it's complete, but if
> anyone would like it uploaded somewhere for playing with let me know.
> 
> Hamish Marson.
> 
> The Load Balancing Mailing List
> Unsubscribe:mailto:[EMAIL PROTECTED]
> Archive:http://vegan.net/lb/archive
> LBDigest:   http://lbdigest.com
> MRTG with SLB:  http://vegan.net/MRTG
> Hosted by:http://www.tokkisystems.com
> 


-
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/

Re: 64-bit resources?

2005-03-11 Thread Deepak Saxena

On Mar 10 2005, at 12:09, Kumar Gala was caught saying:
> 
> On Mar 10, 2005, at 11:35 AM, Greg KH wrote:
> 
> >On Thu, Mar 10, 2005 at 01:46:10AM -0600, Kumar Gala wrote:
> > > Greg,
> > >
> >> I was wondering what the state of the change to 64-bit resources was?
> >
> >On hold till I get the time to fix all of the kernel tree up due to the
> > changes required.
> >
> >Unless someone else wants to volunteer to do the work :)
> 
> Will, I might be able to, what major things need fixing?

Kumar,

I'll help you on this b/c I need 64-bit resources ASAP to support
some new CPUs. 

~Deepak

-- 
Deepak Saxena - [EMAIL PROTECTED] - http://www.plexity.net

Even a stopped clock gives the right time twice a day.
-
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/

[PATCH] ppc32: Remove SPR short-hand defines

2005-03-11 Thread Kumar Gala

Andrew,

Removed the Special purpose register (SPR) short-hand defines to help with 
name space pollution.  All SPRs are now referenced as SPRN_.

Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>

---

(patch was above the normal size limit)

http://gate.crashing.org/~galak/spr-rework.20050311.l26.patch
-
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/

Re: Average power consumption in S3?


> What I would suggest doing is changing the code to use a blacklist
> instead of a whitelist, and make it optional with a CONFIG option that
> is marked experimental, and then get it into the mainline for
> additional testing.  If we can get ATI to give us the right way to do
> it, great, but if they aren't being responsive, maybe we should just
> do it empirically.

I'm hesitant to switch a whitelist because of a couple of settings in
there that are specific to the way the chip is wired on the mobo.
Apparently, thinkpads are similar enough to Macs, but I wouldn't bet on
this beeing "commmon"...

Also, the code in there switches to D2, not D3 and is only for M6,M7 and
M9 for now. I may be able to produce code for the M10 as well based on
some dumps we did from the MacOS driver, paulus wrote something that we
ended up not using because the chip is actually powered down on Macs
with the M10.

Then, there is the problem of machines where the chip is powered down
during sleep... I can re-POST an rv280 (M9+) and an M10 but only in
"graphics" mode, not the VGA side for which I know nothing about, with
the same possible issue about video RAM mode register setting.

Ben.


-
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/

Re: [PATCH] ppc32: move powermac backlight stuff to a workqueue

On Fri, 2005-03-11 at 18:10 +, James Simmons wrote:
> > I hope I'll replace this by the new backlight framework in a future
> > kernel version, but for now, this will fix the immediate issues with
> > radeon.
> 
> Is it possible to move it over to the new backlight code that is in 
> drivers/video/backlight ?

Ugh... I wrote that I itend to move it over to it and you ask if it's
possible to move it over to it ? :)

I will do when I have time for it, I have more urgent stuffs on my list
at the moment.

Ben.


-
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/

N00b Asks: Supporting Linux Power Management HOWTO?

2005-03-11 Thread Leo L. Schwab

I'm currently working on driver development for an embedded/handheld
system. We're currently using kernel 2.6.11 on an ARM-based platform, and
I've already got a handful of drivers running (anyone need an I2C bus driver
for a Freescale MX21?). Earlier this week, I was asked to begin work on
power management -- shutting off unused devices, placing the system in
suspend/standby/sleep, etc.

So I started Googling around for info on Linux power management and,
near as I can tell, there doesn't appear to be a cohesive approach to the
issue. What I've managed to turn up so far is:

- APM
An older power management system, supplanted by ACPI. It seems to
enjoy the most mature support in Linux, if for no other reason
than it's been around so much longer. It lacks flexibility,
however.
- ACPI
The current "standard" for power management. Support even on x86-
platforms seems highly uneven, however, and the ACPI support code
still seems to be undergoing major revisions. It also appears to
be widely regarded as an unholy mess of a spec. I've also gleaned
hints from LKML discussons that ACPI contains enough x86-specific
material to make it a questionable choice on other platforms.
- DPM (Dynamic Power Management, http://dynamicpower.sf.net/ )
A proposal put forward by MontaVista and IBM, primarily for
embedded systems (although an Intel Speedstep implementation is
available). While the reference implementation is being kept
current, it doesn't seem to have a lot of activity surrounding it,
despite being two years old.

The functionality in each of these facilities seems to overlap
the others. DPM in particular seems to heavily overlap services provided by
ACPI and exposed by 'cpufreq'. This suggests to me that one ends up
redundantly implementing power support across three APIs, or that one is
supposed to select a single API and stick with that. How one makes this
selection is not at all clear.

Ideally, what I'd like is "the" approach that integrates most
cleanly into existing frameworks. That is, I'd like to be able to write the
power management support into the drivers and platform-specific kernel
files, then essentially drop a stock distro on top of it and have the
largest number of scripts and tools Just Work. I would prefer, if possible,
to write support for one interface rather than three (APM, ACPI, DPM)
especially when two of them are still moving targets.

So, I guess what I'm asking for at the moment is:
- A brief overview of the current state and maturity of power
management support in the 2.6.x kernel series,
- the currently available facilities for implementing and supporting
power management,
- pointers to documents describing the facilities in detail and how
to write driver and platform support for them.

I realize I well may be asking for too much -- the following LKML
thread suggests that Linux power management remains a problem under active
discussion with fragmented solutions:

http://groups-beta.google.com/group/fa.linux.kernel/browse_thread/thread/cab82562215fde4/4660291cd90cf2d2?q=power#4660291cd90cf2d2

Nevertheless, any and all guidance would be greatly appreciated.
Please Cc: list responses to this address. My sincerest thanks in advance.

--
Leo L. Schwab -- Digital Spellweaver [EMAIL PROTECTED] ..or..
\_ -_ http://ewhac.best.vwh.net/[EMAIL PROTECTED]
O^o Recumbent Bikes: The Only Way To Fly. (pronounced "EH-wack")
-
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/

[PATCH 6/6] PCI Express Advanced Error Reporting Driver

This patch includes the source code of startup component (last patch
to be applied) of PCI Express Advanced Error Reporting driver.

Signed-off-by: T. Long Nguyen <[EMAIL PROTECTED]>


diff -urpN linux-2.6.11-rc5/arch/i386/Kconfig 
patch-2.6.11-rc5-aerc3-split6/arch/i386/Kconfig
--- linux-2.6.11-rc5/arch/i386/Kconfig  2005-02-24 11:39:54.0 -0500
+++ patch-2.6.11-rc5-aerc3-split6/arch/i386/Kconfig 2005-03-11 
11:28:42.0 -0500
@@ -1131,8 +1131,6 @@ config PCI_MMCONFIG
select ACPI_BOOT
default y
 
-source "drivers/pci/pcie/Kconfig"
-
 source "drivers/pci/Kconfig"
 
 config ISA
diff -urpN linux-2.6.11-rc5/drivers/pci/Kconfig 
patch-2.6.11-rc5-aerc3-split6/drivers/pci/Kconfig
--- linux-2.6.11-rc5/drivers/pci/Kconfig2005-02-24 11:40:05.0 
-0500
+++ patch-2.6.11-rc5-aerc3-split6/drivers/pci/Kconfig   2005-03-11 
12:17:29.0 -0500
@@ -1,4 +1,9 @@
 #
+# PCI Express configuration
+#
+source "drivers/pci/pcie/Kconfig"
+
+#
 # PCI configuration
 #
 config PCI_MSI
diff -urpN linux-2.6.11-rc5/drivers/pci/pcie/aer/aerdrv.c 
patch-2.6.11-rc5-aerc3-split6/drivers/pci/pcie/aer/aerdrv.c
--- linux-2.6.11-rc5/drivers/pci/pcie/aer/aerdrv.c  1969-12-31 
19:00:00.0 -0500
+++ patch-2.6.11-rc5-aerc3-split6/drivers/pci/pcie/aer/aerdrv.c 2005-03-10 
10:25:15.0 -0500
@@ -0,0 +1,254 @@
+/*
+ * Copyright (C) 2005 Intel
+ * Copyright (C) Tom Long Nguyen ([EMAIL PROTECTED])
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "aerdrv.h"
+
+/*
+ * Version Information
+ */
+#define DRIVER_VERSION "v1.0"
+#define DRIVER_AUTHOR "[EMAIL PROTECTED]"
+#define DRIVER_DESC "Root Port Advanced Error Reporting Driver"
+MODULE_AUTHOR(DRIVER_AUTHOR);
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_LICENSE("GPL");
+
+static int __devinit aerdrv_probe (struct pcie_device *dev, 
+   const struct pcie_port_service_id *id );
+static void aerdrv_remove(struct pcie_device *dev);
+static int aerdrv_suspend(struct pcie_device *dev, u32 state) {return 0;}
+static int aerdrv_resume(struct pcie_device *dev) {return 0;}
+
+/*
+ * PCI Express bus's AER Root service driver data structure
+ */
+static struct pcie_port_service_id service_id[] = { { 
+   .vendor = PCI_ANY_ID, 
+   .device = PCI_ANY_ID,
+   .port_type = PCIE_RC_PORT, 
+   .service_type = PCIE_PORT_SERVICE_AER,
+   }, { /* end: all zeroes */ }
+};
+
+static struct pcie_port_service_driver root_aerdrv = {
+   .name   = "aer",
+   .id_table   = _id[0],
+
+   .probe  = aerdrv_probe,
+   .remove = aerdrv_remove,
+
+   .suspend= aerdrv_suspend,
+   .resume = aerdrv_resume,
+};
+
+/**
+ * aerdrv_irq - Root Port's ISR
+ * @irq: IRQ assigned to Root Port
+ * @context: pointer to Root Port data structure
+ * @r: pointer struct pt_regs
+ *
+ * Invoked when Root Port detects AER messages.
+ **/
+irqreturn_t aerdrv_irq(int irq, void *context, struct pt_regs * r)
+{
+   unsigned int status, id;
+   struct pcie_device *pdev = (struct pcie_device *)context;
+   struct aer_rpc *rpc = get_service_data(pdev);
+   int next_prod_idx;
+   unsigned long flags;
+
+   /* 
+* Must lock access to Root Error Status Reg, Root Error ID Reg, 
+* and Root error producer/consumer index 
+*/
+   spin_lock_irqsave(>e_lock, flags);
+
+   /* Read error status */
+   pci_read_config_dword(pdev->port, ROOT_ERROR_STATUS_REG, );
+   if (!(status & ROOT_ERR_STATUS_MASKS)) {
+   spin_unlock_irqrestore(>e_lock, flags);
+   return IRQ_NONE;
+   }
+
+   /* Read error source and clear error status */
+   pci_read_config_dword(pdev->port, CORRECTABLE_SOURCE_ID_REG, );
+   pci_write_config_dword(pdev->port, ROOT_ERROR_STATUS_REG, status);
+   
+   /* Store error source for later DPC handler */
+   next_prod_idx = rpc->prod_idx + 1;
+   if (next_prod_idx == AER_ERROR_SOURCES_MAX)
+   next_prod_idx = 0;
+   if (next_prod_idx == rpc->cons_idx) {
+   /* 
+* Error Storm Condition - possibly the same error occurred.
+* Drop the error.
+*/
+   spin_unlock_irqrestore(>e_lock, flags);
+   return IRQ_HANDLED;
+   } 
+   rpc->e_sources[rpc->prod_idx].status =  status & ROOT_ERR_STATUS_MASKS;
+   rpc->e_sources[rpc->prod_idx].id =  id;
+   rpc->prod_idx = next_prod_idx;
+   spin_unlock_irqrestore(>e_lock, flags);
+   
+   /*  Invoke DPC handler */
+   schedule_work(>dpc_handler);
+
+   return IRQ_HANDLED;
+}
+
+/**
+ * aerdrv_alloc_rpc - allocate Root Port data structure
+ * @dev: pointer to the pcie_dev data structure
+ *
+ * Invoked when Root Port's AER service is loaded.
+ **/
+static struct aer_rpc*

Re: A new 10GB Ethernet Driver by Chelsio Communications

On Fri, Mar 11, 2005 at 11:21:32AM -0800, Andrew Morton wrote:
> Christoph Lameter <[EMAIL PROTECTED]> wrote:
> >
> > A Linux driver for the Chelsio 10Gb Ethernet Network Controller by
> >  Chelsio (http://www.chelsio.com). This driver supports the Chelsio N210
> >  NIC and is backward compatible with the Chelsio N110 model 10Gb NICs.
> 
> Thanks, Christoph.
> 
> The 400k patch was too large for the vger email server so I have uploaded it 
> to
> 
>  
> http://www.zip.com.au/~akpm/linux/patches/stuff/a-new-10gb-ethernet-driver-by-chelsio-communications.patch
> 
> for reviewers.
>...

- my3126.c is unused (because t1_my3126_ops isn't used anywhere)
- what are the EXTRA_CFLAGS in drivers/net/chelsio/Makefile for?
- $(cxgb-y) in drivers/net/chelsio/Makefile seems to be unneeded
- completely unused global functions:
  - espi.c: t1_espi_get_intr_counts
  - sge.c: t1_sge_get_intr_counts
- the following functions can be made static:
  - sge.c: t1_espi_workaround
  - sge.c: t1_sge_tx
  - subr.c: __t1_tpi_read
  - subr.c: __t1_tpi_write
  - subr.c: t1_wait_op_done


cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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/

[2.6.11-rc5-mm1 patch] fs/reiser4/: possible cleanups

This patch contains possible cleanups including the following:
- make needlessly global code static
- plugin/compress/minilzo.c: many cleanups
- remove or #if 0 the following unused global functions:
  - context.c: check_contexts
  - flush.c: jnode_tostring
  - flush.c: znode_tostring
  - flush.c: pos_tostring
  - flush_queue.c: fq_by_jnode
  - inode.c: get_reiser4_inode_by_key
  - lock.c: lock_mode
  - plugin/cryptcompress.c: set_nrpages_by_inode
  - file.c: readpages_unix_file
  - plugin/item/ctail.c: ctail_make_unprepped_cluster
  - plugin/item/extent_item_ops.c: show_extent
  - plugin/item/tail.c: show_tail
  - tree_walk.c: tree_walk

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch was already sent on:
- 3 Mar 2005

 fs/reiser4/block_alloc.c |2 
 fs/reiser4/cluster.h |3 
 fs/reiser4/context.c |2 
 fs/reiser4/debug.c   |   13 +
 fs/reiser4/debug.h   |2 
 fs/reiser4/flush.c   |6 
 fs/reiser4/flush.h   |4 
 fs/reiser4/flush_queue.c |7 
 fs/reiser4/inode.c   |6 
 fs/reiser4/inode.h   |3 
 fs/reiser4/jnode.c   |8 -
 fs/reiser4/jnode.h   |2 
 fs/reiser4/lock.c|2 
 fs/reiser4/lock.h|1 
 fs/reiser4/page_cache.c  |2 
 fs/reiser4/plugin/compress/lzoconf.h |   23 --
 fs/reiser4/plugin/compress/minilzo.c |  179 +--
 fs/reiser4/plugin/cryptcompress.c|   15 -
 fs/reiser4/plugin/file/file.c|   14 -
 fs/reiser4/plugin/file/funcs.h   |2 
 fs/reiser4/plugin/item/ctail.c   |4 
 fs/reiser4/plugin/item/ctail.h   |1 
 fs/reiser4/plugin/item/extent.h  |1 
 fs/reiser4/plugin/item/extent_item_ops.c |2 
 fs/reiser4/plugin/item/tail.c|5 
 fs/reiser4/plugin/item/tail.h|1 
 fs/reiser4/plugin/object.c   |2 
 fs/reiser4/plugin/object.h   |1 
 fs/reiser4/tree_walk.c   |4 
 fs/reiser4/txnmgr.h  |1 
 fs/reiser4/vfs_ops.c |   14 -
 fs/reiser4/wander.c  |2 
 fs/reiser4/znode.c   |4 
 33 files changed, 66 insertions(+), 272 deletions(-)

--- linux-2.6.11-rc5-mm1-full/fs/reiser4/block_alloc.c.old  2005-03-01 
21:18:07.0 +0100
+++ linux-2.6.11-rc5-mm1-full/fs/reiser4/block_alloc.c  2005-03-01 
21:18:14.0 +0100
@@ -932,7 +932,7 @@
 #if REISER4_DEBUG
 
 /* check "allocated" state of given block range */
-void
+static void
 reiser4_check_blocks(const reiser4_block_nr * start, const reiser4_block_nr * 
len, int desired)
 {
sa_check_blocks(start, len, desired);
--- linux-2.6.11-rc5-mm1-full/fs/reiser4/context.c.old  2005-03-01 
21:18:31.0 +0100
+++ linux-2.6.11-rc5-mm1-full/fs/reiser4/context.c  2005-03-01 
21:19:08.0 +0100
@@ -47,6 +47,7 @@
 /* lock protecting access to active_contexts. */
 spinlock_t active_contexts_lock;
 
+#if 0
 void
 check_contexts(void)
 {
@@ -58,6 +59,7 @@
}
spin_unlock(_contexts_lock);
 }
+#endif  /*  0  */
 
 #endif /* REISER4_DEBUG */
 
--- linux-2.6.11-rc5-mm1-full/fs/reiser4/debug.h.old2005-03-01 
21:19:25.0 +0100
+++ linux-2.6.11-rc5-mm1-full/fs/reiser4/debug.h2005-03-01 
21:19:31.0 +0100
@@ -176,8 +176,6 @@
REISER4_CHECK_NODE = 0x0008
 } reiser4_debug_flags;
 
-extern int reiser4_is_debugged(struct super_block *super, __u32 flag);
-
 extern int is_in_reiser4_context(void);
 
 /*
--- linux-2.6.11-rc5-mm1-full/fs/reiser4/debug.c.old2005-03-01 
21:19:38.0 +0100
+++ linux-2.6.11-rc5-mm1-full/fs/reiser4/debug.c2005-03-01 
22:54:38.0 +0100
@@ -61,6 +61,11 @@
  */
 static spinlock_t panic_guard = SPIN_LOCK_UNLOCKED;
 
+#if REISER4_DEBUG
+static int
+reiser4_is_debugged(struct super_block *super, __u32 flag);
+#endif
+
 /* Your best friend. Call it on each occasion.  This is called by
 fs/reiser4/debug.h:reiser4_panic(). */
 reiser4_internal void
@@ -303,19 +308,19 @@
return result;
 }
 
-/* REISER4_DEBUG */
-#endif
-
 /*
  * check that some bits specified by @flags are set in ->debug_flags of the
  * super block.
  */
-reiser4_internal int
+static int
 reiser4_is_debugged(struct super_block *super, __u32 flag)
 {
return get_super_private(super)->debug_flags & flag;
 }
 
+/* REISER4_DEBUG */
+#endif
+
 /* allocate memory. This calls kmalloc(), performs some additional checks, and
keeps track of how many memory was allocated on behalf of current super
block. */
--- linux-2.6.11-rc5-mm1-full/fs/reiser4/flush.h.old2005-03-01 
21:21:31.0 +0100
+++ linux-2.6.11-rc5-mm1-full/fs/reiser4/flush.h2005-03-01

Re: Linux 2.6.11.2

2005-03-11 Thread Gene Heskett

On Friday 11 March 2005 14:23, Bill Davidsen wrote:
>Gene Heskett wrote:
>> Somewhat Greg, it caught me out.  OTOH, once we know that .2 needs
>> .1, we'll be ok.  And it does give a quick method for us frogs to
>> define if one of them is a regression.  The only thing that should
>> break if we leave one out of the squence is the EXTRAVERSION path
>> in the Makefile & we can certainly fix that easily enough for
>> testing.
>
>2nd that, I'm so delighted to have -stable that I will happily
> accept patches of what ever type you find easiest to produce, in
> this case sequential incrementals. Just don't screw the process by
> changing it, we can cope! Anyone who can't figure out how to
> generate the single big diff against mainline shouldn't be patching
> kernels ;-)

Humm, that might be a pretty high fence for me to jump there Bill.  
ATM, what I'm running is 11.2, with the bk-ieee1394.patch, and for my 
uses, it certainly seems to be bulletproof.  But then I'm not running 
a server with 30,000 clients either, this is your classic geeks 
desktop here, even if the geek is 70 years old.  Firewire Just 
Works(TM), usb seems to be back among the living and I'm a relatively 
happy camper.  Till the next patch comes out & I'll just *have* to 
try it...  :)

Heck, if the next .3 patch just was a relabeled bk-ieee1394.patch, I'd 
be in Hog Heaven.  And if the next patch after that made my 
pcHDTV-3000 card work out of the box,  I'd offer the patch maker a 
couple of his favorite libations.  Hows that for a good deal?  So 
far, thats a re-install after every reboot situation now because the 
replacement modules are built out of the tree.

>> Question?  Is it a given that these, if they don't have warts,
>> will be in mainline 2.6.12?
>
>I think Linus noted his intention to grab the fixes he likes. That's
> not a determanent process by any means ;-)

We've noted that previously.  OTOH, he has always managed to come up 
with perfectly valid objections to those not accepted if queried 
about the whynots.  I can't argue with that for a heartbeat since I 
don't and cannot come close to having an overall view in as much 
detail as he obviously keeps in his head.

-- 
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.
-
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/

Re: [PATCH 4/9] UML - Export gcov symbol based on gcc version

On Fri, Mar 11, 2005 at 06:53:15PM -0500, Jeff Dike wrote:
> [EMAIL PROTECTED] said:
> > And therefore you added a patch that helps only those distros at the
> > price of breaking other people and distros using sane compilers? 
> 
> Didn't you start this thread by pointing out that SuSE has a gcc 3.3.4
> which isn't?  I would call that a compiler which lies about its version, and
> for the purposes of this argument, I would say that it is not a sane
> compiler.

I said:

<--  snip  -->

This line has to be something like

( (__GNUC__ == 3 && __GNUC_MINOR__ == 3 && __GNUC_PATCHLEVEL__ >= 4) && \
   HEAVILY_PATCHES_SUSE_GCC ) 

<--  snip  -->

IOW:
Only heavily patches gcc 3.3 compiler define __gcov_init.


Anton's original report said that he needs __gcov_init with
SuSE gcc 3.3.4 .


> Given this, your original (correct) claim was that my patch would not help
> such compilers.  Are you now claiming that it does help such compilers, and
> no one else?

No, my claim is that no sane gcc 3.3 defines __gcov_init.

>   Jeff

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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/

Re: status of the USB w9968cf.c driver in kernel 2.6?

On Fri, Mar 04, 2005 at 10:58:33AM +0100, Luca Risolia wrote:
> Scrive Adrian Bunk <[EMAIL PROTECTED]>:
> 
> > On Tue, Mar 01, 2005 at 06:46:03PM +0100, Luca Risolia wrote:
> > > Scrive Adrian Bunk <[EMAIL PROTECTED]>: 
>...
> > > > - there's no w9968cf-vpp module in the kernel sources 
> > >  
> > > w9968cf-vpp is an optional, gpl'ed module, which can not be included in 
> > > the
> > 
> > > mainline kernel, as I explained in the documentation of the driver. 
> > 
> >   Please keep in mind that official kernels do not include the second 
> >   module for performance purposes.
> > 
> > What exactly does this mean?
> 
> Frame decoding/decompression should be done in userspace, although you can 
> still download and use a separate kernel module.
>...

If it's deprecated to do this in a kernel module, shouldn't at some time 
the EXPORT_SYMBOL's for the decoding/decompression module be removed 
from the kernel?

> Regards,
> Luca

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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/

Re: Last night Linus bk - netfilter busted?

2005-03-11 Thread Patrick McHardy

Herbert Xu wrote:
Patrick McHardy <[EMAIL PROTECTED]> wrote:
You're right, good catch. IPT_RETURN is interpreted internally by
ip_tables, but since the value changed it isn't recognized by ip_tables
anymore and returned to nf_iterate() as NF_REPEAT. This patch restores
the old value.

Please fix netfilter_arp while you're at it since it does exactly
the same thing.
New patch attached, thanks.
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2005/03/11 23:54:54+01:00 [EMAIL PROTECTED] 
#   [NETFILTER]: Fix iptables userspace compatibility breakage
#   
#   Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
# 
# include/linux/netfilter_ipv6/ip6_tables.h
#   2005/03/11 23:54:44+01:00 [EMAIL PROTECTED] +1 -1
#   [NETFILTER]: Fix iptables userspace compatibility breakage
#   
#   Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
# 
# include/linux/netfilter_ipv4/ip_tables.h
#   2005/03/11 23:54:44+01:00 [EMAIL PROTECTED] +1 -1
#   [NETFILTER]: Fix iptables userspace compatibility breakage
#   
#   Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
# 
# include/linux/netfilter_arp/arp_tables.h
#   2005/03/11 23:54:44+01:00 [EMAIL PROTECTED] +1 -1
#   [NETFILTER]: Fix iptables userspace compatibility breakage
#   
#   Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
# 
diff -Nru a/include/linux/netfilter_arp/arp_tables.h 
b/include/linux/netfilter_arp/arp_tables.h
--- a/include/linux/netfilter_arp/arp_tables.h  2005-03-11 23:55:09 +01:00
+++ b/include/linux/netfilter_arp/arp_tables.h  2005-03-11 23:55:09 +01:00
@@ -154,7 +154,7 @@
 #define ARPT_CONTINUE 0x
 
 /* For standard target */
-#define ARPT_RETURN (-NF_MAX_VERDICT - 1)
+#define ARPT_RETURN (-NF_REPEAT - 1)
 
 /* The argument to ARPT_SO_GET_INFO */
 struct arpt_getinfo
diff -Nru a/include/linux/netfilter_ipv4/ip_tables.h 
b/include/linux/netfilter_ipv4/ip_tables.h
--- a/include/linux/netfilter_ipv4/ip_tables.h  2005-03-11 23:55:09 +01:00
+++ b/include/linux/netfilter_ipv4/ip_tables.h  2005-03-11 23:55:09 +01:00
@@ -166,7 +166,7 @@
 #define IPT_CONTINUE 0x
 
 /* For standard target */
-#define IPT_RETURN (-NF_MAX_VERDICT - 1)
+#define IPT_RETURN (-NF_REPEAT - 1)
 
 /* TCP matching stuff */
 struct ipt_tcp
diff -Nru a/include/linux/netfilter_ipv6/ip6_tables.h 
b/include/linux/netfilter_ipv6/ip6_tables.h
--- a/include/linux/netfilter_ipv6/ip6_tables.h 2005-03-11 23:55:09 +01:00
+++ b/include/linux/netfilter_ipv6/ip6_tables.h 2005-03-11 23:55:09 +01:00
@@ -166,7 +166,7 @@
 #define IP6T_CONTINUE 0x
 
 /* For standard target */
-#define IP6T_RETURN (-NF_MAX_VERDICT - 1)
+#define IP6T_RETURN (-NF_REPEAT - 1)
 
 /* TCP matching stuff */
 struct ip6t_tcp

Re: AGP bogosities

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.
-
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/

[PATCH 5/6] PCI Express Advanced Error Reporting Driver

This patch includes the source code of core component of PCI Express
Advanced Error Reporting driver.

Signed-off-by: T. Long Nguyen <[EMAIL PROTECTED]>


diff -urpN linux-2.6.11-rc5/drivers/pci/pcie/aer/aerdrv_core.c 
patch-2.6.11-rc5-aerc3-split5/drivers/pci/pcie/aer/aerdrv_core.c
--- linux-2.6.11-rc5/drivers/pci/pcie/aer/aerdrv_core.c 1969-12-31 
19:00:00.0 -0500
+++ patch-2.6.11-rc5-aerc3-split5/drivers/pci/pcie/aer/aerdrv_core.c
2005-03-10 10:31:09.0 -0500
@@ -0,0 +1,911 @@
+/*
+ * Copyright (C) 2005 Intel
+ * Copyright (C) Tom Long Nguyen ([EMAIL PROTECTED])
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "aerdrv.h"
+
+LIST_HEAD(rc_list);/* Define Root Complex List */
+static int verbose = VERBOSE_LIMIT_DISPLAY;
+static int auto_mode = 1;
+static int aer_init_flag = 0;
+
+/**
+ * print_source_devices - print a list of AER devices in Root Port hierarchy
+ * @head: pointer to Root Port's children list
+ * @page: pointer to a buffer
+ *
+ * Invoked by user interface status. Caller must acquire Root semaphore prior
+ * to calling. 
+ **/
+static int print_source_devices(struct list_head *head, char *page)
+{
+   struct list_head *entry;
+   struct aer_device *dev;
+   char *p = page;
+   char *error_name;
+
+   list_for_each(entry, head) {
+   dev = container_of(entry, struct aer_device, node);
+   p += sprintf(p, "  Bus %d, device %d, function %d:\n",
+   AER_DEVICE_BUS(dev->requestor_id),
+   AER_DEVICE_DEV(dev->requestor_id),
+   AER_DEVICE_FUNC(dev->requestor_id)); 
+   if (dev->handle) {
+   p += sprintf(p, "Class %04x: PCI device 
%02x:%02x\n",
+   dev->class_code, dev->device, dev->vendor);
+   p += sprintf(p, "COR_ERR %d, NONFATAL_ERR %d,"
+   " FATAL_ERR %d\n",
+   dev->correctables, 
+   dev->nonfatals,
+   dev->fatals);
+   } else
+   p += sprintf(p, "COR_ERR %d, UNCOR_ERR %d\n",
+   dev->correctables, 
+   dev->uncorrectables);
+   error_name = aer_get_error_source_name(>last_recorded_err);
+   if (error_name) {
+   p += sprintf(p, "Last Error Detected @ "
+   "%d/%d/%d %d:%d:%d - %s\n", 
+   dev->time_stamp.month, dev->time_stamp.day, 
+   dev->time_stamp.year + 1900, dev->time_stamp.hours,
+   dev->time_stamp.minutes, dev->time_stamp.seconds,
+   error_name);
+   }
+   p += sprintf(p, "Register Callbacks - %s\n",
+   (dev->handle != NULL) ? "Yes" : "No");
+   if (PCIE_PORT(dev->attribute.type)) 
+   p += print_source_devices(>children, p);
+   }
+
+   return p-page;
+}
+
+/**
+ * search_node - search for a Root Port node associated with this
+ *  downstream ID
+ * @requestor_id: endpoint source ID
+ *
+ * Invoked to search for an associated Root Port node.
+ * A rc_list list, initialized during driver init, contains physical
+ * Root Port devices in Root Complex, no semaphore access lock is 
+ * necessary prior to calling.
+ **/
+static struct aer_rpc* search_node(unsigned short requestor_id)
+{
+   struct list_head *entry;
+   struct aer_rpc *rpc = NULL;
+   int bus = AER_DEVICE_BUS(requestor_id);
+
+   if (!list_empty(_list)) {
+   struct aer_rpc *tmp;
+
+   list_for_each(entry, _list) {
+   tmp = container_of(entry, struct aer_rpc, node);
+   if ((bus >= tmp->secondary && bus <= tmp->subordinate)||
+   tmp->self_id == requestor_id) {
+   rpc = tmp;
+   break;  
+   }
+   }
+   }
+
+   return rpc; 
+}
+
+/**
+ * search_direct_parent - search for a direct PCIE Port for endpoint
+ * @head: pointer to a Root Port's children list
+ * @id: endpoint source ID
+ *
+ * Invoked to search for a direct one-to-one PCIE Port associated with
+ * endpoint. Caller must acquire Root semaphore "rpc_sema" prior to
+ * calling.
+ **/
+static struct aer_device* search_direct_parent(struct list_head *head, u16 id)
+{
+   struct list_head *entry;
+   struct aer_device *parent = NULL;
+
+   if (list_empty(head)) 
+   return NULL;
+
+   list_for_each(entry, head) {
+   struct aer_device *dev;
+   int secondary, subordinate, bus =

Re: AGP bogosities

2005-03-11 Thread Martin Schlemmer

On Fri, 2005-03-11 at 22:46 +, J.A. Magallon wrote:
> On 03.11, Dave Jones wrote:
> > On Fri, Mar 11, 2005 at 10:11:08PM +, J.A. Magallon wrote:
> >  > 
> >  > On 03.11, Paul Mackerras wrote:
> >  > > Linus,
> >  > > 
> >  > ...
> >  > > 
> >  > > Oh, and by the way, I have 3D working 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 :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 
> > :00:00.0 into 4x mode
> >  > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 
> > :01:00.0 into 4x mode
> >  > Mar 11 23:00:29 werewolf kernel: agpgart: Found an AGP 3.0 compliant 
> > device at :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 
> > :00:00.0 into 4x mode
> >  > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 
> > :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 :00:00.0.
> agpgart: Putting AGP V3 device at :00:00.0 into 8x mode
> agpgart: Putting AGP V3 device at :01:00.0 into 8x mode
> agpgart: Found an AGP 3.0 compliant device at :00:00.0.
> agpgart: Putting AGP V3 device at :00:00.0 into 8x mode
> agpgart: Putting AGP V3 device at :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 :00:00.0.
agpgart: X tried to set rate=x12. Setting to AGP3 x8 mode.
agpgart: Putting AGP V3 device at :00:00.0 into 8x mode
agpgart: Putting AGP V3 device at :01:00.0 into 8x mode
---

(ok, so old driver is a bit dodgy)

--new--
agpgart: Found an AGP 3.0 compliant device at :00:00.0.
agpgart: Putting AGP V3 device at :00:00.0 into 8x mode
agpgart: Putting AGP V3 device at :01:00.0 into 8x mode
---


-- 
Martin Schlemmer



signature.asc
Description: This is a digitally signed message part

Re: AGP bogosities

2005-03-11 Thread Martin Schlemmer

On Fri, 2005-03-11 at 23:17 +, J.A. Magallon wrote:
> On 03.12, Martin Schlemmer wrote:
> > On Fri, 2005-03-11 at 22:46 +, J.A. Magallon wrote:
> > > On 03.11, Dave Jones wrote:
> > > > On Fri, Mar 11, 2005 at 10:11:08PM +, J.A. Magallon wrote:
> > > >  > 
> > > >  > On 03.11, Paul 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 :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 
> > > > :00:00.0 into 4x mode
> > > >  > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 
> > > > :01:00.0 into 4x mode
> > > >  > Mar 11 23:00:29 werewolf kernel: agpgart: Found an AGP 3.0 compliant 
> > > > device at :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 
> > > > :00:00.0 into 4x mode
> > > >  > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 
> > > > :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 :00:00.0.
> > > agpgart: Putting AGP V3 device at :00:00.0 into 8x mode
> > > agpgart: Putting AGP V3 device at :01:00.0 into 8x mode
> > > agpgart: Found an AGP 3.0 compliant device at :00:00.0.
> > > agpgart: Putting AGP V3 device at :00:00.0 into 8x mode
> > > agpgart: Putting AGP V3 device at :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 :00:00.0.
> > agpgart: X tried to set rate=x12. Setting to AGP3 x8 mode.
> > agpgart: Putting AGP V3 device at :00:00.0 into 8x mode
> > agpgart: Putting AGP V3 device at :01:00.0 into 8x mode
> > ---
> > 
> > (ok, so old driver is a bit dodgy)
> > 
> > --new--
> > agpgart: Found an AGP 3.0 compliant device at :00:00.0.
> > agpgart: Putting AGP V3 device at :00:00.0 into 8x mode
> > agpgart: Putting AGP V3 device at :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



signature.asc
Description: This is a digitally signed message part

Re: AGP bogosities


On 03.12, Martin Schlemmer wrote:
> On Fri, 2005-03-11 at 23:17 +, J.A. Magallon wrote:
> > On 03.12, Martin Schlemmer wrote:
> > > On Fri, 2005-03-11 at 22:46 +, J.A. Magallon wrote:
> > > > On 03.11, Dave Jones wrote:
> > > > > On Fri, Mar 11, 2005 at 10:11:08PM +, J.A. Magallon 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  \   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


-
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/

Re: i830 DRM problems

2005-03-11 Thread Dave Airlie

> 
> I am experiencing problems with DRM on my Dell Optiplex GX260.
> I am running a Debian Sarge with Vanilla Linux 2.6.11 and XFree 4.3.0.
> This one appeared while playing crack-attack and lead to a crash
> of the X server.
> 

a) does it work with 2.6.10?
b) does it work if you turn off intelfb?

Dave.
-
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/

Re: AGP bogosities

2005-03-11 Thread Bjorn Helgaas

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?

: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 8000 (32-bit, prefetchable) [size=128M]
I/O ports at 0d00 [size=256]
Memory at 8802 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at 8800 [disabled] [size=128K]
Capabilities: [58] AGP version 2.0
Capabilities: [50] Power Management version 2

: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: 4000-4fff
Memory behind bridge: a000-a40f
Capabilities: [dc] Power Management version 1

: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 a4032000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2

: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 a4031000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2

: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 a403 (32-bit, non-prefetchable) [size=256]
Capabilities: [40] Power Management version 2

: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 a000 (32-bit, prefetchable) [size=64M]
I/O ports at 4000 [disabled] [size=256]
Memory at a402 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at a400 [disabled] [size=128K]
Capabilities: [50] Power Management version 2

: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 d0022000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2

: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 d0021000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2

: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 d002 (32-bit, non-prefetchable) [size=256]
Capabilities: [40] Power Management version 2

: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

:a0:03.0 Ethernet controller: Intel Corp. 82540EM Gigabit Ethernet 
Controller (rev 02)
Subsystem: Hewlett-Packard Company:

Re: [PATCH] mm counter operations through macros

Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> This patch extracts all the operations on counters protected by the
> page table lock (currently rss and anon_rss) into definitions in
> include/linux/sched.h. All rss operations are performed through
> the following macros:
>
> get_mm_counter(mm, member)-> Obtain the value of a counter
> set_mm_counter(mm, member, value) -> Set the value of a counter
> update_mm_counter(mm, member, value)  -> Add to a counter
> inc_mm_counter(mm, member)-> Increment a counter
> dec_mm_counter(mm, member)-> Decrement a counter

I spose it makes sense, if we'll be making scalability changes in there.

> 
> +#define set_mm_counter(mm, member, value) (mm)->member = (value)
> +#define get_mm_counter(mm, member) ((mm)->member)
> +#define update_mm_counter(mm, member, value) (mm)->member += (value)
> +#define inc_mm_counter(mm, member) (mm)->member++
> +#define dec_mm_counter(mm, member) (mm)->member--
> +#define MM_COUNTER_T unsigned long

Would prefer `mm_counter_t' here.

Why not a typedef?

> @@ -231,9 +237,13 @@ struct mm_struct {
>   unsigned long start_code, end_code, start_data, end_data;
>   unsigned long start_brk, brk, start_stack;
>   unsigned long arg_start, arg_end, env_start, env_end;
> - unsigned long rss, anon_rss, total_vm, locked_vm, shared_vm;
> + unsigned long total_vm, locked_vm, shared_vm;
>   unsigned long exec_vm, stack_vm, reserved_vm, def_flags, nr_ptes;
> 
> + /* Special counters protected by the page_table_lock */
> + MM_COUNTER_T rss;
> + MM_COUNTER_T anon_rss;
> +

Why were only two counters converted?

Could I suggest that you rename all these counters, so that code which
fails to use the macros won't compile?

That renaming can be hidden in the header file: add an underscore to the
front of all the identifiers, paste that underscore back within the macros.

-
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/

Re: AGP bogosities


On 03.12, Martin Schlemmer wrote:
> On Fri, 2005-03-11 at 22:46 +, J.A. Magallon wrote:
> > On 03.11, Dave Jones wrote:
> > > On Fri, Mar 11, 2005 at 10:11:08PM +, J.A. Magallon wrote:
> > >  > 
> > >  > On 03.11, Paul Mackerras wrote:
> > >  > > Linus,
> > >  > > 
> > >  > ...
> > >  > > 
> > >  > > 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 :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 
> > > :00:00.0 into 4x mode
> > >  > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 
> > > :01:00.0 into 4x mode
> > >  > Mar 11 23:00:29 werewolf kernel: agpgart: Found an AGP 3.0 compliant 
> > > device at :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 
> > > :00:00.0 into 4x mode
> > >  > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 
> > > :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 :00:00.0.
> > agpgart: Putting AGP V3 device at :00:00.0 into 8x mode
> > agpgart: Putting AGP V3 device at :01:00.0 into 8x mode
> > agpgart: Found an AGP 3.0 compliant device at :00:00.0.
> > agpgart: Putting AGP V3 device at :00:00.0 into 8x mode
> > agpgart: Putting AGP V3 device at :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 :00:00.0.
> agpgart: X tried to set rate=x12. Setting to AGP3 x8 mode.
> agpgart: Putting AGP V3 device at :00:00.0 into 8x mode
> agpgart: Putting AGP V3 device at :01:00.0 into 8x mode
> ---
> 
> (ok, so old driver is a bit dodgy)
> 
> --new--
> agpgart: Found an AGP 3.0 compliant device at :00:00.0.
> agpgart: Putting AGP V3 device at :00:00.0 into 8x mode
> agpgart: Putting AGP V3 device at :01:00.0 into 8x mode
> ---
> 

Just curiosity, what says your /proc/driver/nvidia/agp/status ?

--
J.A. Magallon  \   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


-
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/

[PATCH 4/6] PCI Express Advanced Error Reporting Driver

This patch includes the source code of Root callback-handle component
of PCI Express Advanced Error Reporting driver.

Signed-off-by: T. Long Nguyen <[EMAIL PROTECTED]>


diff -urpN linux-2.6.11-rc5/drivers/pci/pcie/aer/aerdrv_rpc_handle.c 
patch-2.6.11-rc5-aerc3-split4/drivers/pci/pcie/aer/aerdrv_rpc_handle.c
--- linux-2.6.11-rc5/drivers/pci/pcie/aer/aerdrv_rpc_handle.c   1969-12-31 
19:00:00.0 -0500
+++ patch-2.6.11-rc5-aerc3-split4/drivers/pci/pcie/aer/aerdrv_rpc_handle.c  
2005-03-09 13:25:36.0 -0500
@@ -0,0 +1,96 @@
+/*
+ * Copyright (C) 2005 Intel
+ * Copyright (C) Tom Long Nguyen ([EMAIL PROTECTED])
+ *
+ */
+#include 
+#include 
+#include 
+
+#include "aerdrv.h"
+
+static int aer_root_notify(unsigned short requestor_id, union aer_error 
*error);
+static int aer_root_get_header(unsigned short requestor_id, 
+   union aer_error *error, struct header_log_regs *log);
+
+/* AER callback handle data structure */
+struct pcie_aer_handle aer_root_handle = {
+   .notify = aer_root_notify,
+   .get_header = aer_root_get_header,
+};
+
+/**
+ * aer_root_notify - process an error being notified by AER Root driver
+ * @requestor_id: an identification
+ * @error: pointer to an error data structure
+ *
+ * Invoked when AER Root Port itself generates error messages.
+ **/
+static int aer_root_notify(unsigned short requestor_id, union aer_error *error)
+{
+   struct pci_dev *pdev = get_root_pci_dev(requestor_id);
+   int pos, retval = -EINVAL;
+   u32 status;
+   u16 reg16;
+   
+   if (error->type == AER_CORRECTABLE) {
+   pci_read_config_dword(pdev, 
+   CORRECTABLE_ERROR_STATUS_REG, );
+   if (status & ERR_CORRECTABLE_ERROR_MASK) {
+   pci_write_config_dword(pdev, 
+   CORRECTABLE_ERROR_STATUS_REG, status);
+   error->source.type = AER_CORRECTABLE;
+   error->source.status = status;
+   retval = 0;
+   }   
+   } else {
+   pci_read_config_dword(pdev, 
+   UNCORRECTABLE_ERROR_STATUS_REG, );
+   if (status & ERR_UNCORRECTABLE_ERROR_MASK) {
+   u32 severity;
+
+   pci_read_config_dword(pdev, 
+   UNCORRECTABLE_ERROR_SEVERITY_REG, );
+   pci_write_config_dword(pdev, 
+   UNCORRECTABLE_ERROR_STATUS_REG, status);
+   if (status & severity)
+   error->source.type = AER_FATAL;
+   else
+   error->source.type = AER_NONFATAL;
+   error->source.status = status;
+   retval = 0;
+   }
+   }
+   
+   /* Clean up Root device status */
+   pos = pci_find_capability(pdev, PCI_CAP_ID_EXP);
+   pci_read_config_word(pdev, pos + PCIE_CAP_DEVICE_STATUS_REG_OFF,);
+   pci_write_config_word(pdev, pos + PCIE_CAP_DEVICE_STATUS_REG_OFF,reg16);
+
+   return retval;
+}
+
+/**
+ * aer_root_get_header - provide TLP header
+ * @requestor_id: an identification
+ * @error: pointer to a TLP header data structure
+ *
+ * Invoked when AER Root Port logs the header of TLP associated with an error.
+ **/
+static int aer_root_get_header(unsigned short requestor_id, 
+   union aer_error *error, struct header_log_regs *log)
+{
+   struct pci_dev *pdev = get_root_pci_dev(requestor_id);
+
+   if (error->type == AER_CORRECTABLE || 
+   !(error->source.status & AER_LOG_TLP_MASKS))
+   return AER_UNSUCCESS;
+   
+   pci_read_config_dword(pdev, HEADER_LOG_REG, >dw0);
+   pci_read_config_dword(pdev, HEADER_LOG_REG + 4, >dw1);
+   pci_read_config_dword(pdev, HEADER_LOG_REG + 8, >dw2);
+   pci_read_config_dword(pdev, HEADER_LOG_REG + 12, >dw3);
+
+   return AER_SUCCESS;
+}
+
-
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/

RE: [PATCH] PCI Express Advanced Error Reporting Driver

Nguyen, Tom L writes:

> The standard PCI Specification calls out SERR and PERR. I am not sure
> about the recent discussion of PCI error of recovery. It is perhaps
> regarding the possibility of recovering from a PERR or SERR. However,
> PCI Express error occurs on the PCI Express link or on behalf of
> transactions occurred on the PCI Express link. PCI Express component,
> which implements PCI Express Advanced Error Reporting Capability, sends
> error message to the Root Port to indicate error occurred on the PCI
> Express link where it is connected. The PCI Express error recovery is on
> behalf of attempting to do a PCI Express link recovery, not PCI error
> recovery. It appears that PCI Express AER is disjoint from PCI error
> recovery.

To give you some context, the recent discussion was about how we could
give a unified interface to drivers for both PCI-Express error
reporting and for the "Enhanced Error Handling" (EEH) facilities we
have on IBM PPC64 boxes.  EEH includes not only the detection and
reporting of errors (for PCI, PCI-X and PCI-Express buses) but also
hardware support for isolating devices when an error is detected, plus
means for resetting individual bus segments or slots, to assist in
recovering a device which has got into a bad state.

Does PCI Express provide any facilities for recovering from errors,
beyond just "try that transaction again"?

Paul.
-
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/

[PATCH 3/6] PCI Express Advanced Error Reporting Driver

This patch includes the source code of event-logged component of PCI
Express Advanced Error Reporting driver.

Signed-off-by: T. Long Nguyen <[EMAIL PROTECTED]>


diff -urpN linux-2.6.11-rc5/drivers/pci/pcie/aer/aerdrv_event.c 
patch-2.6.11-rc5-aerc3-split3/drivers/pci/pcie/aer/aerdrv_event.c
--- linux-2.6.11-rc5/drivers/pci/pcie/aer/aerdrv_event.c1969-12-31 
19:00:00.0 -0500
+++ patch-2.6.11-rc5-aerc3-split3/drivers/pci/pcie/aer/aerdrv_event.c   
2005-03-09 13:26:28.0 -0500
@@ -0,0 +1,752 @@
+/*
+ * Copyright (C) 2005 Intel
+ * Copyright (C) Tom Long Nguyen ([EMAIL PROTECTED])
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "aerdrv.h"
+
+LIST_HEAD(evt_queue);  /* Define Event Queue List */
+static struct semaphore evt_sema;  /* Sema access for evt consume/store */
+
+static int records = 0;
+static int eventlog_size = EVENT_LOG_SIZE_MAX;
+static DECLARE_WAIT_QUEUE_HEAD(kevtd_wait);
+static DECLARE_COMPLETION(kevtd_exit);
+static pid_t kevtd_pid = 0;
+
+static char* aer_error_severity_string[] = {
+   "Uncorrected (Non-Fatal)", 
+   "Uncorrected (Fatal)",
+   "Corrected", 
+   "UnCorrected"
+};
+
+static char* aer_correctable_error_string[] = {
+   "Receiver Error",   /* Bit Position 0   */
+   "Unknown Error Bit 1   ",   /* Bit Position 1   */
+   "Unknown Error Bit 2   ",   /* Bit Position 2   */
+   "Unknown Error Bit 3   ",   /* Bit Position 3   */
+   "Unknown Error Bit 4   ",   /* Bit Position 4   */
+   "Unknown Error Bit 5   ",   /* Bit Position 5   */
+   "Bad TLP   ",   /* Bit Position 6   */
+   "Bad DLLP  ",   /* Bit Position 7   */
+   "RELAY_NUM Rollover",   /* Bit Position 8   */
+   "Unknown Error Bit 9   ",   /* Bit Position 9   */
+   "Unknown Error Bit 10  ",   /* Bit Position 10  */
+   "Unknown Error Bit 11  ",   /* Bit Position 11  */
+   "Replay Timer Timeout  "/* Bit Position 12  */
+   "Unknown Error Bit 13  ",   /* Bit Position 13  */
+   "Unknown Error Bit 14  ",   /* Bit Position 14  */
+   "Unknown Error Bit 15  ",   /* Bit Position 15  */
+   "Unknown Error Bit 16  ",   /* Bit Position 16  */
+   "Unknown Error Bit 17  ",   /* Bit Position 17  */
+   "Unknown Error Bit 18  ",   /* Bit Position 18  */
+   "Unknown Error Bit 19  ",   /* Bit Position 19  */
+   "Unknown Error Bit 20  ",   /* Bit Position 20  */
+   "Unknown Error Bit 21  ",   /* Bit Position 21  */
+   "Unknown Error Bit 22  ",   /* Bit Position 22  */
+   "Unknown Error Bit 23  ",   /* Bit Position 23  */
+   "Unknown Error Bit 24  ",   /* Bit Position 24  */
+   "Unknown Error Bit 25  ",   /* Bit Position 25  */
+   "Unknown Error Bit 26  ",   /* Bit Position 26  */
+   "Unknown Error Bit 27  ",   /* Bit Position 27  */
+   "Unknown Error Bit 28  ",   /* Bit Position 28  */
+   "Unknown Error Bit 29  ",   /* Bit Position 29  */
+   "Unknown Error Bit 30  ",   /* Bit Position 30  */
+   "Unknown Error Bit 31  "/* Bit Position 31  */
+};
+
+static char* aer_uncorrectable_error_string[] = {
+   "Training Severity ",   /* Bit Position 0   */
+   "Unknown Error Bit 1   ",   /* Bit Position 1   */
+   "Unknown Error Bit 2   ",   /* Bit Position 2   */
+   "Unknown Error Bit 3   ",   /* Bit Position 3   */
+   "Data Link Protocol",   /* Bit Position 4   */
+   "Unknown Error Bit 5   ",   /* Bit Position 5   */
+   "Unknown Error Bit 6   ",   /* Bit Position 6   */
+   "Unknown Error Bit 7   ",   /* Bit Position 7   */
+   "Unknown Error Bit 8   ",   /* Bit Position 8   */
+   "Unknown Error Bit 9   ",   /* Bit Position 9   */
+   "Unknown Error Bit 10  ",   /* Bit Position 10  */
+   "Unknown Error Bit 11  ",   /* Bit Position 11  */
+   "Poisoned TLP  ",   /* Bit Position 12  */
+   "Flow Control Protocol ",   /* Bit Position 13  */
+   "Completion Timeout",   /* Bit Position 14  */
+   "Completer Abort   ",   /* Bit Position 15  */
+   "Unexpected Completion ",   /* Bit Position 16  */
+   "Receiver Overflow ",   /* Bit Position 17  */
+   "Malformed TLP ",   /* Bit Position 18  */
+   "ECRC  ",   /* Bit Position 19  */
+   "Unsupported Request   "/* Bit Position 20  */
+   "Unknown Error Bit 21  ",   /* Bit Position 21

[PATCH 0/6] PCI Express Advanced Error Reporting Driver

PCI Express error signaling can occur on the PCI Express link itself
or on behalf of transactions initiated on the link. PCI Express
defines the Advanced Error Reporting capability, which is implemented 
with a PCI Express advanced error reporting extended capability
structure, to provide more robust error reporting. With the Advanced
Error Reporting capability a PCI Express component, which detects an
error, can send an error message to the Root Port associated with
its hierarchy.  

The PCI Express Advanced Error Reporting driver is a PCI Express Bus's 
service driver to handle Advanced Error Reporting on Root Ports. The
PCI Express AER Root driver provides the following functions:

-   A mechanism to allow a driver of a PCI Express component to
register/un-register its AER aware callback handle with the
PCI Express AER Root driver. This mechanism is provided as
an option to allow the PCI Express AER Root driver to query
the PCI Express component device driver to determine more
precisely which error and what severity occurred.

-   A mechanism to process the error reporting message detected
by Root Ports, and 

-   Report the errors to user.

This patchset, which is based on Linux kernel 2.6.11-rc5, consists
of patches in numeric order as they should be applied.

[PATCH 1/6] <- first patch to be applied
[PATCH 2/6] <- second patch to be applied
[PATCH 3/6] <- third patch to be applied
[PATCH 4/6] <- fourth patch to be applied
[PATCH 5/6] <- fifth patch to be applied
[PATCH 6/6] <- last patch to be applied

Please send us any suggestions, feedback, comments or alternative
designs.

Signed-off-by: T. Long Nguyen <[EMAIL PROTECTED]>


-
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/

[PATCH 1/6] PCI Express Advanced Error Reporting Driver

This patch includes PCIEAER-HOWTO.txt, which describes how the PCI
Express Advanced Error Reporting Root driver works.

Signed-off-by: T. Long Nguyen <[EMAIL PROTECTED]>


diff -urpN linux-2.6.11-rc5/Documentation/PCIEAER-HOWTO.txt 
patch-2.6.11-rc5-aerc3-split1/Documentation/PCIEAER-HOWTO.txt
--- linux-2.6.11-rc5/Documentation/PCIEAER-HOWTO.txt1969-12-31 
19:00:00.0 -0500
+++ patch-2.6.11-rc5-aerc3-split1/Documentation/PCIEAER-HOWTO.txt   
2005-03-11 10:25:21.0 -0500
@@ -0,0 +1,712 @@
+   The PCI Express Advanced Error Reporting Root Driver Guide HOWTO
+   T. Long Nguyen <[EMAIL PROTECTED]>
+   02/23/2005
+
+1. About this guide
+
+This guide describes the basics of the PCI Express Advanced Error
+Reporting (AER) Root driver and provides information on how to enable
+the drivers of AER endpoint devices to register/un-register with PCI
+Express Root AER driver.
+
+2. Copyright © Intel Corporation 2005. 
+
+3. What is the PCI Express AER Root Driver?
+
+PCI Express error signaling can occur on the PCI Express link itself
+or on behalf of transactions initiated on the link. PCI Express
+defines two error reporting paradigms: the baseline capability and
+the Advanced Error Reporting capability. The baseline capability is
+required of all PCI Express components providing a minimum defined
+set of error reporting requirements. Advanced Error Reporting
+capability is implemented with a PCI Express advanced error reporting
+extended capability structure providing more robust error reporting.
+
+The PCI Express AER Root driver provides the mechanism to support PCI
+Express Advanced Error Reporting capability. The PCI Express AER Root
+driver provides three basic functions:
+
+-  A mechanism to allow a driver of a PCI Express component to
+   register/un-register its AER aware callback handle with the
+   PCI Express AER Root driver. This mechanism is provided as
+   an option to allow the PCI Express AER Root driver to query
+   the PCI Express component device driver to determine more
+   precisely which error and what severity occurred.
+   
+-  A mechanism to process the error reporting message detected
+   by Root Ports, and report the errors to user.
+
+4. Why Use the PCI Express AER Root Driver?
+
+In a PCI Express-aware system, a PCI Express component in a hierarchy
+associated with the Root Port can send an error reporting message
+to the Root Port. The Root Port, upon receiving an error reporting
+message, internally processes and logs the error message in its PCI
+Express capability structure. Error information being logged includes
+storing the error reporting agent's requestor ID into the Error
+Source Identification Registers and setting the error bits of the
+Root Error Status Register accordingly. If AER error reporting is
+enabled in Root Error Command Register, the Root Port generates an
+interrupt if an error is detected.
+
+In existing Linux kernels, 2.4.x and 2.6.x, there is no root service
+driver available to manage the PCI Express advanced error reporting
+extended capability structure. If an error is detected by the Root
+Port, the baseline capability, as described above, therefore must
+be provided by platform hardware to provide the platform-specific
+system with minimum defined error reporting requirements. Such a 
+platform-specific system may have BIOS not only configure the Root
+Control Register of the Root Ports' PCI Express capability structure
+to generate the system error accordingly but also handle error 
+reporting messages. Using platform-specific BIOS to handle system
+error reporting has three key issues:
+
+-  Inability to coordinate with the downstream device drivers
+   to determine more precisely which error and what severity.
+
+-  Inability to reset the downstream links while handling fatal
+   error recovery.
+
+-  Platform-specific dependency.
+
+To provide a solution to these issues requires the PCI Express AER
+Root driver that provides:
+
+-  A mechanism for the OS and application to determine if a fatal
+   error is fatal to the system, OS, or application increasing
+   uptime.
+
+-  A mechanism to notify the downstream device drivers if errors
+   occurred.
+
+-  A mechanism to dynamically perform error recovery actions
+   based on configuration options.
+
+-  Platform-specific independence.
+
+5. Including the PCI Express AER Root Driver into the Linux Kernel
+
+The PCI Express AER Root driver is a Root Port service driver attached
+to the PCI Express Port Bus driver. Its service must be registered
+with the PCI Express Port Bus driver and users are required to include
+the PCI Express Port Bus driver in the kernel (refer to
+PCIEBUS-HOWTO.txt). Once the kernel config CONFIG_PCIEPORTBUS is
+included, the PCI Express AER Root driver is

Re: 2.6.11-mm2 fremap.c compile error

On Tue, Mar 08, 2005 at 07:54:11PM +0100, Jurriaan wrote:

> mm/fremap.c:33:48: macro "flush_cache_page" passed 3 arguments, but takes 
> just 2
> mm/fremap.c: In function `zap_pte':
> mm/fremap.c:33: error: `flush_cache_page' undeclared (first use in this 
> function)
> mm/fremap.c:33: error: (Each undeclared identifier is reported only once
> mm/fremap.c:33: error: for each function it appears in.)
> mm/fremap.c:34:55: macro "ptep_get_and_clear" passed 3 arguments, but takes 
> just 1
> mm/fremap.c:34: error: `ptep_get_and_clear' undeclared (first use in this 
> function)
> mm/fremap.c:48:41: macro "pte_clear" passed 3 arguments, but takes just 1
> mm/fremap.c:48: error: `pte_clear' undeclared (first use in this function)
> mm/fremap.c: In function `install_page':
> mm/fremap.c:97: warning: implicit declaration of function `set_pte_at'
> make[1]: *** [mm/fremap.o] Error 1
> make: *** [mm] Error 2
>  
> The same config worked fine for 2.6.11-mm1:
>...

I wasn't able to reproduce this with your .config .

Are you using a completely otherwise unpatched 2.6.11-mm2?
Please retry with a freshly unpacked 2.6.11 plus the -mm2 patch.

> Good luck,
> Jurriaan

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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/

Re: A new 10GB Ethernet Driver by Chelsio Communications

2005-03-11 Thread Stephen Hemminger

On Fri, 11 Mar 2005 11:21:32 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:

> Christoph Lameter <[EMAIL PROTECTED]> wrote:
> >
> > A Linux driver for the Chelsio 10Gb Ethernet Network Controller by
> >  Chelsio (http://www.chelsio.com). This driver supports the Chelsio N210
> >  NIC and is backward compatible with the Chelsio N110 model 10Gb NICs.
> 
> Thanks, Christoph.
> 
> The 400k patch was too large for the vger email server so I have uploaded it 
> to
> 
>  
> http://www.zip.com.au/~akpm/linux/patches/stuff/a-new-10gb-ethernet-driver-by-chelsio-communications.patch
> 
> for reviewers.

The performance recommendations in cxgb.txt are common to all fast devices,
and should be in one file rather than just for this device. I would rather
see ip-sysctl.txt updated or a new file on tuning recommendations started.
Some of them have consequences that aren't documented well.  
For example, turning off TCP timestamps risks data corruption from sequence 
wrap.

A new driver shouldn't need so may #ifdef's unless you want to putit on older
vendor versions of 2.4

Some accessor and wrapper functions like:
t1_pci_read_config_4
adapter_name
t1_malloc
are just annoying noise.

Why have useless dead code like:




/* Interrupt handler */
+static int pm3393_interrupt_handler(struct cmac *cmac)
+{
+   u32 master_intr_status;
+/*
+1. Read master interrupt register.
+2. Read BLOCK's interrupt status registers.
+3. Handle BLOCK interrupts.
+*/
+   /* Read the master interrupt status register. */
+   pmread(cmac, SUNI1x10GEXP_REG_MASTER_INTERRUPT_STATUS,
+  _intr_status);
+   CH_DBG(cmac->adapter, INTR, "PM3393 intr cause 0x%x\n",
+  master_intr_status);
+
+   /* Handle BLOCK's interrupts. */
+
+   if (SUNI1x10GEXP_BITMSK_TOP_PL4IO_INT & master_intr_status) {
+   }
+
+   if (SUNI1x10GEXP_BITMSK_TOP_IRAM_INT & master_intr_status) {
+   }
+
+   if (SUNI1x10GEXP_BITMSK_TOP_ERAM_INT & master_intr_status) {
+   }
+
+   /* SERDES */
+   if (SUNI1x10GEXP_BITMSK_TOP_XAUI_INT & master_intr_status) {
+   }
+
+   /* MSTAT */
+   if (SUNI1x10GEXP_BITMSK_TOP_MSTAT_INT & master_intr_status) {
+   }
+
+   /* RXXG */
+   if (SUNI1x10GEXP_BITMSK_TOP_RXXG_INT & master_intr_status) {
+   }
+
+   /* TXXG */
+   if (SUNI1x10GEXP_BITMSK_TOP_TXXG_INT & master_intr_status) {
+   }
+
+   /* XRF */
+   if (SUNI1x10GEXP_BITMSK_TOP_XRF_INT & master_intr_status) {
+   }
+
+   /* XTEF */
+   if (SUNI1x10GEXP_BITMSK_TOP_XTEF_INT & master_intr_status) {
+   }
+
+   /* MDIO */
+   if (SUNI1x10GEXP_BITMSK_TOP_MDIO_BUSY_INT & master_intr_status) {
+   /* Not used. 8000 uses MDIO through Elmer. */
+   }
+
+   /* RXOAM */
+   if (SUNI1x10GEXP_BITMSK_TOP_RXOAM_INT & master_intr_status) {
+   }
+
+   /* TXOAM */
+   if (SUNI1x10GEXP_BITMSK_TOP_TXOAM_INT & master_intr_status) {
+   }
+
+   /* IFLX */
+   if (SUNI1x10GEXP_BITMSK_TOP_IFLX_INT & master_intr_status) {
+   }
+
+   /* EFLX */
+   if (SUNI1x10GEXP_BITMSK_TOP_EFLX_INT & master_intr_status) {
+   }
+
+   /* PL4ODP */
+   if (SUNI1x10GEXP_BITMSK_TOP_PL4ODP_INT & master_intr_status) {
+   }
+
+   /* PL4IDU */
+   if (SUNI1x10GEXP_BITMSK_TOP_PL4IDU_INT & master_intr_status) {
+   }
-
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/

[PATCH 2/6] PCI Express Advanced Error Reporting Driver

This patch includes the source code of sysfs component of PCI
Express Advanced Error Reporting driver.

Signed-off-by: T. Long Nguyen <[EMAIL PROTECTED]>


diff -urpN linux-2.6.11-rc5/drivers/pci/pcie/aer/aerdrv_sysfs.c 
patch-2.6.11-rc5-aerc3-split2/drivers/pci/pcie/aer/aerdrv_sysfs.c
--- linux-2.6.11-rc5/drivers/pci/pcie/aer/aerdrv_sysfs.c1969-12-31 
19:00:00.0 -0500
+++ patch-2.6.11-rc5-aerc3-split2/drivers/pci/pcie/aer/aerdrv_sysfs.c   
2005-03-09 13:25:36.0 -0500
@@ -0,0 +1,87 @@
+/*
+ * Copyright (C) 2005 Intel
+ * Copyright (C) Tom Long Nguyen ([EMAIL PROTECTED])
+ *
+ */
+
+#include "aerdrv_sysfs.h"
+   
+static ssize_t aer_sysfs_consume_show(struct device_driver *dev, char *buf)
+{
+   return aer_fsprint_record(buf);
+}
+   
+static ssize_t aer_sysfs_status_show(struct device_driver *dev, char *buf)
+{
+   return aer_fsprint_devices(buf);
+}
+   
+static ssize_t aer_sysfs_verbose_show(struct device_driver *dev, char *buf)
+{
+   return sprintf(buf, "Verbose display set to %d\n", 
+   aer_get_verbose()); 
+}
+   
+static ssize_t aer_sysfs_verbose_store(struct device_driver *drv,  
+   const char *buf, size_t count)  
+{
+   aer_set_verbose(buf[0] - 0x30); 
+   return count;   
+}
+
+static ssize_t aer_sysfs_auto_show(struct device_driver *dev, char *buf)
+{
+   return sprintf(buf, "Automatic reporting is %s\n",  
+   (aer_get_auto_mode()) ? "on" : "off");  
+}
+   
+static ssize_t aer_sysfs_auto_store(struct device_driver *drv, 
+   const char *buf, size_t count)  
+{
+   aer_set_auto_mode(buf[0] - 0x30);   
+   return count;   
+}
+
+/*
+ * Define AER Sysfs user interfaces
+ */
+static DRIVER_ATTR(consume, S_IRUGO, aer_sysfs_consume_show, NULL);
+static DRIVER_ATTR(status, S_IRUGO, aer_sysfs_status_show, NULL);
+static DRIVER_ATTR(verbose, S_IWUSR | S_IRUGO, aer_sysfs_verbose_show,
+  aer_sysfs_verbose_store);
+static DRIVER_ATTR(auto, S_IWUSR | S_IRUGO, aer_sysfs_auto_show,
+  aer_sysfs_auto_store);
+
+static struct attribute *aer_sysfs_driver_attrs[] = {
+   _attr_status.attr,
+   _attr_verbose.attr,
+   _attr_consume.attr,
+   _attr_auto.attr,
+   NULL
+};
+
+static struct attribute_group aer_sysfs_driver_attr_group = {
+   .attrs = aer_sysfs_driver_attrs,
+};
+
+/**
+ * aer_sysfs_init - AER user interface initialization
+ * @drv: pointer to device_driver data structure of AER service driver
+ *
+ * Invoked when AER service driver is loaded. 
+ **/
+int aer_sysfs_init(struct device_driver *drv)
+{
+   return sysfs_create_group(>kobj, _sysfs_driver_attr_group);
+}
+
+/**
+ * aer_sysfs_cleanup - remove AER user interface
+ * @drv: pointer to device_driver data structure of AER service driver
+ *
+ * Invoked when AER service driver is unloaded. 
+ **/
+void aer_sysfs_cleanup(struct device_driver *drv)
+{
+   sysfs_remove_group(>kobj, _sysfs_driver_attr_group);
+}
diff -urpN linux-2.6.11-rc5/drivers/pci/pcie/aer/aerdrv_sysfs.h 
patch-2.6.11-rc5-aerc3-split2/drivers/pci/pcie/aer/aerdrv_sysfs.h
--- linux-2.6.11-rc5/drivers/pci/pcie/aer/aerdrv_sysfs.h1969-12-31 
19:00:00.0 -0500
+++ patch-2.6.11-rc5-aerc3-split2/drivers/pci/pcie/aer/aerdrv_sysfs.h   
2005-03-09 13:25:36.0 -0500
@@ -0,0 +1,19 @@
+/*
+ * Copyright (C) 2005 Intel
+ * Copyright (C) Tom Long Nguyen ([EMAIL PROTECTED])
+ *
+ */
+
+#ifndef_AERDRV_SYSFS_H_
+#define_AERDRV_SYSFS_H_
+
+#include 
+
+extern int aer_fsprint_devices(char *page);
+extern int aer_fsprint_record(char *page);
+extern void aer_set_verbose(int value);
+extern int aer_get_verbose(void);
+extern void aer_set_auto_mode(int value);
+extern int aer_get_auto_mode(void);
+
+#endif //_AERDRV_SYSFS_H_
-
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/

Re: AGP bogosities


On 03.11, Dave Jones wrote:
> On Fri, Mar 11, 2005 at 10:11:08PM +, J.A. Magallon wrote:
>  > 
>  > On 03.11, Paul Mackerras wrote:
>  > > Linus,
>  > > 
>  > ...
>  > > 
>  > > Oh, and by the way, I have 3D working relatively well on my G5 with a
>  > > 64-bit kernel (and 32-bit X server and 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 :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 
> :00:00.0 into 4x mode
>  > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 
> :01:00.0 into 4x mode
>  > Mar 11 23:00:29 werewolf kernel: agpgart: Found an AGP 3.0 compliant 
> device at :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 
> :00:00.0 into 4x mode
>  > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 
> :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 :00:00.0.
agpgart: Putting AGP V3 device at :00:00.0 into 8x mode
agpgart: Putting AGP V3 device at :01:00.0 into 8x mode
agpgart: Found an AGP 3.0 compliant device at :00:00.0.
agpgart: Putting AGP V3 device at :00:00.0 into 8x mode
agpgart: Putting AGP V3 device at :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  \   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


-
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/

Re: AGP bogosities

2005-03-11 Thread Dmitry Torokhov

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
-
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/

Re: AGP bogosities

2005-03-11 Thread Dmitry Torokhov

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
-
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/

Re: AGP bogosities

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.
-
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/

Re: [PATCH] clean up FIXME in do_timer_interrupt

Lee Revell <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2005-03-10 at 00:42 -0800, George Anzinger wrote:
> > This patch changes the update of the cmos clock to be timer driven
> > rather than poll driven by the timer interrupt function.  If the clock
> > is not being synced to an outside source the timer is removed and thus
> > system overhead is nill in that case.  The update frequency is still ~11
> > minutes and missing the update window still causes a retry in 60
> > seconds.
> 
> No replies yet.  Are there any objections to this patch?

Nope.  I think it's neat.  I queued it 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/

Re: [ patch 3/5] drivers/serial/jsm: new serial device driver

2005-03-11 Thread Wen Xiong

Arjan van de Ven wrote:
Jeff pointed out several PCI posting errors last time.  Before we used 
udelay and now we changed to readb/readl instead of udelay this time.
But we only used PCI posting when we think maybe delay there.
So we have to do PCI posting on every writeb? 
   

not every
 

Do you have some rules for 
doing PCI posting while writeb? depends on what kind of registers?
   

basically you need to do posting flushes after every write for which you
assume later on the hardware received the write. If you do 5 writes in a
row you don't need 5 flushes. If you do a read later always anyway you
don't need any flushes.  
On the other side of the spectrum: if you do something to the hardware
and then wait for some event, you do need to flush that stuff.
So at minimum you want to make sure that at any point where you leave
the driver (to userspace or tty layer or ...) all writes have been
flushed. And at all points where you are going to wait for hardware
events.


 

Based on above all points, I audited the whole drvier for PCI posting 
issues.
Just added several PCI posting while the driver has interfaces with tty 
layer.

Thanks for your comments.
wendy

diff -Nuar linux-2.6.11.org/drivers/serial/jsm/jsm_neo.c 
linux-2.6.11.new/drivers/serial/jsm/jsm_neo.c
--- linux-2.6.11.org/drivers/serial/jsm/jsm_neo.c   1969-12-31 
18:00:00.0 -0600
+++ linux-2.6.11.new/drivers/serial/jsm/jsm_neo.c   2005-03-11 
16:26:47.442988256 -0600
@@ -0,0 +1,1402 @@
+/
+ * Copyright 2003 Digi International (www.digi.com)
+ *
+ * Copyright (C) 2004 IBM Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ * 
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY, EXPRESS OR IMPLIED; without even the 
+ * implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR 
+ * PURPOSE.  See the GNU General Public License for more details.
+ * 
+ * You should have received a copy of the GNU General Public License 
+ * along with this program; if not, write to the Free Software 
+ * Foundation, Inc., 59 * Temple Place - Suite 330, Boston,
+ * MA  02111-1307, USA.
+ *
+ * Contact Information:
+ * Scott H Kilau <[EMAIL PROTECTED]>
+ * Wendy Xiong   <[EMAIL PROTECTED]>
+ *
+ ***/
+#include/* For udelay */
+#include   /* For the various UART offsets */
+#include 
+#include 
+#include 
+
+#include "jsm.h"   /* Driver main header file */
+
+static u32 jsm_offset_table[8] = { 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 
0x80 };
+
+static void neo_set_cts_flow_control(struct jsm_channel *ch)
+{
+   u8 ier = readb(>ch_neo_uart->ier);
+   u8 efr = readb(>ch_neo_uart->efr);
+
+   jsm_printk(PARAM, INFO, >ch_bd->pci_dev, "Setting CTSFLOW\n");
+
+   /* Turn on auto CTS flow control */
+   ier |= (UART_17158_IER_CTSDSR);
+   efr |= (UART_17158_EFR_ECB | UART_17158_EFR_CTSDSR);
+
+   /* Turn off auto Xon flow control */
+   efr &= ~(UART_17158_EFR_IXON);
+
+   /* Why? Becuz Exar's spec says we have to zero it out before setting it 
*/
+   writeb(0, >ch_neo_uart->efr);
+
+   /* Turn on UART enhanced bits */
+   writeb(efr, >ch_neo_uart->efr);
+
+   /* Turn on table D, with 8 char hi/low watermarks */
+   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY), 
>ch_neo_uart->fctr);
+
+   /* Feed the UART our trigger levels */
+   writeb(8, >ch_neo_uart->tfifo);
+   ch->ch_t_tlevel = 8;
+
+   writeb(ier, >ch_neo_uart->ier);
+}
+
+static void neo_set_rts_flow_control(struct jsm_channel *ch)
+{
+   u8 ier = readb(>ch_neo_uart->ier);
+   u8 efr = readb(>ch_neo_uart->efr);
+
+   jsm_printk(PARAM, INFO, >ch_bd->pci_dev, "Setting RTSFLOW\n");
+
+   /* Turn on auto RTS flow control */
+   ier |= (UART_17158_IER_RTSDTR);
+   efr |= (UART_17158_EFR_ECB | UART_17158_EFR_RTSDTR);
+
+   /* Turn off auto Xoff flow control */
+   ier &= ~(UART_17158_IER_XOFF);
+   efr &= ~(UART_17158_EFR_IXOFF);
+
+   /* Why? Becuz Exar's spec says we have to zero it out before setting it 
*/
+   writeb(0, >ch_neo_uart->efr);
+
+   /* Turn on UART enhanced bits */
+   writeb(efr, >ch_neo_uart->efr);
+
+   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY), 
>ch_neo_uart->fctr);
+   ch->ch_r_watermark = 4;
+
+   writeb(56, >ch_neo_uart->rfifo);
+   ch->ch_r_tlevel = 56;
+
+   writeb(ier, >ch_neo_uart->ier);
+
+   /*
+* From the Neo UART spec sheet:
+* The auto RTS/DTR function must be started by asserting
+* RTS/DTR# output pin (MCR bit-0 or 1 to logic 1 after
+

Re: AGP bogosities

2005-03-11 Thread Linus Torvalds



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
-
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/

Re: Linux 2.6.11.2

2005-03-11 Thread Greg KH

On Fri, Mar 11, 2005 at 11:19:28AM -0800, Chris Wright wrote:
> * Matt Mackall ([EMAIL PROTECTED]) wrote:
> > Or do you want to do it the same way you do for every other branch? I
> > don't want to special-case it in my code and I don't think users want
> > to special-case it in their brains. Have separate interdiffs on the
> > side, please, and then people can choose, but do it the standard way.
> > 
> > Dear ${SUCKER}s, can we have a decision on this? My ketchup tool is
> > broken for 2.6.11.2 and I don't want to cut a new release until a firm
> > decision is made. Obviously I have a strong preference for all 2.6.x.y
> > diffs being against 2.6.x, it means that .y can be treated the same as
> > -rc, -bk, -mm, ... (and I already coded it that way when 2.6.8.1 came
> > out).
> 
> I agree with having the patch be against .x, with x.y -> x.y+1 interdiffs
> available on the side.  Greg, any issue with that?

No, I agree with that, and will not be hard to do at all (the release
script already handles this just fine.)  

I've held off rediffing 2.6.11.2 so far, as I don't know where to put
the x.y+1 interdiffs?  kernel/v2.6/incr/ ?  Any thoughts?

thanks,

greg k-h
-
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/

Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB

2005-03-11 Thread Bjorn Helgaas

Can you do an "lspci -vvn"?  I'm looking at quirk_via_irqpic() in
2.6.9, which is what printed this:

> >PCI: Via IRQ fixup for :00:07.2, from 9 to 10
> >PCI: Via IRQ fixup for :00:07.3, from 9 to 10

but it looks like it should only run for PCI_DEVICE_ID_VIA_82C586_2,
PCI_DEVICE_ID_VIA_82C686_5, and PCI_DEVICE_ID_VIA_82C686_6.

You have:

:00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] 
(rev 40)
:00:07.1 IDE interface: VIA Technologies, Inc. 
VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06)
:00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 1a) (prog-if 00 
[UHCI])
:00:07.3 USB Controller: VIA Technologies, Inc. USB (rev 1a) (prog-if 00 
[UHCI])

and we apparently ran the quirk for 07.2 and 07.3.  I wouldn't
have thought those would have one of the above device IDs.  The
"lspci -vvn" should tell us for sure.

2.6.11 removed that quirk and runs quirk_via_bridge() for
all VIA devices, but only sets via_interrupt_line_quirk if
(pdev->devfn == 0), which you don't have.  So that's why
my patch didn't do anything.

> Also two more questions:
> 
> 1. What is VIA fixup? Is it some hardware bug? Or BIOS problem? Why is it 
> needed? On what hardware / software it is needed?

I really don't know much about the VIA fixup.  I just noticed
that we seem to be doing it slightly differently in 2.6.11 than
we did in 2.6.9, and thought maybe it was related to your problem.
Here's a changeset that has a couple pointers:

http://linux.bkbits.net:8080/linux-2.5/cset%4041cb9d48DRV4TYe77gvstTawuZFYyQ

> 2. Why this patch shrinked bzImage that much:
> 
> -rw-r--r--  1 root root 1828186 mar 11 23:33 vmlinuz-2.6.11-cko1
> -rw-r--r--  1 root root 1828355 mar  2 20:48 vmlinuz-2.6.11-cko1.old

I have no idea about this.  But it's only a couple hundred bytes.

So here's another patch to try (revert the first one, then apply this).

= drivers/acpi/pci_irq.c 1.37 vs edited =
--- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
+++ edited/drivers/acpi/pci_irq.c   2005-03-11 15:13:49 -07:00
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -438,10 +439,17 @@
}
}
 
-   if (via_interrupt_line_quirk)
-   pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq & 15);
-
dev->irq = acpi_register_gsi(irq, edge_level, active_high_low);
+
+   if (dev->vendor == PCI_VENDOR_ID_VIA) {
+   u8 old_irq, new_irq = dev->irq & 0xf;
+
+   pci_read_config_byte(dev, PCI_INTERRUPT_LINE, _irq);
+   printk(KERN_INFO PREFIX "Via IRQ fixup for %s, from %d "
+   "to %d\n", pci_name(dev), old_irq, new_irq);
+   udelay(15);
+   pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
+   }
 
printk(KERN_INFO PREFIX "PCI interrupt %s[%c] -> GSI %u "
"(%s, %s) -> IRQ %d\n",


-
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/

Re: AGP bogosities

2005-03-11 Thread Chris Wedgwood

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.
-
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/

Re: A new 10GB Ethernet Driver by Chelsio Communications

On Fri, Mar 11, 2005 at 11:21:32AM -0800, Andrew Morton wrote:
> Christoph Lameter <[EMAIL PROTECTED]> wrote:
> >
> > A Linux driver for the Chelsio 10Gb Ethernet Network Controller by
> >  Chelsio (http://www.chelsio.com). This driver supports the Chelsio N210
> >  NIC and is backward compatible with the Chelsio N110 model 10Gb NICs.
> 
> Thanks, Christoph.
> 
> The 400k patch was too large for the vger email server so I have uploaded it 
> to
> 
>  
> http://www.zip.com.au/~akpm/linux/patches/stuff/a-new-10gb-ethernet-driver-by-chelsio-communications.patch
> 
> for reviewers.
>...

#if defined(MODULE) && ! defined(MODVERSIONS)
#define MODVERSIONS
#endif


Why?


cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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/

Re: [PATCH] clean up FIXME in do_timer_interrupt

2005-03-11 Thread Lee Revell

On Thu, 2005-03-10 at 00:42 -0800, George Anzinger wrote:
> This patch changes the update of the cmos clock to be timer driven
> rather than poll driven by the timer interrupt function.  If the clock
> is not being synced to an outside source the timer is removed and thus
> system overhead is nill in that case.  The update frequency is still ~11
> minutes and missing the update window still causes a retry in 60
> seconds.

No replies yet.  Are there any objections to this patch?

If not, it should be applied as it reduces the worst case latency of the
-RT kernel from about 90 to 40 usecs on my hardware.

The effect on mainline should be negligible.

Lee

-
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/

Re: AGP bogosities

2005-03-11 Thread Dave Jones

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

-
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/

Re: [PATCH 4/9] UML - Export gcov symbol based on gcc version

2005-03-11 Thread Jeff Dike

[EMAIL PROTECTED] said:
> And therefore you added a patch that helps only those distros at the
> price of breaking other people and distros using sane compilers? 

Didn't you start this thread by pointing out that SuSE has a gcc 3.3.4
which isn't?  I would call that a compiler which lies about its version, and
for the purposes of this argument, I would say that it is not a sane
compiler.

Given this, your original (correct) claim was that my patch would not help
such compilers.  Are you now claiming that it does help such compilers, and
no one else?

Jeff


-
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/

Re: AGP bogosities

2005-03-11 Thread OGAWA Hirofumi

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)
_
-
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/

Re: [PATCH 5/9] UML - change semaphores to completions

2005-03-11 Thread Jeff Dike

[EMAIL PROTECTED] said:
> >  + 
> >  +  init_completion(>done), 
> >  +
> 
> I'll convert that to a semicolon...

Gawd, thanks...

Jeff

-
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/

Re: AGP bogosities

2005-03-11 Thread Dave Jones

On Fri, Mar 11, 2005 at 10:11:08PM +, J.A. Magallon wrote:
 > 
 > On 03.11, Paul Mackerras wrote:
 > > Linus,
 > > 
 > ...
 > > 
 > > Oh, and by the way, I have 3D working relatively well on my G5 with a
 > > 64-bit kernel (and 32-bit X server and clients), which is why I care
 > > about AGP 3.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 :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 
 > :00:00.0 into 4x mode
 > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 
 > :01:00.0 into 4x mode
 > Mar 11 23:00:29 werewolf kernel: agpgart: Found an AGP 3.0 compliant device 
 > at :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 
 > :00:00.0 into 4x mode
 > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at 
 > :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

-
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/

[PATCH] ppc32: emulate load/store string instructions

2005-03-11 Thread Kumar Gala

Andrew,

Some Book-E implementations (e500) do not implement the userland 
load/store string instructions.  Apparently these instructions are rather 
painful to implement do to the fact that they modify the destination 
register differently then ever other instruction.  Matt did the inital 
work some time ago, and I finally got around to cleaning it up.

Signed-off-by: Matt McClintock
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>

---

diff -Nru a/arch/ppc/kernel/traps.c b/arch/ppc/kernel/traps.c
--- a/arch/ppc/kernel/traps.c   2005-03-11 15:07:28 -06:00
+++ b/arch/ppc/kernel/traps.c   2005-03-11 15:07:28 -06:00
@@ -389,6 +389,87 @@
 #define INST_MCRXR 0x7c000400
 #define INST_MCRXR_MASK0x7c0007fe
 
+#define INST_STRING0x7c00042a
+#define INST_STRING_MASK   0x7c0007fe
+#define INST_STRING_GEN_MASK   0x7c00067e
+#define INST_LSWI  0x7c0004aa
+#define INST_LSWX  0x7c00042a
+#define INST_STSWI 0x7c0005aa
+#define INST_STSWX 0x7c00052a
+
+static int emulate_string_inst(struct pt_regs *regs, u32 instword)
+{
+   u8 rT = (instword >> 21) & 0x1f;
+   u8 rA = (instword >> 16) & 0x1f;
+   u8 NB_RB = (instword >> 11) & 0x1f;
+   u32 num_bytes;
+   u32 EA;
+   int pos = 0;
+
+   /* Early out if we are an invalid form of lswx */
+   if ((instword & INST_STRING_MASK) == INST_LSWX)
+   if ((rA >= rT) || (NB_RB >= rT) || (rT == rA) || (rT == NB_RB))
+   return -EINVAL;
+
+   /* Early out if we are an invalid form of lswi */
+   if ((instword & INST_STRING_MASK) == INST_LSWX)
+   if ((rA >= rT) || (rT == rA))
+   return -EINVAL;
+
+   EA = (rA == 0) ? 0 : regs->gpr[rA];
+
+   switch (instword & INST_STRING_MASK) {
+   case INST_LSWX:
+   case INST_STSWX:
+   EA += NB_RB;
+   num_bytes = regs->xer & 0x7f;
+   break;
+   case INST_LSWI:
+   case INST_STSWI:
+   num_bytes = (NB_RB == 0) ? 32 : NB_RB;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   while (num_bytes != 0)
+   {
+   u8 val;
+   u32 shift = 8 * (3 - (pos & 0x3));
+
+   switch ((instword & INST_STRING_MASK)) {
+   case INST_LSWX:
+   case INST_LSWI:
+   if (get_user(val, (u8 __user *)EA))
+   return -EFAULT;
+   /* first time updating this reg,
+* zero it out */
+   if (pos == 0)
+   regs->gpr[rT] = 0;
+   regs->gpr[rT] |= val << shift;
+   break;
+   case INST_STSWI:
+   case INST_STSWX:
+   val = regs->gpr[rT] >> shift;
+   if (put_user(val, (u8 __user *)EA))
+   return -EFAULT;
+   break;
+   }
+   /* move EA to next address */
+   EA += 1;
+   num_bytes--;
+
+   /* manage our position within the register */
+   if (++pos == 4) {
+   pos = 0;
+   if (++rT == 32)
+   rT = 0;
+   }
+   }
+
+   return 0;
+}
+
 static int emulate_instruction(struct pt_regs *regs)
 {
u32 instword;
@@ -422,6 +503,10 @@
regs->xer &= ~0xf000UL;
return 0;
}
+
+   /* Emulate load/store string insn. */
+   if ((instword & INST_STRING_GEN_MASK) == INST_STRING)
+   return emulate_string_inst(regs, instword);
 
return -EINVAL;
 }
-
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/

Re: [PATCH] PPC64 NUMA memory fixup

2005-03-11 Thread mike kravetz

Here is another version of the patch.  This one gets the cell sizes
before extracting the cells.  I have made this change to existing
code in the file, as well as the code I added.  This works fine on
my 720, but so did the previous patch. :)  I'd appreciate it if
someone could touch test this on a machine known to break with
the previous version (such as G5).

-- 
Signed-off-by: Mike Kravetz <[EMAIL PROTECTED]>


diff -Naupr linux-2.6.11/arch/ppc64/mm/numa.c 
linux-2.6.11.work/arch/ppc64/mm/numa.c
--- linux-2.6.11/arch/ppc64/mm/numa.c   2005-03-02 07:38:38.0 +
+++ linux-2.6.11.work/arch/ppc64/mm/numa.c  2005-03-11 21:08:29.0 
+
@@ -40,7 +40,6 @@ int nr_cpus_in_node[MAX_NUMNODES] = { [0
 
 struct pglist_data *node_data[MAX_NUMNODES];
 bootmem_data_t __initdata plat_node_bdata[MAX_NUMNODES];
-static unsigned long node0_io_hole_size;
 static int min_common_depth;
 
 /*
@@ -49,7 +48,8 @@ static int min_common_depth;
  */
 static struct {
unsigned long node_start_pfn;
-   unsigned long node_spanned_pages;
+   unsigned long node_end_pfn;
+   unsigned long node_present_pages;
 } init_node_data[MAX_NUMNODES] __initdata;
 
 EXPORT_SYMBOL(node_data);
@@ -186,14 +186,31 @@ static int __init find_min_common_depth(
return depth;
 }
 
-static unsigned long read_cell_ul(struct device_node *device, unsigned int 
**buf)
+static int __init get_mem_addr_cells(void)
+{
+   struct device_node *memory = NULL;
+
+   memory = of_find_node_by_type(memory, "memory");
+   if (!memory)
+   return 0; /* it won't matter */
+   return(prom_n_addr_cells(memory));
+}
+
+static int __init get_mem_size_cells(void)
+{
+   struct device_node *memory = NULL;
+
+   memory = of_find_node_by_type(memory, "memory");
+   if (!memory)
+   return 0; /* it won't matter */
+   return(prom_n_size_cells(memory));
+}
+
+static unsigned long read_n_cells(int n, unsigned int **buf)
 {
-   int i;
unsigned long result = 0;
 
-   i = prom_n_size_cells(device);
-   /* bug on i>2 ?? */
-   while (i--) {
+   while (n--) {
result = (result << 32) | **buf;
(*buf)++;
}
@@ -267,6 +284,7 @@ static int __init parse_numa_properties(
 {
struct device_node *cpu = NULL;
struct device_node *memory = NULL;
+   int addr_cells, size_cells;
int max_domain = 0;
long entries = lmb_end_of_DRAM() >> MEMORY_INCREMENT_SHIFT;
unsigned long i;
@@ -313,6 +331,8 @@ static int __init parse_numa_properties(
}
}
 
+   addr_cells = get_mem_addr_cells();
+   size_cells = get_mem_size_cells();
memory = NULL;
while ((memory = of_find_node_by_type(memory, "memory")) != NULL) {
unsigned long start;
@@ -329,8 +349,8 @@ static int __init parse_numa_properties(
ranges = memory->n_addrs;
 new_range:
/* these are order-sensitive, and modify the buffer pointer */
-   start = read_cell_ul(memory, _buf);
-   size = read_cell_ul(memory, _buf);
+   start = read_n_cells(addr_cells, _buf);
+   size = read_n_cells(size_cells, _buf);
 
start = _ALIGN_DOWN(start, MEMORY_INCREMENT);
size = _ALIGN_UP(size, MEMORY_INCREMENT);
@@ -348,33 +368,28 @@ new_range:
if (max_domain < numa_domain)
max_domain = numa_domain;
 
-   /* 
-* For backwards compatibility, OF splits the first node
-* into two regions (the first being 0-4GB). Check for
-* this simple case and complain if there is a gap in
-* memory
+   /*
+* Initialize new node struct, or add to an existing one.
 */
-   if (init_node_data[numa_domain].node_spanned_pages) {
-   unsigned long shouldstart =
-   init_node_data[numa_domain].node_start_pfn +
-   init_node_data[numa_domain].node_spanned_pages;
-   if (shouldstart != (start / PAGE_SIZE)) {
-   /* Revert to non-numa for now */
-   printk(KERN_ERR
-  "WARNING: Unexpected node layout: "
-  "region start %lx length %lx\n",
-  start, size);
-   printk(KERN_ERR "NUMA is disabled\n");
-   goto err;
-   }
-   init_node_data[numa_domain].node_spanned_pages +=
+   if (init_node_data[numa_domain].node_end_pfn) {
+   if ((start / PAGE_SIZE) <
+   init_node_data[numa_domain].node_start_pfn)
+

Re: AGP bogosities