On Tue, Sep 21, 2010 at 11:17:07AM +0200, Michael S. Tsirkin wrote:
> On Mon, Sep 20, 2010 at 10:51:36PM +0200, Edgar E. Iglesias wrote:
> > On Mon, Sep 20, 2010 at 03:31:32PM -0500, Anthony Liguori wrote:
> > > On 09/20/2010 05:42 AM, Michael S. Tsirkin wrote:
> > > > On Sun, Sep 19, 2010 at 07:36
On Mon, Sep 20, 2010 at 10:51:36PM +0200, Edgar E. Iglesias wrote:
> On Mon, Sep 20, 2010 at 03:31:32PM -0500, Anthony Liguori wrote:
> > On 09/20/2010 05:42 AM, Michael S. Tsirkin wrote:
> > > On Sun, Sep 19, 2010 at 07:36:51AM +0100, Stefan Hajnoczi wrote:
> > >
> > >> On Sat, Sep 18, 2010 at
On Mon, Sep 20, 2010 at 9:31 PM, Anthony Liguori wrote:
> On 09/20/2010 05:42 AM, Michael S. Tsirkin wrote:
>>
>> On Sun, Sep 19, 2010 at 07:36:51AM +0100, Stefan Hajnoczi wrote:
>>
>>>
>>> On Sat, Sep 18, 2010 at 10:27 PM, Edgar E. Iglesias
>>> wrote:
>>>
This doesn't look right. AFAI
On Mon, Sep 20, 2010 at 10:40:35PM +0200, Edgar E. Iglesias wrote:
> On Mon, Sep 20, 2010 at 03:31:32PM -0500, Anthony Liguori wrote:
> > On 09/20/2010 05:42 AM, Michael S. Tsirkin wrote:
> > > On Sun, Sep 19, 2010 at 07:36:51AM +0100, Stefan Hajnoczi wrote:
> > >
> > >> On Sat, Sep 18, 2010 at
On Mon, Sep 20, 2010 at 03:31:32PM -0500, Anthony Liguori wrote:
> On 09/20/2010 05:42 AM, Michael S. Tsirkin wrote:
> > On Sun, Sep 19, 2010 at 07:36:51AM +0100, Stefan Hajnoczi wrote:
> >
> >> On Sat, Sep 18, 2010 at 10:27 PM, Edgar E. Iglesias
> >> wrote:
> >>
> >>> This doesn't look
On Mon, Sep 20, 2010 at 10:44:34PM +0200, Michael S. Tsirkin wrote:
> On Mon, Sep 20, 2010 at 10:40:35PM +0200, Edgar E. Iglesias wrote:
> > On Mon, Sep 20, 2010 at 03:31:32PM -0500, Anthony Liguori wrote:
> > > On 09/20/2010 05:42 AM, Michael S. Tsirkin wrote:
> > > > On Sun, Sep 19, 2010 at 07:36
On 09/20/2010 03:44 PM, Michael S. Tsirkin wrote:
>>> From f77c3143f3fbefdfa2f0cc873c2665b5aa78e8c9 Mon Sep 17 00:00:00 2001
>>> From: Anthony Liguori
>>> Date: Mon, 20 Sep 2010 15:29:31 -0500
>>> Subject: [PATCH] tap: make sure packets are at least 40 bytes long
>>>
>>> This is required by ethern
On Mon, Sep 20, 2010 at 03:31:32PM -0500, Anthony Liguori wrote:
> On 09/20/2010 05:42 AM, Michael S. Tsirkin wrote:
> >On Sun, Sep 19, 2010 at 07:36:51AM +0100, Stefan Hajnoczi wrote:
> >>On Sat, Sep 18, 2010 at 10:27 PM, Edgar E. Iglesias
> >> wrote:
> >>>This doesn't look right. AFAIK, MAC's do
On Mon, Sep 20, 2010 at 03:31:32PM -0500, Anthony Liguori wrote:
> On 09/20/2010 05:42 AM, Michael S. Tsirkin wrote:
> > On Sun, Sep 19, 2010 at 07:36:51AM +0100, Stefan Hajnoczi wrote:
> >
> >> On Sat, Sep 18, 2010 at 10:27 PM, Edgar E. Iglesias
> >> wrote:
> >>
> >>> This doesn't look
On 09/20/2010 05:42 AM, Michael S. Tsirkin wrote:
On Sun, Sep 19, 2010 at 07:36:51AM +0100, Stefan Hajnoczi wrote:
On Sat, Sep 18, 2010 at 10:27 PM, Edgar E. Iglesias
wrote:
This doesn't look right. AFAIK, MAC's dont pad on receive.
I agree. NICs that do padding will do it
On Sun, Sep 19, 2010 at 07:36:51AM +0100, Stefan Hajnoczi wrote:
> On Sat, Sep 18, 2010 at 10:27 PM, Edgar E. Iglesias
> wrote:
> > This doesn't look right. AFAIK, MAC's dont pad on receive.
>
> I agree. NICs that do padding will do it on transmit, not receive.
> Anything coming in on the wire s
On Mon, Sep 20, 2010 at 11:03:37AM +0200, Edgar E. Iglesias wrote:
> On Mon, Sep 20, 2010 at 10:50:40AM +0200, Kevin Wolf wrote:
> > Am 19.09.2010 08:36, schrieb Stefan Hajnoczi:
> > > On Sat, Sep 18, 2010 at 10:27 PM, Edgar E. Iglesias
> > > wrote:
> > >> This doesn't look right. AFAIK, MAC's don
On Mon, Sep 20, 2010 at 10:50:40AM +0200, Kevin Wolf wrote:
> Am 19.09.2010 08:36, schrieb Stefan Hajnoczi:
> > On Sat, Sep 18, 2010 at 10:27 PM, Edgar E. Iglesias
> > wrote:
> >> This doesn't look right. AFAIK, MAC's dont pad on receive.
> >
> > I agree. NICs that do padding will do it on trans
On Mon, Sep 20, 2010 at 10:42:31AM +0200, Kevin Wolf wrote:
> Am 18.09.2010 23:12, schrieb Stefan Hajnoczi:
> > On Sat, Sep 18, 2010 at 9:57 PM, Hervé Poussineau
> > wrote:
> >> Another patch creating ARP replies at least 64 bytes long has been
> >> committed:
> >> http://git.savannah.gnu.org/cgi
On Mon, Sep 20, 2010 at 10:42:31AM +0200, Kevin Wolf wrote:
> Am 18.09.2010 23:12, schrieb Stefan Hajnoczi:
> > On Sat, Sep 18, 2010 at 9:57 PM, Hervé Poussineau
> > wrote:
> >> Another patch creating ARP replies at least 64 bytes long has been
> >> committed:
> >> http://git.savannah.gnu.org/cgi
Am 19.09.2010 08:36, schrieb Stefan Hajnoczi:
> On Sat, Sep 18, 2010 at 10:27 PM, Edgar E. Iglesias
> wrote:
>> This doesn't look right. AFAIK, MAC's dont pad on receive.
>
> I agree. NICs that do padding will do it on transmit, not receive.
> Anything coming in on the wire should already have t
Am 18.09.2010 23:12, schrieb Stefan Hajnoczi:
> On Sat, Sep 18, 2010 at 9:57 PM, Hervé Poussineau
> wrote:
>> Another patch creating ARP replies at least 64 bytes long has been
>> committed:
>> http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=dbf3c4b4baceb91eb64d09f787cbe92d65188813
>>
>> Doe
On Sun, Sep 19, 2010 at 02:04:55PM +0200, Edgar E. Iglesias wrote:
> On Sun, Sep 19, 2010 at 01:18:01PM +0200, Michael S. Tsirkin wrote:
> > On Sun, Sep 19, 2010 at 07:36:51AM +0100, Stefan Hajnoczi wrote:
> > > On Sat, Sep 18, 2010 at 10:27 PM, Edgar E. Iglesias
> > > wrote:
> > > > This doesn't
On Sun, Sep 19, 2010 at 01:18:01PM +0200, Michael S. Tsirkin wrote:
> On Sun, Sep 19, 2010 at 07:36:51AM +0100, Stefan Hajnoczi wrote:
> > On Sat, Sep 18, 2010 at 10:27 PM, Edgar E. Iglesias
> > wrote:
> > > This doesn't look right. AFAIK, MAC's dont pad on receive.
> >
> > I agree. NICs that do
On Sun, Sep 19, 2010 at 07:36:51AM +0100, Stefan Hajnoczi wrote:
> On Sat, Sep 18, 2010 at 10:27 PM, Edgar E. Iglesias
> wrote:
> > This doesn't look right. AFAIK, MAC's dont pad on receive.
>
> I agree. NICs that do padding will do it on transmit, not receive.
> Anything coming in on the wire s
On Sat, Sep 18, 2010 at 10:27 PM, Edgar E. Iglesias
wrote:
> This doesn't look right. AFAIK, MAC's dont pad on receive.
I agree. NICs that do padding will do it on transmit, not receive.
Anything coming in on the wire should already have the minimum length.
In QEMU that isn't true today and tha
On Sat, Sep 18, 2010 at 09:43:45PM +0100, Stefan Hajnoczi wrote:
> The OpenIndiana (Solaris) e1000g driver drops frames that are too long
> or too short. It expects to receive frames of at least the Ethernet
> minimum size. ARP requests in particular are small and will be dropped
> if they are no
On Sat, Sep 18, 2010 at 9:57 PM, Hervé Poussineau wrote:
> Another patch creating ARP replies at least 64 bytes long has been
> committed:
> http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=dbf3c4b4baceb91eb64d09f787cbe92d65188813
>
> Does it fix your issue?
No I don't think so. This is an e
Hi,
Stefan Hajnoczi a écrit :
The OpenIndiana (Solaris) e1000g driver drops frames that are too long
or too short. It expects to receive frames of at least the Ethernet
minimum size. ARP requests in particular are small and will be dropped
if they are not padded appropriately, preventing a Sol
The OpenIndiana (Solaris) e1000g driver drops frames that are too long
or too short. It expects to receive frames of at least the Ethernet
minimum size. ARP requests in particular are small and will be dropped
if they are not padded appropriately, preventing a Solaris VM from
becoming visible on
25 matches
Mail list logo
