> > bce(4) is broken in stable, your best option is to revert to the
> > driver in releng 7.1.
>
> Is anybody working on fixing bce(4) in stable? As far as
> I can see in the repository, nothing happened recently.
> The last commit in releng 7 was in December last year.
I am slightly surprised
warhol-00.cs.huji.ac.il amd[715]: Unknown $ sequence in
> > "rhost:=${RHOST};type:=nfsl;fs:=${FS};rfs:=$huldig#^ZM-^KoM- abase"
> > Feb 6 19:00:00 warhol-00.cs.huji.ac.il kernel: impossible packet length
> > (2068989523) from nfs server sunfire:/dist
> >
>
> On Sun, 8 Feb 2009, Danny Braniss wrote:
>
> >> On Sun, 8 Feb 2009, Danny Braniss wrote:
> >>
> >>> looking at the bce source, it's not clear (to me :-). If errors are
> >>> detected in bce_rx_intr(), the packet gets dropped, which I would expect
> >>> to be the treatment of an offloded che
: discard
frame w/o=20
leading ethernet header (len 0 pkt len 0)
=2E..
Feb 6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: Unknown $
sequence in=20
"rhost:=3D${RHOST};type:=3Dnfsl;fs:=3D${FS};rfs:=3D$huldig#^ZM-
^KoM- a=
base"
Feb 6 19:00:00 warhol-00.cs.huji.ac.il kernel: impossi
On Sun, 8 Feb 2009, Danny Braniss wrote:
On Sun, 8 Feb 2009, Danny Braniss wrote:
looking at the bce source, it's not clear (to me :-). If errors are
detected in bce_rx_intr(), the packet gets dropped, which I would expect
to be the treatment of an offloded chekcum error, but it seems that i
>
> On Sun, 8 Feb 2009, Danny Braniss wrote:
>
> > looking at the bce source, it's not clear (to me :-). If errors are
> > detected
> > in bce_rx_intr(), the packet gets dropped, which I would expect to be the
> > treatment of an offloded chekcum error, but it seems that is not the case.
>
>
fsl;fs:=${FS};rfs:=$huldig#^ZM-^KoM- abase"
>Feb 6 19:00:00 warhol-00.cs.huji.ac.il kernel: impossible packet length
>(2068989523) from nfs server sunfire:/dist
>
>which seems to point fingers at bce...
It does rather suggest that bce is not behaving. What happens if you
turn off check
On Sun, 8 Feb 2009, Danny Braniss wrote:
looking at the bce source, it's not clear (to me :-). If errors are detected
in bce_rx_intr(), the packet gets dropped, which I would expect to be the
treatment of an offloded chekcum error, but it seems that is not the case.
I think we're thinking of
> On Sun, 8 Feb 2009, Peter Jeremy wrote:
>
> > On 2009-Feb-08 11:31:45 +0200, Danny Braniss wrote:
> >> Q: with rxcsum on, and a bad checksum packet is received, is it
> >> dropped by the NIC? if not, then it somewhat explains the behaviour
> >
> > If checksum offloading is working correctly t
On Sun, 8 Feb 2009, Peter Jeremy wrote:
On 2009-Feb-08 11:31:45 +0200, Danny Braniss wrote:
Q: with rxcsum on, and a bad checksum packet is received, is it
dropped by the NIC? if not, then it somewhat explains the behaviour
If checksum offloading is working correctly then a bad packet shou
On Sun, Feb 08, 2009 at 10:45:13AM +0200, Danny Braniss wrote:
> I'm reposting this to hackers, and there is some more info.
>
> > Hi,
> > on 2 different servers, running 7.1-stable + zfs, I get this
> > error rather frequently:
> >
> > Feb 5 17:01:03 w
On 2009-Feb-08 11:31:45 +0200, Danny Braniss wrote:
>Q: with rxcsum on, and a bad checksum packet is received, is it
> dropped by the NIC? if not, then it somewhat explains the behaviour
If checksum offloading is working correctly then a bad packet should
be dropped by the NIC. If checksum off
ard frame w/o=20
> >leading ethernet header (len 0 pkt len 0)
> =2E..
> >Feb 6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: Unknown $ sequence in=20
> >"rhost:=3D${RHOST};type:=3Dnfsl;fs:=3D${FS};rfs:=3D$huldig#^ZM-^KoM- a=
> base"
> >Feb 6 19:00:00 warhol-00.cs.huji
I'm reposting this to hackers, and there is some more info.
> Hi,
> on 2 different servers, running 7.1-stable + zfs, I get this
> error rather frequently:
>
> Feb 5 17:01:03 warhol-00 kernel: impossible packet length (543383918) from
> nfs server sunfire:/dist
>
> On 2009-Feb-06 08:32:27 +0200, Danny Braniss wrote:
> >on 2 different servers, running 7.1-stable + zfs, I get this
> >error rather frequently:
> >
> >Feb 5 17:01:03 warhol-00 kernel: impossible packet length (543383918) fro=
> m=20
> >nfs server sunfire
On 2009-Feb-06 08:32:27 +0200, Danny Braniss wrote:
>on 2 different servers, running 7.1-stable + zfs, I get this
>error rather frequently:
>
>Feb 5 17:01:03 warhol-00 kernel: impossible packet length (543383918) from
>nfs server sunfire:/dist
I gather warhol-00 is running
Hi,
on 2 different servers, running 7.1-stable + zfs, I get this
error rather frequently:
Feb 5 17:01:03 warhol-00 kernel: impossible packet length (543383918) from
nfs server sunfire:/dist
Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1936028704) from
nfs server sunfire:/dist
17 matches
Mail list logo
