Problems with Ethernet on PowerBook Wallstreet G3

Problems with Ethernet on PowerBook Wallstreet G3

[Wolfgang Denk]

Hi,

I'm experiencing serious  problems  with  ethernet  on  my  PowerBook
Wallstreet G3; my hope that LinuxPPC 2000 would do some magic to make
it go away was in vain.

I have seen similar trouble reports (Josh Huber <huberj@wpi.edu>  and
Joseph Garcia <jpgarcia@execpc.com>; Tue, 8 Feb 2000: "BMAC eth prob-
lems..."), but never seen a solution...

Summary: outgoing traffic is extremely slow; outgoing TCP streams get
corrupted without notice.

* Ethernet is extremely slow when SENDING data.  While  incoming  FTP
  traffic  reaches  800...900  kB/s  (which  seems  ok  on  a 10 mbps
  network), outgoing traffic makes only 40...50 kB/s.

* Outgoing data gets corrupted: larger outgoing  FTP  file  transfers
  get  corrupted  every  now and then - gzip compressed data will not
  uncompress because of checksum errors,  and  checksuming  the  file
  before and after the FTP trasfer verifies this.

* NFS traffic seems to be a bit better (somewhat faster, a  lot  less
  corruption), but is still creeping slow.

* When using the PowerBook as NFS _server_, on the client I will  see
  error messages:

	nfs: server 10.0.0.3 not responding, still trying
	nfs: server 10.0.0.3 not responding, still trying
	nfs: server 10.0.0.3 OK
	nfs: server 10.0.0.3 OK
	...
	nfs: server 10.0.0.3 not responding, still trying
	nfs: server 10.0.0.3 not responding, still trying
	nfs: server 10.0.0.3 OK
	nfs: server 10.0.0.3 OK
	...
	nfs: server 10.0.0.3 not responding, still trying
	nfs: server 10.0.0.3 not responding, still trying
	nfs: server 10.0.0.3 OK
	nfs: server 10.0.0.3 OK

* The problem is persistent on all types of  network  connections;  I
  tried:

  - Connecting to a switching dual speed (10/100 mbps) hub
  - Connecting to a simple 10 mbps hub
  - direct connection using a crossover cable

  Network load is minimal, and  all  other  systems  don't  show  any
  problems. I see 0 collisions on the powerbook, and not many (<0.2%)
  on my other systems.

  The only indication of netwoprk problewms I've seen so far  is  the
  following:

	Apr  9 04:22:07 diddl arpwatch: 0:5:2:7:39:97 sent bad addr len (hard 0, prot 4)
	Apr  9 04:24:37 diddl arpwatch: 0:5:2:7:39:97 sent bad addr len (hard 0, prot 4)
	Apr  9 04:44:06 diddl arpwatch: 0:5:2:7:39:97 sent bad addr len (hard 0, prot 4)
	Apr  9 04:45:07 diddl arpwatch: 0:5:2:7:39:97 sent bad addr len (hard 0, prot 4)
	Apr  9 04:55:37 diddl arpwatch: 0:5:2:7:39:97 sent bad addr len (hard 0, prot 4)
	Apr  9 05:22:07 diddl arpwatch: 0:5:2:7:39:97 sent bad addr len (hard 0, prot 4)
	Apr  9 05:34:07 diddl arpwatch: 0:5:2:7:39:97 sent bad addr len (hard 0, prot 4)
	Apr  9 05:56:37 diddl arpwatch: 0:5:2:7:39:97 sent bad addr len (hard 0, prot 4)
	Apr  9 06:28:07 diddl arpwatch: 0:5:2:7:39:97 sent bad addr len (hard 0, prot 4)
	Apr  9 06:31:07 diddl arpwatch: 0:5:2:7:39:97 sent bad addr len (hard 0, prot 4)

  The address reported _is_ the ethernet address of my PowerBook, but
  unfortunately I'm not able to reproduce the situation  that  caused
  these  messages  to be logged, nor do I know what might have caused
  them.



This makes the system basicly unsuable for all network based work.

Any ideas what migh cause this type of problem - and how to fix it ?!?

Thanks in advance,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
As in certain cults it is possible to kill a process if you know  its
true name.                      -- Ken Thompson and Dennis M. Ritchie

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

Re: Problems with Ethernet on PowerBook Wallstreet G3

[Benjamin Herrenschmidt]

On Tue, Apr 11, 2000, David A. Gatwood <dgatwood@deepspace.mklinux.org> wrote:

>> * Ethernet is extremely slow when SENDING data.  While  incoming  FTP
>>   traffic  reaches  800...900  kB/s  (which  seems  ok  on  a 10 mbps
>>   network), outgoing traffic makes only 40...50 kB/s.
>
>Interesting.  The MkLinux driver exhibits the same symptoms.  Hmm... I
>wonder....  Do a side by side code comparison, and they're basically the
>same driver...  *coughs*  You might want to have a look at Darwin's
>drivers and see if they shed any light on this.  Unless of course, that's
>just another clone....  I won't even ask....
>
>There are apparently occasional issues of outgoing packets getting hosed.
>Probably a DMA bug somewhere, if I were guessing, but....  I seem to
>recall the data being off by a byte in one direction or the other (i.e. a
>byte getting dropped or added), but I could be remembering wrong.  It has
>been a very long time since I heard anyone mention this bug -- as in two
>years, at least.

The Darwin bmac driver contains interesting comments about chip bugs that
cause Tx packets to get corrupted in some conditions (and possibly other
issues). I didn't have time to look more closely, but for those
interested, the new kernel in Darwin CVS is the module System/xnu (not
System/kernel, this is the old kernel).

Ben.


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

Re: Problems with Ethernet on PowerBook Wallstreet G3

[Joseph Garcia]

Here's my observations on whats happening with my system (PDQ/300):

Any out-going FTP transfer maxes around 100K/s, and has potential to corrupt.
NFS, atalk, etc seem to be ok.  Incoming transfers also seem to be ok.  By
outgoing, I do mean out going.  Whether its with a server (wu or pro), or a
client, if the file originates from my powerbook, it has this common problem.

During the time of transfer, the collision light on the hub blares.  I have
tried this with a normal hub and a switch.  As far as I can tell, this would
mean it is colliding with itself.  How else could a switched hub get collisions
this prevalent?

Initially, I was thinking that this is a bug brought on by the BMAC+, a
sibling/upgrade to the BMAC that can do 100BT and full duplex.  I looked at the
driver, and one wait value was changed from a few hundred ms (early 2.2.x) to 10
ms.  I tried switching it back, but there was no change.  so its not that.
Anything else that could be causing it?  I don't remember this problem with
earlier 2.2 kernels.  Anyone confirm this?  2.1.x maybe?

I severly doubt it is a pure TCP problem, because ftp using the lo device
regards high return.  The only possible cause is the BMAC driver IMO.  But how
would it only effect FTP outgoing?  I've heard that FTP uses raw bandwidth, so
does that mean it uses some low level handshaking that nothing else uses, and
depends on the file's host?   So where do FTP-out and BMAC collide in such a way
that it doesnt affect lo, nor incoming files?

Sorry if I'm ranting.

Is this info any help?

--
Joseph P. Garcia      jpgarcia@execpc.com      jpgarcia@lidar.ssec.wisc.edu
CS Undergraduate                      Student Employee - Systems Programmer
University of Wisconsin - Madison                            UW Lidar Group

"Did you ever notice how the Chinese Abacus, with 2 '5' beads and 5 '1'
beads, is perfect for hexidecimal math?"

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

Re: Problems with Ethernet on PowerBook Wallstreet G3

[Benjamin Herrenschmidt]

Browsing the Darwin bmac driver source, I found some interesting comments:

 /*-------------------------------------------------------------------------
 * Work around a hardware bug where the controller will receive
 * unicast packets not directed to the station. The hardware is
 * erroneously using the hash table to qualify the unicast address.
 * This routine will check that the packet is unicast, and if so,
 * makes sure that the unicast address matches the station's address.
 * Thus function returns true if the packet should be rejected.
 *-------------------------------------------------------------------------*/

(This unicast filter workaround is enabled when the PCI device-id of the
chip is 0x10)


      /*
       * On the transmit side, we use the chipset interrupt. Using the
	   * transmit DMA interrupt (or having multiple transmit DMA entries)
	   * would allows us to send the next frame to the chipset prior the
	   * transmit fifo going empty.
       * However, this aggrevates a BMac chipset bug where the next frame
going
	   * out gets corrupted (first two bytes lost) if the chipset had to retry
	   * the previous frame.
       */

/*-------------------------------------------------------------------------
 * _sendDummyPacket
 * ----------------
 * The BMac receiver seems to be locked until we send our first packet.
 *
 *-------------------------------------------------------------------------*/


		/*
		 * The BMac Ethernet controller appends two bytes to each receive
		 * buffer containing the buffer
		 * size and receive frame status.
		 * We locate these bytes by using the DMA residual counts.
		 */


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

Re: Problems with Ethernet on PowerBook Wallstreet G3

[David A. Gatwood]

On Wed, 12 Apr 2000, Joseph Garcia wrote:

> Initially, I was thinking that this is a bug brought on by the BMAC+, a

Nope.  The original bmac had this bug, too, as did this driver before bmac
was supported.  (Or at least the MkLinux version of this driver, which you
can compare line-for-line for grins.)


> change.  so its not that.  Anything else that could be causing it?  I
> don't remember this problem with earlier 2.2 kernels.  Anyone confirm
> this?  2.1.x maybe?

Unless there was a previous bmac driver that used different code, it is
unlikely that this ever worked right.  Especially, given that even Apple's
Darwin code says it's a hardware bug.  Two words: sun ethernet....  ;-)


David

---------------------------------------------------------------------
A logician trying to explain logic to a programmer is like a cat
trying to explain to a fish what it's like to be wet.

	-- unknown, possibly Franklin Veaux


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

Re: Problems with Ethernet on PowerBook Wallstreet G3

[Michael Schmitz]

On Wed, 12 Apr 2000, Benjamin Herrenschmidt wrote:

> Browsing the Darwin bmac driver source, I found some interesting comments:
>
>       /*
>        * On the transmit side, we use the chipset interrupt. Using the
> 	   * transmit DMA interrupt (or having multiple transmit DMA entries)
> 	   * would allows us to send the next frame to the chipset prior the
> 	   * transmit fifo going empty.
>        * However, this aggrevates a BMac chipset bug where the next frame
> going
> 	   * out gets corrupted (first two bytes lost) if the chipset had to retry
> 	   * the previous frame.
>        */

Extremely ugly. Does this mean corruption even happens when using the
device interrupt? Anyway, we seem to be using the txdma interrupt so this
bug is what bites us probably.

> 		/*
> 		 * The BMac Ethernet controller appends two bytes to each receive
> 		 * buffer containing the buffer
> 		 * size and receive frame status.
> 		 * We locate these bytes by using the DMA residual counts.
> 		 */

Need to allocate large enough receive buffers here :-) That's already
taken care of:
	/* initialize list of sk_buffs for receiving and set up recv dma
*/
	if (!bp->rx_allocated) {
	        for (i = 0; i < N_RX_RING; i++) {
	                bp->rx_bufs[i] = dev_alloc_skb(RX_BUFLEN+2);
                        if (bp->rx_bufs[i] == NULL) return 0;
	                skb_reserve(bp->rx_bufs[i], 2);
	        }
	        bp->rx_allocated = 1;
	}

	Michael


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

Re: Problems with Ethernet on PowerBook Wallstreet G3

[Wolfgang Denk]

In message <38F4BBFA.B3CE8273@execpc.com> Joseph Garcia wrote:
>
> Any out-going FTP transfer maxes around 100K/s, and has potential to corrupt.
> NFS, atalk, etc seem to be ok.  Incoming transfers also seem to be ok.  By
> outgoing, I do mean out going.  Whether its with a server (wu or pro), or a
> client, if the file originates from my powerbook, it has this common problem.

This is exactly what I am seeing.

> During the time of transfer, the collision light on the hub blares.  I have
> tried this with a normal hub and a switch.  As far as I can tell, this would
> mean it is colliding with itself.  How else could a switched hub get collisions
> this prevalent?

Same for me. And another observation:  the  collision  count  of  the
Ethernet interface n the Mac stays at "2" (yes, two) all the time.

> ms.  I tried switching it back, but there was no change.  so its not that.
> Anything else that could be causing it?  I don't remember this problem with
> earlier 2.2 kernels.  Anyone confirm this?  2.1.x maybe?

I think I had LinuxPPC R4 without this problem. Maybe I will dig out
the old CD-ROMs.

> I severly doubt it is a pure TCP problem, because ftp using the lo device
> regards high return.  The only possible cause is the BMAC driver IMO.  But how
> would it only effect FTP outgoing?  I've heard that FTP uses raw bandwidth, so
> does that mean it uses some low level handshaking that nothing else uses, and
> depends on the file's host?   So where do FTP-out and BMAC collide in such a way
> that it doesnt affect lo, nor incoming files?

I'm trying to figure out what triggers the  problem,  and  what  gets
corrupted. First, I seem to have no problems (in terms of corruption;
the  slow  speed  is  always there) when the PB ist mostly idle, just
doing FTP'ing an existing file. However, when  I'm  running  a  "gtar
-zcf  -  | rsh somewhere_else "cat >foo.gz" I can be pretty sure that
"foo.gz" gets corrupted.

I also get corruptions when I'm running a "ls -lR  /"  in  the  back-
ground.

==> It seems that a lot of disk activity raises  the  probability  of
    the corruption.

I've FTP'ed a few big files; here is an example of what happens:  "0"
was  transferred  OK  while  the  disks  were  idle; "1" and "2" were
transferred with a "ls -lR /" running, and got corrupted:

-> ls -l 0 1 2
-rw-r--r--   1 wd       users    48867469 Apr 13 00:02 0
-rw-r--r--   1 wd       users    48867469 Apr 12 23:39 1
-rw-r--r--   1 wd       users    48867469 Apr 12 23:56 2
-> gzip -vt 0 ; gzip -vt 1 ; gzip -vt 2
0:                       OK
1:
gzip: 1: invalid compressed data--crc error
2:
gzip: 2: invalid compressed data--format violated


Comparing the files gives:

-> cmp -l 0 1
44003307 201  51
44003309 117 361
44003311  51 205
44003313 361  61
44003315 205 202
44003317  61 221
44003319 202 170
44003321 221 217
44003323 170  64
44003325 217 312
44003327  64 271
44003329 312  12
44003331 271 341
44003333  12 320
44003335 341 345
44003337 320  47
...

-> cmp -l 0 2
6572503  57 315
6572505 310  22
6572507 315 165
6572509  22 141
6572511 165  60
6572513 141  36
6572515  60 112
6572517  36 320
6572519 112 243
6572521 320 303
6572523 243 250
6572525 303  26
6572527 250  32
6572529  26 142
6572531  32 150
6572533 142 233
...


This shows an interesting  problem:  only  the  ODD  data  bytes  get
corrupted,  being "shifted down" with an offset of 4 (two "odd bytes"
are missing); but the total size of the files is OK again...

-> xd 0 +0x6449d0 | head
  6449d0  c5fee1f0 a7392f93  c80dcdda 127575c2  |     9/      uu |
First corruption here -^^    ^^  ^^   ^^  ^^
  6449e0  612030d7 1e5e4a2f  d02aa352 c3f3a887  |a 0  ^J/ * R    |
  6449f0  16361ace 623768e1  9b2724f4 299b8530  | 6  b7h  '$ )  0|
  644a00  024d53ab b7e6a185  86cc7448 3741c0dc  | MS       tH7A  |
  644a10  cf49887c 8470e8e5  01bd1b65 d9dd1b44  | I | p     e   D|
  644a20  a1bf7924 42154515  4d515c74 34593432  |  y$B E MQ\t4Y42|
  644a30  f416deb6 1885ea08  f3d53604 85847255  |          6   rU|
  644a40  4f061242 e401e067  458894e4 21d01233  |O  B   gE   !  3|
  644a50  6fb929eb f2f98b1f  eb3df035 af1805e0  |o )      = 5    |
  644a60  bc0702a6 5f812a08  09d103c0 a4bae645  |    _ *        E|
  ...
-> xd 2 +0x6449d0 | head
  6449d0  c5fee1f0 a739cd93  120d75da 617530c2  |     9    u au0 |
First corruption here -^^    ^^  ^^   ^^  ^^
  6449e0  1e204ad7 d05ea32f  c32aa852 16f31a87  |  J  ^ / * R    |
  6449f0  623668ce 9b3724e1  292785f4 029b5330  |b6h  7$ )'    S0|
  644a00  b74da1ab 86e67485  37ccc048 cf4188dc  | M    t 7  H A  |
  644a10  8449e87c 01701be5  d9bd1b65 a1dd7944  | I | p     e  yD|
  644a20  42bf4524 4d155c15  34513474 f459de32  |B E$M \ 4Q4t Y 2|
  644a30  1816eab6 f3853608  85d57204 4f841255  |      6   r O  U|
  644a40  e406e042 45019467  218812e4 6fd02933  |   BE  g!   o )3|
  644a50  f2b98beb ebf9f01f  af3d0535 bc1802e0  |         = 5    |
  644a60  5f072aa6 09810308  a4d1e6c0 ddbaec45  |_ *            E|
  ...

Does this trigger any ideas in anybody?

Wolfgang

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Harrison's Postulate:
	For every action, there is an equal and opposite criticism.

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

Re: Problems with Ethernet on PowerBook Wallstreet G3

[Wolfgang Denk]

Even more observations:

=> Corruption happens in "chunks" that look like network packets:

	-> cmp -l 0 2
      1 6572503  57 315
      2 6572505 310  22
      3 6572507 315 165
      4 6572509  22 141
	...
    699 6573909 240 135
    700 6573911 324 104
    701 6573913 135 226
    702 6573915 104 141	<= 1412 Bytes bad, followed by good data, until:
    703 11721589 240 226
    704 11721591  16 251
    705 11721593 226 261
    706 11721595 251 115
	...
   1404 11722997 173  43
   1405 11722999 301  61
   1406 11723001  43 201
   1407 11723003  61  55 <= 1414 Bytes bad, followed by good data, until:
   1408 39669229 166 277
   1409 39669231  70 330
   1410 39669233 277  33
   1411 39669235 330  23
	...
   2195 40193571 254 373
   2196 40193573 155 242
   2197 40193575 373   2
   2198 40193577 242 321
   2199 40193579   2  22 <=
   2200 43640893   0 267
   2201 43640969 221 156
   2202 43640971 141  70
   2203 43640973 156 202
	...

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
The most difficult thing in the world is to know how to  do  a  thing
and to watch someone else doing it wrong, without commenting.
                                                        -- T.H. White

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

Re: Problems with Ethernet on PowerBook Wallstreet G3

[Wolfgang Denk]

In message <Pine.LNX.4.10.10004130948140.10131-100000@opal.biophys.uni-duesseldorf.de> you wrote:
>
> That might be a result of the interface init - if there are no real
> collisions otherwise. What number of collisions does the other machine
> log?

Seems normal to me for a usually lightly loaded network; for instance:

          RX packets:15315134 errors:1699 dropped:210 overruns:1691 frame:16
          TX packets:1427615 errors:7 dropped:0 overruns:3 carrier:4
          collisions:27791 txqueuelen:100

          RX packets:11453931 errors:10 dropped:0 overruns:0 frame:20
          TX packets:5286558 errors:3 dropped:0 overruns:2 carrier:1
          collisions:1157 txqueuelen:100

          RX packets:2011658 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1477258 errors:0 dropped:0 overruns:0 carrier:0
          collisions:8579 txqueuelen:100

> This, together with your info that the missing bytes happen on packet
> boundaries, strongly supports BenH's idea that we may be running into the
> txdma bug quoted above. The chipset apparently needs to be tweaked some
> way to reset the transmitter before starting the next DMA frame.

Yepp.

> What machine is on the receiving end? The file size being conserved may be

The other machines are either PC's running Linux (2.2.12 on a AMD-K6,
2.2.13 on a dual P-II, 2.3.51 on a dual P-III)  or  embedded  systems
(2.2.13 on MPX8xx, with xx=23, 50 and 60).

> due to Linux only looking at the packet size from the header (not cross
> checking with the size actually received), the sending machine padding the
> packet, or the BMAC on the receiving end placing packet size and status at
> the end of the frame.
>
> No idea why the bug correlates with disk activity - is the disk interrupt
> priority higher than ethernet DMA?

Well, I have no absolute evidence that there is a strict correlation.
It's more a certain feeling, and the observation that usually a  'tar
-zcf  - . | rsh ..." is almost certain to fail, while a plain FTP has
at least a 50...70% chance to be ok.

Regarding the interrupts:

# cat /proc/interrupts
           CPU0
  4:          0   PMAC-PIC      SCC-txdma
  5:          0   PMAC-PIC      SCC-rxdma
  6:          0   PMAC-PIC      SCC-txdma
  7:          0   PMAC-PIC      SCC-rxdma
  8:          1   PMAC-PIC      AWACS out
 12:         15   PMAC-PIC      MESH
 13:      20987   PMAC-PIC      ide0
 14:          5   PMAC-PIC      ide1
 15:          0   PMAC-PIC      SCC
 16:          0   PMAC-PIC      SCC
 17:          0   PMAC-PIC      AWACS
 18:       6587   PMAC-PIC      VIA-PMU
 19:          0   PMAC-PIC      SWIM3
 27:          1   PMAC-PIC      interrupt cascade
 32:      92922   PMAC-PIC      BMAC-txdma
 33:      70818   PMAC-PIC      BMAC-rxdma
 42:     163755   PMAC-PIC      BMAC-misc
 68:          0   PMAC-PI2      SCC-txdma
 69:          0   PMAC-PI2      SCC-rxdma
 79:          0   PMAC-PI2      SCC
 83:          0   PMAC-PI2      SWIM3

Hm... I have no idea if this relates to interrupt priorities on  this
box.

Also, after a failing FTP transfer:

# cat /proc/net/bmac
BMAC counters & registers
MEMADD: 0x000000
MEMDATAHI: 0x000000
MEMDATALO: 0x000000
TXPNTR: 0x000214
RXPNTR: 0x0002ce
IPG1: 0x000008
IPG2: 0x000004
ALIMIT: 0x000010
SLOT: 0x000040
PALEN: 0x000007
PAPAT: 0x0000aa
TXSFD: 0x0000ab
JAM: 0x000004
TXCFG: 0x000001
TXMAX: 0x0005ee
TXMIN: 0x000040
PAREG: 0x00000b
DCNT: 0x00b861
NCCNT: 0x0092cf
NTCNT: 0x003635
EXCNT: 0x000000
LTCNT: 0x000000
TXSM: 0x000010
RXCFG: 0x000b01
RXMAX: 0x0005ee
RXMIN: 0x000040
FRCNT: 0x0014d2
AECNT: 0x000000
FECNT: 0x000000
RXSM: 0x000002
RXCV: 0x000000

# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:05:02:07:39:97
          inet addr:10.0.0.3  Bcast:10.255.255.255  Mask:255.0.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:70896 errors:1 dropped:0 overruns:0 frame:0
          TX packets:92979 errors:2 dropped:0 overruns:0 carrier:0
          collisions:0


Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"It is better to have tried and failed than to have  failed  to  try,
but the result's the same."                           - Mike Dennison

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

Re: Problems with Ethernet on PowerBook Wallstreet G3

[Wolfgang Denk]

In message <38F5A91D.1212ECEC@drea.dnd.ca> Gavin Hemphill wrote:
>
> ...
> other so I don't think its LinuxPPC that's causing your problem.  If you
> can test it out try the same ftp's from the MacOS - if you see low rates
> there, then you have a hardware problem - cable, whatever.

Right, I should have mentioned this before: FTP under MacOS is  fine:
full speed (800...900 kB/s), no corrupted data.

So I'm pretty sure it's a software problem with LinuxPPC.

Wolfgang

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
People have one thing in common: they are all different.

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

Re: Problems with Ethernet on PowerBook Wallstreet G3

[Joseph Garcia]

Gavin Hemphill wrote:
> Hmmm, I've been trying to replicate the problems with my two Wallstreet
...
> corruption abounds - Looks like it has something to do with an
> interatction on DMA with the internal IDE drive and the ethernet.

Could this be related to the IDE issues that have been discovered with my hard
drive?  This would mean that there could be a bug in the way DMA is implemented
in hardware on the wallstreet motherboard.  It has been mentioned its possible.
(small flashback: corruption on occation when playing sound, often ro programs
when executed (vi got hit; would run, but would error. few flipped bits
probably), mentioned in SoundJam's readme.  'Contact Apple')

Since MacOS doesn't seem to have any of these problems, there is a solution.

my hard drive from dmesg:
hda: IBM-DYLA-28100, ATA DISK drive
hda: IBM-DYLA-28100, 7815MB w/459kB Cache, CHS=15880/16/63, (U)DMA

Since my brother's lombard has a Toshiba HD, could this all be funkyness with
IBM drives, God forbid? (as opposed to just the BMAC+ doesnt have the hw bug)

Before we start being suspicious, anyone with a non-IBM drive having this
problem?

--
Joseph P. Garcia      jpgarcia@execpc.com      jpgarcia@lidar.ssec.wisc.edu
CS Undergraduate                      Student Employee - Systems Programmer
University of Wisconsin - Madison                            UW Lidar Group

"Did you ever notice how the Chinese Abacus, with 2 '5' beads and 5 '1'
beads, is perfect for hexidecimal math?"

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

Re: Problems with Ethernet on PowerBook Wallstreet G3

[Benjamin Herrenschmidt]

On Thu, Apr 13, 2000, Joseph Garcia <jpgarcia@execpc.com> wrote:

>Could this be related to the IDE issues that have been discovered with
my hard
>drive?  This would mean that there could be a bug in the way DMA is
>implemented
>in hardware on the wallstreet motherboard.  It has been mentioned its
>possible.
>(small flashback: corruption on occation when playing sound, often ro
programs
>when executed (vi got hit; would run, but would error. few flipped bits
>probably), mentioned in SoundJam's readme.  'Contact Apple')

Note that the controller used on the wallstreet is the same used on the
Beige G3 and is very close to the one used in iMacs and B&W G3s.

>Since MacOS doesn't seem to have any of these problems, there is a solution.
>
>my hard drive from dmesg:
>hda: IBM-DYLA-28100, ATA DISK drive
>hda: IBM-DYLA-28100, 7815MB w/459kB Cache, CHS=15880/16/63, (U)DMA
>
>Since my brother's lombard has a Toshiba HD, could this all be funkyness with
>IBM drives, God forbid? (as opposed to just the BMAC+ doesnt have the hw bug)
>
>Before we start being suspicious, anyone with a non-IBM drive having this
>problem?

Well, there is no mention I've seen of such a bug in the Darwin driver.
However, there are a few things worth noting:

 - Darwin enables a bit in the host bridge that allows retrying of some
DMA transactions. Look like this bit is necessary (don't ask me why) and
is not set by the firmware. I have added code to set it in my recent
kernels. However, since Wallstreet's are usually booted via BootX, MacOS
should have set it before entering the kernel. (I don't have the details
under the hand, but you can look in my rsync tree, it's in pmac_pci.c).

 - Older Darwin source contains a comment about a bug in Ohare and Grand
Central DBDMA controller known to clobber datas around memory buffers
when they are not 16-byte aligned. Well, to my knowledge, the IDE always
transfers aligned pages, and the controller in the wallstreet is not an
ohare, but it's worth noting (and should be fixed in other drivers).

 - I have to check what's exactly happening when an odd byte count is
transferred (this happens regulary with ATAPI). The controller itself
always transfer even quantities. Darwin has special provisions for that
by adding a special command at the end of the DBDMA transfer to copy this
remaining byte to a bit bucket. We don't.

 - Before starting a DBDMA command, it would be nice to issue at least a
sync to make sure that the write of the last DBDMA commands to memory has
left the CPU write buffer and will be hanlded by the cache coherency
before the DBDMA controller actually starts. I don't know if there's room
for trouble or not, but this would do no harm. Actually, I'm wondering if
it may be better to store DBDMA command lists in non-cachable memory.

 - There may be something wrong in the MDMA timing calculations. The code
we use should be equivalent to darwin. but...


That's all I have in mind for now. Of course, there's still the
possibility of a bug in the IDE layer that would cause this corruption...
(or a bug in the sound driver that would cause the sound DBDMA channel to
overflow it's allocated buffers but I don't think so).

Note finally that a generic kernel ext2 bug was recently found that could
cause corruptions under certain conditions, especially OOM. (see the
kernel mailing list).

Ben.


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

Re: Problems with Ethernet on PowerBook Wallstreet G3

[David A. Gatwood]

On Thu, 13 Apr 2000, Joseph Garcia wrote:

> Gavin Hemphill wrote:
> > Hmmm, I've been trying to replicate the problems with my two Wallstreet
> ...
> > corruption abounds - Looks like it has something to do with an
> > interatction on DMA with the internal IDE drive and the ethernet.
>
> Could this be related to the IDE issues that have been discovered with my hard
> drive?  This would mean that there could be a bug in the way DMA is implemented
> in hardware on the wallstreet motherboard.  It has been mentioned its possible.
> (small flashback: corruption on occation when playing sound, often ro programs
> when executed (vi got hit; would run, but would error. few flipped bits
> probably), mentioned in SoundJam's readme.  'Contact Apple')
>
> Since MacOS doesn't seem to have any of these problems, there is a solution.
>
> my hard drive from dmesg:
> hda: IBM-DYLA-28100, ATA DISK drive
> hda: IBM-DYLA-28100, 7815MB w/459kB Cache, CHS=15880/16/63, (U)DMA
>
> Since my brother's lombard has a Toshiba HD, could this all be funkyness with
> IBM drives, God forbid? (as opposed to just the BMAC+ doesnt have the hw bug)
>
> Before we start being suspicious, anyone with a non-IBM drive having this
> problem?

It also happens on some desktop G3s with Western Digital drives under
MkLinux.  The only constants are the processor, the PCI bus bridge, I
think the dma controller, and the ethernet chip, and of course, the
ethernet driver.  If it's software, there's pretty much only one or two
places where it could be, given the very minimal code sharing between the
two OSes....


Later,
David

---------------------------------------------------------------------
A logician trying to explain logic to a programmer is like a cat
trying to explain to a fish what it's like to be wet.

	-- unknown, possibly Franklin Veaux


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