qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Weil <weil@mail.berlios.de>
To: "Reimar Döffinger" <Reimar.Doeffinger@gmx.de>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] Intel 8255x/eepro100 compatibility patches
Date: Mon, 10 Aug 2009 06:36:58 +0200	[thread overview]
Message-ID: <4A7FA3EA.4080804@mail.berlios.de> (raw)
In-Reply-To: <20090809211433.GA8892@1und1.de>

Reimar Döffinger schrieb:
> Hello everyone,
> I have been playing around a bit with the OS X/darwin network drivers for these
> cards and noticed that they seem to differ quite a bit from the Linux ones.
> If you're interested, the source of the core part is here:
> http://www.opensource.apple.com/source/AppleIntel8255x/AppleIntel8255x-19/i82557Private.cpp
> Attached is a series of patches that makes things work with at least
> some version of that (sorry, I only tried some binary I found on the
> net, didn't compile from source).
> In addition, I also used the documentation from here:
> http://www.intel.com/design/network/manuals/8255X_OpenSDM.htm
>
> The first patch does not set the SBAck flag for MDI interrupts when
> interrupts are actually disabled for MDI.
> I think (have not tested yet) that this is not necessary to fix
> anything, but according to the documentation the current code is wrong.
>
> The second patch is to ensure that a driver will not
> accidentally/incorrectly change the RU/CU state with a write.
> This is incomplete and a bit ugly, but good enough for these drivers.
>
> The third patch adds support for some kind of receive buffers "flexible
> mode". The Intel documentation as I read it claims that no such mode exist
> for receive, but the fact that those (working with real hardware I
> expect) drivers use it contradicts that...
> This _definitely_ is necessary to support these drivers.
>
> And the last patch expands received data shorter than 60 bytes so no
> short-frame detection is incorrectly triggered, and of course also
> throws away all short-frame detection code since it makes no sense.
> It was also wrong since size is without CRC and thus the short frame
> limit is 60, not 64. And related to that (but without a patch), I think
> that the
>   
>>    } else if ((size > MAX_ETH_FRAME_SIZE + 4) && !(s->configuration[18] & 8)) {
>>     
> check is wrong, too, and the + 4 should not be there...
> Back to the patch, e.g. the rtl8139 driver also expands those frames
> (and I just copied the code for that).
> This too _definitely_ is necessary to support these drivers.
>
> Hope this is interesting to someone and maybe we can even get these
> merged...
>
> Thanks,
> Reimar Döffinger
>   


Hi,

this is interesting to me. Maybe you want to try a newer version of
eepro100.c. The latest version is in http://repo.or.cz/w/qemu/ar7.git,
http://repo.or.cz/w/qemu/ar7.git?a=blob;f=hw/eepro100.c

It has some really important improvements. I want to get it ready
for inclusion in the official QEMU by the end of August.

Regards
Stefan Weil

  reply	other threads:[~2009-08-10  4:37 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-09 21:14 [Qemu-devel] [PATCH] Intel 8255x/eepro100 compatibility patches Reimar Döffinger
2009-08-10  4:36 ` Stefan Weil [this message]
2009-08-10  6:42   ` Reimar Döffinger
2009-08-17  7:47   ` Reimar Döffinger
2009-08-11 18:27 ` Reimar Döffinger
2009-08-11 20:26   ` Anthony Liguori
2009-08-11 21:13     ` [Qemu-devel] " Reimar Döffinger
2009-08-15 12:32       ` Reimar Döffinger
2009-08-11 21:14     ` [Qemu-devel] [PATCH 1/5] Setting the MDI SCBAck flag when interrupts for MDI are disabled is wrong, even if it does not seem to cause any real issue with known drivers Reimar Döffinger
2009-08-11 21:14     ` [Qemu-devel] [PATCH 2/5] Hack to make sure that drivers like AppleIntel8255x will not meddle with the RU/CU state when the ACK the interrupt with a 16 bit write Reimar Döffinger
2009-08-11 21:15     ` [Qemu-devel] [PATCH 3/5] Add support for receiving via receive buffers. While the Intel documentation claims this is unsupported, the OS X drivers use it, causing an assertion failure since rx buffer size is 0 Reimar Döffinger
2009-08-11 23:04       ` malc
2009-08-12  0:35         ` Reimar Döffinger
2009-08-12 17:34           ` malc
2009-08-12 18:24             ` Anthony Liguori
2009-08-13 13:25           ` Reimar Döffinger
2009-08-11 21:15     ` [Qemu-devel] [PATCH 4/5] Short frames do not exist, so remove code to handle them. Also expand packets that are smaller than the shor frame limit, otherwise the OS X network stack seems to discard them Reimar Döffinger
2009-08-11 21:15     ` [Qemu-devel] [PATCH 5/5] Set the RU state to ru_no_resources instead of asserting when we used up the last receive buffer. This should not usually happen with good drivers, but it can happen with the OS X drivers at least Reimar Döffinger
2009-08-12  8:53     ` [Qemu-devel] [PATCH 6/5] Implement the trivial diagnose CU and RU abort commands. These are necessary to make the device work with OpenSolaris 0609 (111b) Reimar Döffinger

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=4A7FA3EA.4080804@mail.berlios.de \
    --to=weil@mail.berlios.de \
    --cc=Reimar.Doeffinger@gmx.de \
    --cc=qemu-devel@nongnu.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).