Re: BMAC stuff - what I have

Re: BMAC stuff - what I have

[Joseph P. Garcia]

[-- Attachment #1: Type: text/plain, Size: 2233 bytes --]

Kernel version: any (2.2.x - 2.4.x)

Symptoms: high speed transfers from a macintosh with a BMAC network device are limited to less than 100kB/s and often corrupted.  Systems known to have this are some Wallstreets and beige Desktops.  10/100 chips in Lombard are BMAC+ which do not seem to have the bug.  This is a hardware bug that exists in some releases of the chip, and only effects Tx packets.

Reproduction instructions: Open an FTP client to any system you have a potential 10Mbit transfer speed.  Transfering from the other computer will yeild high speeds, however transfering to the other system will reveal this problem.  This works with most all protocols i've seen.  This is also seen when on occation, SSH connections using scp or X-forwarding will close with a comment on connection quality/reliability.  something like that.

Explanation of problem: When there is a collision on the network, the BMAC chip will corrupt its Tx DMA buffer.  Proposed solution is to have only one Tx packet in DMA at a time, which the current driver seems to almost do.  Potential for more than one in transit seems to exist.  I beleive that there might be something else relevant to what causes the collisions.

Fixes: No known implementations in Linux.  MacOS and Darwin appear to have workarounds.

> (ie: http://www.geocrawler.com/archives/3/3/2000/10/0/4577176/
> http://www.geocrawler.com/archives/3/3/2000/2/0/3266218/ ).

good links

> Joseph Garcia said this bug had been listed and closed on sourceforge, but I
> can't find any record of that.

I don't recall saying that.  Might have been a miscommunication.  Some wallstreets aren't afflicted by the bug, so a 'works for me' may have been tagged on.  I had the opportunity to use one.  That's all I can say on that.

Attached are some files I recevied from Dan Malek on Jan 25.

I don't claim to be an expert on this.  I base my information on my (sometimes incorrect) interpretations of what I read and hear.  BenH has been much more helpful in explaining the problem.

Feel free to modify the above makings of a report before posting it.

I have tried my hand at hacking a solution together, but haven't gotten anywhere.

--
Joseph P. Garcia
http://www.execpc.com/~jpgarcia

[-- Attachment #2: bmac.note --]
[-- Type: application/octet-stream, Size: 1960 bytes --]


Ok, here's a quick and dirty hack which I believe allows only one xmit
DMA packet per BMac xmit FrameSent interrupt.

I *_really_* don't understand the exact meanings of the dbdma command
bit fields here. Lacking documentation on this thing other than what's
here in the linux source tree (which aint much in the way of comments),
I'm merely guessing at the meanings.

But, if my understanding is correct, the BMac driver has never truly
been running in chained/streaming DMA mode. It's been DMAing one packet
per TxDma interrupt and then advancing the queue and restarting the
DMA engine!? Each entry in the queue gets both the OUTPUT_LAST and
INTR_ALWAYS fields set. I assume this means: "when you're done
with this DMA, stop and send an interrupt for service"?

Anyway, this may still allow for the noted Xmit multi-packet FIFO
collision/corruption problem you noted before. Although the window
of opportunnity is smaller - the DMA engine needs to be restarted
via the bmac_txdma_intr handler service before the Xmit FIFO emties
the data from the previous DMA?

Anyway, I've merely changed this to "INTR_NEVER" and replaced servicing
of the DMA xmit queue with a direct call to bmac_txdma_intr from the
bmac_misc_intr handler when FrameSent or TxUnderrun are true.

Incidentally, it appears that the FrameSent interrupt has been enabled
all along although nothing was being done for FrameSent interrupts in
bmac_misc_intr?

Oh, I just noticed that I've left TxUnderrun interrupts masked! I was
considering that this condition should result in restart of the Xmit
DMA engine. But I'm not sure if there are other recovery fixups needed
in this case. Oh well, it was disabled before and it's still disabled!

This may be the cause of future hangs? If we get an TxUnderrun, we
may not service it to restart the DMA engine. Any Rcv packet interrupt
conditions would unwedge it I guess. But it would still be hung 'til
we receive a packet?

-- 
Regards,
George


[-- Attachment #3: bmac.patch --]
[-- Type: application/octet-stream, Size: 10444 bytes --]

--- linux-2.2.17pre13-ben1.orig/drivers/net/Config.in	Sun Jul 23 06:24:55 2000
+++ linux-2.2.17pre13-ben1/drivers/net/Config.in	Tue Nov  7 17:38:49 2000
@@ -50,6 +50,9 @@
       bool 'Use AAUI port instead of TP by default' CONFIG_MACE_AAUI_PORT
     fi
     tristate 'BMAC (G3 ethernet) support' CONFIG_BMAC
+    if [ "$CONFIG_BMAC" != "n" ]; then
+      bool 'Enable non-streaming Tranmit DMA support' CONFIG_BMAC_NO_STREAM_XMIT_DMA
+    fi
     tristate 'GMAC (G4/iBook ethernet) support' CONFIG_GMAC
     tristate 'Symbios 53c885 (Synergy ethernet) support' CONFIG_NCR885E
   fi
--- linux-2.2.17pre13-ben1.orig/drivers/net/bmac.c	Thu Jul 20 05:06:59 2000
+++ linux-2.2.17pre13-ben1/drivers/net/bmac.c	Tue Nov  7 18:01:43 2000
@@ -49,7 +49,12 @@
 /* Bits in transmit DMA status */
 #define TX_DMA_ERR	0x80
 
-#define XXDEBUG(args)
+#undef CONFIG_BMAC_DEBUG
+#ifndef CONFIG_BMAC_DEBUG
+#define XXDEBUG(args...)
+#else /* CONFIG_BMAC_DEBUG */
+#define XXDEBUG(args...) printk(KERN_INFO args)
+#endif /* CONFIG_BMAC_DEBUG */
 
 struct bmac_data {
 	/* volatile struct bmac *bmac; */
@@ -333,7 +338,7 @@
 	unsigned short *pWord16;
 	int i;
 
-	/* XXDEBUG(("bmac: enter init_registers\n")); */
+	XXDEBUG ("bmac: enter init_registers\n") ;
 
 	bmwrite(dev, RXRST, RxResetValue);
 	bmwrite(dev, TXRST, TxResetBit);
@@ -518,7 +523,7 @@
 	unsigned long flags;
 	int i;
 
-	XXDEBUG(("bmac: enter set_address\n"));
+	XXDEBUG ("bmac: enter set_address\n") ;
 	save_flags(flags); cli();
 
 	for (i = 0; i < 6; ++i) {
@@ -531,7 +536,7 @@
 	bmwrite(dev, MADD2, *pWord16);
 
 	restore_flags(flags);
-	XXDEBUG(("bmac: exit set_address\n"));
+	XXDEBUG ("bmac: exit set_address\n") ;
 	return 0;
 }
 
@@ -563,7 +568,12 @@
 	vaddr = skb->data;
 	baddr = virt_to_bus(vaddr);
 
+#ifndef CONFIG_BMAC_NO_STREAM_XMIT_DMA
 	dbdma_setcmd(cp, (OUTPUT_LAST | INTR_ALWAYS | WAIT_IFCLR), len, baddr, 0);
+#else /* CONFIG_BMAC_NO_STREAM_XMIT_DMA */
+	dbdma_setcmd(cp, (OUTPUT_LAST | INTR_NEVER | WAIT_IFCLR), len, baddr, 0);
+	/* dbdma_setcmd(cp, (OUTPUT_LAST | INTR_NEVER | WAIT_NEVER | BR_NEVER | KEY_SYSTEM), len, baddr, 0);*/
+#endif /* CONFIG_BMAC_NO_STREAM_XMIT_DMA */
 }
 
 static void
@@ -650,14 +660,14 @@
 	int i;
 
 	/* see if there's a free slot in the tx ring */
-	/* XXDEBUG(("bmac_xmit_start: empty=%d fill=%d\n", */
-	/* 	     bp->tx_empty, bp->tx_fill)); */
+	XXDEBUG ("bmac_xmit_packet: empty=%d fill=%d\n",
+	 	     bp->tx_empty, bp->tx_fill) ;
 	i = bp->tx_fill + 1;
 	if (i >= N_TX_RING) i = 0;
 	if (i == bp->tx_empty) {
 		dev->tbusy = 1;
 		bp->tx_fullup = 1;
-		XXDEBUG(("bmac_transmit_packet: tx ring full\n"));
+		XXDEBUG ("bmac_transmit_packet: tx ring full\n") ;
 		return -1;		/* can't take it at the moment */
 	}
 
@@ -692,7 +702,7 @@
 	save_flags(flags); cli();
 
 	if (++rxintcount < 10) {
-		XXDEBUG(("bmac_rxdma_intr\n"));
+		XXDEBUG ("bmac_rxdma_intr\n") ;
 	}
 
 	last = -1;
@@ -739,7 +749,7 @@
 	dbdma_continue(rd);
 
 	if (rxintcount < 10) {
-		XXDEBUG(("bmac_rxdma_intr done\n"));
+		XXDEBUG ("bmac_rxdma_intr done\n") ;
 	}
 }
 
@@ -756,7 +766,7 @@
 	save_flags(flags); cli();
 
 	if (txintcount++ < 10) {
-		XXDEBUG(("bmac_txdma_intr\n"));
+		XXDEBUG ("bmac_txdma_intr\n") ;
 	}
 
 	/*     del_timer(&bp->tx_timeout); */
@@ -766,7 +776,7 @@
 		cp = &bp->tx_cmds[bp->tx_empty];
 		stat = ld_le16(&cp->xfer_status);
 		if (txintcount < 10) {
-			XXDEBUG(("bmac_txdma_xfer_stat=%#0x\n", stat));
+			XXDEBUG ("bmac_txdma_xfer_stat=%#0x\n", stat) ;
 		}
 		if (!(stat & ACTIVE)) break;
 
@@ -777,8 +787,8 @@
 		bp->tx_bufs[bp->tx_empty] = NULL;
 		bp->tx_fullup = 0;
 		dev->tbusy = 0;
-		/* XXDEBUG(("bmac_intr: cleared tbusy, empty=%d fill=%d\n", */
-		/* 		 i, bp->tx_fill)); */
+		XXDEBUG ("bmac_txdma_intr: cleared tbusy, empty=%d fill=%d\n",
+		 		 bp->tx_empty, bp->tx_fill) ;
 		mark_bh(NET_BH);
 		if (++bp->tx_empty >= N_TX_RING) bp->tx_empty = 0;
 		if (bp->tx_empty == bp->tx_fill) break;
@@ -787,7 +797,7 @@
 	restore_flags(flags);
 
 	if (txintcount < 10) {
-		XXDEBUG(("bmac_txdma_intr done->bmac_start\n"));
+		XXDEBUG ("bmac_txdma_intr done->bmac_start\n") ;
 	}
 
 	bmac_start(dev);
@@ -846,7 +856,7 @@
 {	
 	unsigned int newcrc;
 
-	XXDEBUG(("bmac_crc: addr=%#04x, %#04x, %#04x\n", *address, address[1], address[2]));
+	XXDEBUG ("bmac_crc: addr=%#04x, %#04x, %#04x\n", *address, address[1], address[2]) ;
 	newcrc = crc416(0xffffffff, *address);	/* address bits 47 - 32 */
 	newcrc = crc416(newcrc, address[1]);	/* address bits 31 - 16 */
 	newcrc = crc416(newcrc, address[2]);	/* address bits 15 - 0  */
@@ -940,12 +950,12 @@
 bmac_add_multi(struct device *dev,
 	       struct bmac_data *bp, unsigned char *addr)
 {
-	/* XXDEBUG(("bmac: enter bmac_add_multi\n")); */
+	XXDEBUG ("bmac: enter bmac_add_multi\n") ;
 	bmac_addhash(bp, addr);
 	bmac_rx_off(dev);
 	bmac_update_hash_table_mask(dev, bp);
 	bmac_rx_on(dev, 1, (dev->flags & IFF_PROMISC)? 1 : 0);
-	/* XXDEBUG(("bmac: exit bmac_add_multi\n")); */
+	XXDEBUG ("bmac: exit bmac_add_multi\n") ;
 }
 
 static void
@@ -973,34 +983,34 @@
 	unsigned short rx_cfg;
 	int i;
 
-	XXDEBUG(("bmac: enter bmac_set_multicast, n_addrs=%d\n", num_addrs));
+	XXDEBUG ("bmac: enter bmac_set_multicast, n_addrs=%d\n", num_addrs) ;
 
 	if((dev->flags & IFF_ALLMULTI) || (dev->mc_count > 64)) {
 		for (i=0; i<4; i++) bp->hash_table_mask[i] = 0xffff;
 		bmac_update_hash_table_mask(dev, bp);
 		rx_cfg = bmac_rx_on(dev, 1, 0);
-		XXDEBUG(("bmac: all multi, rx_cfg=%#08x\n"));
+		XXDEBUG ("bmac: all multi, rx_cfg=%#08x\n") ;
 	} else if ((dev->flags & IFF_PROMISC) || (num_addrs < 0)) {
 		rx_cfg = bmread(dev, RXCFG);
 		rx_cfg |= RxPromiscEnable;
 		bmwrite(dev, RXCFG, rx_cfg);
 		rx_cfg = bmac_rx_on(dev, 0, 1);
-		XXDEBUG(("bmac: promisc mode enabled, rx_cfg=%#08x\n", rx_cfg));
+		XXDEBUG ("bmac: promisc mode enabled, rx_cfg=%#08x\n", rx_cfg) ;
 	} else {
 		for (i=0; i<4; i++) bp->hash_table_mask[i] = 0;
 		for (i=0; i<64; i++) bp->hash_use_count[i] = 0;
 		if (num_addrs == 0) {
 			rx_cfg = bmac_rx_on(dev, 0, 0);
-			XXDEBUG(("bmac: multi disabled, rx_cfg=%#08x\n", rx_cfg));
+			XXDEBUG ("bmac: multi disabled, rx_cfg=%#08x\n", rx_cfg) ;
 		} else {
 			for (dmi=dev->mc_list; dmi!=NULL; dmi=dmi->next)
 				bmac_addhash(bp, dmi->dmi_addr);
 			bmac_update_hash_table_mask(dev, bp);
 			rx_cfg = bmac_rx_on(dev, 1, 0);
-			XXDEBUG(("bmac: multi enabled, rx_cfg=%#08x\n", rx_cfg));
+			XXDEBUG ("bmac: multi enabled, rx_cfg=%#08x\n", rx_cfg) ;
 		}
 	}
-	/* XXDEBUG(("bmac: exit bmac_set_multicast\n")); */
+	XXDEBUG ("bmac: exit bmac_set_multicast\n") ;
 }
 #else /* ifdef SUNHME_MULTICAST */
 
@@ -1081,9 +1091,9 @@
 	struct bmac_data *bp = (struct bmac_data *)dev->priv;
 	unsigned int status = bmread(dev, STATUS);
 	if (miscintcount++ < 10) {
-		XXDEBUG(("bmac_misc_intr\n"));
+		XXDEBUG ("bmac_misc_intr\n") ;
 	}
-	/* XXDEBUG(("bmac_misc_intr, status=%#08x\n", status)); */
+	XXDEBUG ("bmac_misc_intr, status=%#08x\n", status) ;
 	/*     bmac_txdma_intr_inner(irq, dev_id, regs); */
 	/*   if (status & FrameReceived) bp->stats.rx_dropped++; */
 	if (status & RxErrorMask) bp->stats.rx_errors++;
@@ -1096,6 +1106,13 @@
 	if (status & TxErrorMask) bp->stats.tx_errors++;
 	if (status & TxUnderrun) bp->stats.tx_fifo_errors++;
 	if (status & TxNormalCollExp) bp->stats.collisions++;
+
+#ifdef CONFIG_BMAC_NO_STREAM_XMIT_DMA
+	if (status & (FrameSent | TxUnderrun)) {
+		XXDEBUG ("bmac_misc_intr: calling bmac_txdma_intr to restart Xmit DMA!\n");
+		bmac_txdma_intr(irq, dev_id, regs);
+	}
+#endif /* CONFIG_BMAC_NO_STREAM_XMIT_DMA */
 }
 
 /*
@@ -1324,7 +1341,7 @@
 		dev->dev_addr[j] = rev? bitrev(addr[j]): addr[j];
 		printk("%c%.2x", (j? ':': ' '), dev->dev_addr[j]);
 	}
-	XXDEBUG((", base_addr=%#0lx", dev->base_addr));
+	XXDEBUG (", base_addr=%#0lx", dev->base_addr) ;
 	printk("\n");
     
 	dev->open = bmac_open;
@@ -1392,7 +1409,7 @@
 
 static int bmac_open(struct device *dev)
 {
-	/* XXDEBUG(("bmac: enter open\n")); */
+	XXDEBUG ("bmac: enter open\n") ;
 	/* reset the chip */
 	bmac_reset_and_enable(dev, 1);
 
@@ -1426,7 +1443,7 @@
 	st_le32(&td->control, DBDMA_CLEAR(RUN|PAUSE|FLUSH|WAKE));	/* clear run bit */
 
 	/* free some skb's */
-	XXDEBUG(("bmac: free rx bufs\n"));
+	XXDEBUG ("bmac: free rx bufs\n") ;
 	for (i=0; i<N_RX_RING; i++) {
 		if (bp->rx_bufs[i] != NULL) {
 			dev_kfree_skb(bp->rx_bufs[i]);
@@ -1434,7 +1451,7 @@
 		}
 	}
 	bp->rx_allocated = 0;
-	XXDEBUG(("bmac: free tx bufs\n"));
+	XXDEBUG ("bmac: free tx bufs\n") ;
 	for (i = 0; i<N_TX_RING; i++) {
 		if (bp->tx_bufs[i] != NULL) {
 			dev_kfree_skb(bp->tx_bufs[i]);
@@ -1442,7 +1459,7 @@
 		}
 	}
 	bp->reset_and_enabled = 0;
-	XXDEBUG(("bmac: all bufs freed\n"));
+	XXDEBUG ("bmac: all bufs freed\n") ;
 
 	MOD_DEC_USE_COUNT;
 
@@ -1489,7 +1506,7 @@
 	unsigned short config, oldConfig;
 	int i;
 
-	XXDEBUG(("bmac: tx_timeout called\n"));
+	XXDEBUG ("bmac: tx_timeout called\n") ;
 	save_flags(flags); cli();
 	bp->timeout_active = 0;
 
@@ -1497,9 +1514,9 @@
 /*     	bmac_handle_misc_intrs(bp, 0); */
 
 	cp = &bp->tx_cmds[bp->tx_empty];
-/*	XXDEBUG((KERN_DEBUG "bmac: tx dmastat=%x %x runt=%d pr=%x fs=%x fc=%x\n", */
-/* 	   ld_le32(&td->status), ld_le16(&cp->xfer_status), bp->tx_bad_runt, */
-/* 	   mb->pr, mb->xmtfs, mb->fifofc)); */
+	/* XXDEBUG (KERN_DEBUG "bmac: tx dmastat=%x %x runt=%d pr=%x fs=%x fc=%x\n", */
+ 	/*    ld_le32(&td->status), ld_le16(&cp->xfer_status), bp->tx_bad_runt, */
+ 	/*    mb->pr, mb->xmtfs, mb->fifofc) ; */
 
 	/* turn off both tx and rx and reset the chip */
 	config = bmread(dev, RXCFG);
@@ -1518,8 +1535,8 @@
 	out_le32(&rd->control, DBDMA_SET(RUN|WAKE));
 
 	/* fix up the transmit side */
-	XXDEBUG((KERN_DEBUG "bmac: tx empty=%d fill=%d fullup=%d\n",
-		 bp->tx_empty, bp->tx_fill, bp->tx_fullup));
+	XXDEBUG (KERN_DEBUG "bmac: tx empty=%d fill=%d fullup=%d\n",
+		 bp->tx_empty, bp->tx_fill, bp->tx_fullup) ;
 	i = bp->tx_empty;
 	++bp->stats.tx_errors;
 	if (i != bp->tx_fill) {
@@ -1531,7 +1548,7 @@
 	bp->tx_fullup = 0;
 	dev->tbusy = 0;
 	mark_bh(NET_BH);
-	XXDEBUG((KERN_DEBUG "bmac: clearing tbusy\n"));
+	XXDEBUG (KERN_DEBUG "bmac: clearing tbusy\n") ;
 	if (i != bp->tx_fill) {
 		cp = &bp->tx_cmds[i];
 		out_le16(&cp->xfer_status, 0);
@@ -1539,7 +1556,7 @@
 		out_le32(&td->cmdptr, virt_to_bus(cp));
 		out_le32(&td->control, DBDMA_SET(RUN));
 		/* 	bmac_set_timeout(dev); */
-		XXDEBUG((KERN_DEBUG "bmac: starting %d\n", i));
+		XXDEBUG (KERN_DEBUG "bmac: starting %d\n", i) ;
 	}
 
 	/* turn it back on */

Re: BMAC stuff - what I have

[Robert E Brose II]

-- forwarded message --

Kernel version: any (2.2.x - 2.4.x)

Symptoms: high speed transfers from a macintosh with a BMAC network device are limited to less than 100kB/s and often corrupted.  Systems known to have this are some Wallstreets and beige Desktops.  10/100 chips in Lombard are BMAC+ which do not seem to have the bug.  This is a hardware bug that exists in some releases of the chip, and only effects Tx packets.

-- end of forwarded message --


I see the same problem on my Rev C iMac at 100 mb in both 2.2 and 2.4
kernels. I get slow transfers and broken scp's but not corrupted
data on complete transfers. Same machine works fine in MacOS and OSX.

Bob
--
Robert E. Brose II    N0QBJ
http://www.jriver.com/~bob/
bob@kunk.jriver.com

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: BMAC stuff - what I have

[Joseph P. Garcia]

On Sat, 10 Feb 2001 22:38:22 -0600 (CST), Robert E Brose II <bob@kunk.jriver.com> wrote:
> I see the same problem on my Rev C iMac at 100 mb in both 2.2 and 2.4
> kernels. I get slow transfers and broken scp's but not corrupted
> data on complete transfers. Same machine works fine in MacOS and OSX.
>
> Bob

Thanks for the input.

If it is true that the iMac has the same Tx problem, since they have always used BMAC+ (AppleSpec: 10/100 on all iMacs), I guess that this would mean that BMAC+ can also have this bug.  Can any one confirm this with an additional case?

It seems rather erratic on which systems are afflicted.  My brother's lombard is not affected, nor a wallstreet confirmed built after mine, which is.

In anycase, enough talk.  Anyone know dbdma well enough to approach a fix? :)

--
Joseph P. Garcia
http://www.execpc.com/~jpgarcia

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: BMAC stuff - what I have

[Iain Sandoe]

Hi Joseph,

> In anycase, enough talk.  Anyone know dbdma well enough to approach a fix? :)

It's not so bad to mess with...

http://www.rs6000.ibm.com/resource/technology/chrpio/dbdma5.mak.html

and...

"Macintosh Technology in the
Common Hardware Reference Platform"  - Apple Computer (MacTech.pdf)

although where to get the latter - officially - I'm not sure...

ciao,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: BMAC stuff - what I have

[Joseph P. Garcia]

let this be a lesson to me to be more vigalant in testing.  The patch posted earlier seems to work for me now. (2.4.2pre2)

smack me with a Bozo point or two.

--
Joseph P. Garcia
http://www.execpc.com/~jpgarcia

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: BMAC stuff - what I have

[Dan Malek]

"Joseph P. Garcia" wrote:

> If it is true that the iMac has the same Tx problem,

Yes, they do.  That is why we started working on it.  I just
tracked down some of the info from Darwin, and had someone else
work on it for a while.

> ... Anyone know dbdma well enough to approach a fix? :)

Yeah, but I don't have the time right now.  It's on the list of
things to do, but it doesn't bother me enough to stop other things
and fix it.  Since you asked, I thought I would at least give you
what I had so you wouldn't have to start from zero :-).


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: BMAC stuff - what I have

[Albrecht Dre_]

"Joseph P. Garcia" wrote:
[snip]
> It seems rather erratic on which systems are afflicted.  My brother's lombard
> is not affected, nor a wallstreet confirmed built after mine, which is.

Just for your information: I acutally *have* this problem quite frequently with
my Lombard/333 when it is connected to a 100MBit switch. It seems to work when
conntected to 1 10MBit hub, though.

Yours, Albrecht.


--

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/