[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Intel 8255x/eepro100 compatibility patches
From: |
Reimar Döffinger |
Subject: |
Re: [Qemu-devel] Intel 8255x/eepro100 compatibility patches |
Date: |
Sat, 15 Aug 2009 14:32:23 +0200 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
On Tue, Aug 11, 2009 at 11:13:51PM +0200, Reimar Döffinger wrote:
> On Tue, Aug 11, 2009 at 03:26:25PM -0500, Anthony Liguori wrote:
> > Please send this as a series of patches with each patch in an email.
>
> Ok, resending as a series of patches, hopefully this is the proper format now.
> Repeating myself a bit from the original mail:
> 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
>
> Hope this is interesting to someone and maybe we can even get these
> merged...
I know it hasn't been that long, but still: ping?
Btw. I have tested my patched version with OSX (10.5), OpenSolaris (0906),
Ubuntu (9.10
alpha) and FreeBSD 7.2 (admittedly only x86/x86_64) and found no issues.
- [Qemu-devel] [PATCH] Intel 8255x/eepro100 compatibility patches, Reimar Döffinger, 2009/08/09
- Re: [Qemu-devel] [PATCH] Intel 8255x/eepro100 compatibility patches, Stefan Weil, 2009/08/10
- Re: [Qemu-devel] [PATCH] Intel 8255x/eepro100 compatibility patches, Reimar Döffinger, 2009/08/11
- Re: [Qemu-devel] [PATCH] Intel 8255x/eepro100 compatibility patches, Anthony Liguori, 2009/08/11
- [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
- [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
- [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
- Re: [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., malc, 2009/08/11
- Re: [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
- Re: [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., malc, 2009/08/12
- Re: [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., Anthony Liguori, 2009/08/12
- Re: [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/13
- [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
- [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/11