linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Joseph P. Garcia" <jpgarcia@execpc.com>
To: Jim Blackburn <blackbjm@jmu.edu>
Cc: linuxppc-dev@lists.linuxppc.org
Subject: Re: BMAC driver issue addressed?
Date: Mon, 30 Oct 2000 12:22:36 -0600	[thread overview]
Message-ID: <39FDBC6C.1F6496CF@execpc.com> (raw)
In-Reply-To: B6231A90.1458%blackbjm@jmu.edu


Jim Blackburn wrote:
>
> Hi all:
>
> I experience the infamous problems with the bmac driver on my beige g3
> minitower.  A while back there was talk of analyzing Darwin's workaround for
> the bmac's hardware issues and implementing that into Linux's kernel.  Has
> anyone taken on this project since that discussion, or has it been shuffled
> down to the bottom of the deck in light of more pressing issues with the
> kernel?

By which i think you mean the collide-with-self with 100k/s max Xfer w/ errors?
I'd still like to see it fixed :)

I tried to fix it at one point, but didnt get far.  My code only caused the
kernel to panic, but I should mention, it panicked whenever it would normally
have stalled or collided.  Looking closer, it would appear that what I was
doing, which was ignoring packets that aren't for us or our Masq, seems to be
already done in the Linux kernel.  maybe my implementation was doing something
different and more correct, save the panic.

Looking at the darwin kernel, which is where I got the idea, It looks like it
was doing it for a particular revision of the motherboard, which I remember
calling 0x10.  My PDQ i think is a 0x17, and I had the pleasure of running my
Linux setup on a 0x10 at one point.  the 0x10 did not have the collision problem
in linux, while my 0x17 does.  the value refers to some value somewhere in the
device tree.  im sure you can find it after looking at where Darwin gets it. it
might be /proc/device-tree/pci/mac-io/device-id (lsprop)

I'm still puzzled about the whole thing, like if Darwin is filtering those
packets we should be ignoring anyway, and Linux does too, Is this really the
problem?  And what was it I was really doing those months ago?  (sorry, i lost
my old code)  I recall using standard things in the kernel.  just one acception
added that was in the case of it should have been ignored by the chip.

According to the ppclinux sourceforge bug tracker, the problem was fixed for a
patched kernel or two.  <shrug>

Corrections?  Comments?

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

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

  reply	other threads:[~2000-10-30 18:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-10-30 17:31 BMAC driver issue addressed? Jim Blackburn
2000-10-30 18:22 ` Joseph P. Garcia [this message]
2000-10-30 18:57   ` Benjamin Herrenschmidt
2000-10-30 20:12     ` Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=39FDBC6C.1F6496CF@execpc.com \
    --to=jpgarcia@execpc.com \
    --cc=blackbjm@jmu.edu \
    --cc=linuxppc-dev@lists.linuxppc.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).