[9fans] VIA VT8122 (ethervgbe), 256 packets, and further no PHY

[9fans] VIA VT8122 (ethervgbe), 256 packets, and further no PHY

[Tristan Plumb]

Is anybody else currently using the ethervgbe driver? I'm had some
problems with it which don't seem to be caused by my hardware.

After receiving 256 packets I was getting:
panic: freeb: ref -1; caller pc 0xf01b1754
panic: freeb: ref -1; caller pc 0xf01b1754

Turns out calling freeb was messing things up (so the second time through
the block list the data went to bung blocks) and the workaround simple:

537c537
<			etheriq(edev, block, 1);
---
>			etheriq(edev, block, 0);

Now, those of you who know more about this than I, are there any
side-effects of that? It seems to be working now... I also discovered
(from the chipset manual) that the RX ring is apparently limited to 252
entries, but I'vn't made sure those 4 packets were indeed being dropped.

I came across the missing PHY message in 9fans, and just wanted to put
out there that I've only had the problem in the transition from Linux to
Plan 9 (like when I was fetching docs for it), at which point removing
power from the computer before booting fixed it.

enjoy,
tristan

--
All original matter is hereby placed immediately under the public domain.

Re: [9fans] VIA VT8122 (ethervgbe), 256 packets, and further no PHY

[Noah Evans]

I had the same problem and came to the same (kludgey) solution. The
ethervgbe driver is still a bit of a work in progress. Other ethernet
drivers use the same trick, a pool of Blocks that are never freed, but
they use _xincref inside the driver proper to make sure etheriq(...,
1) doesn't cause a reference counting panic. That doesn't work in the
vgbe driver for reasons I didn't have the time to explore.

On the subject, if anybody's interested in pxe booting off a card
supported by the ethervgbe driver, I have a preliminary 9load driver
that you can use/debug.

On Fri, Jan 22, 2010 at 11:33 AM, Tristan Plumb <9p-st@imu.li> wrote:
> Is anybody else currently using the ethervgbe driver? I'm had some
> problems with it which don't seem to be caused by my hardware.
>
> After receiving 256 packets I was getting:
> panic: freeb: ref -1; caller pc 0xf01b1754
> panic: freeb: ref -1; caller pc 0xf01b1754
>
> Turns out calling freeb was messing things up (so the second time through
> the block list the data went to bung blocks) and the workaround simple:
>
> 537c537
> <                       etheriq(edev, block, 1);
> ---
>>                       etheriq(edev, block, 0);
>
> Now, those of you who know more about this than I, are there any
> side-effects of that? It seems to be working now... I also discovered
> (from the chipset manual) that the RX ring is apparently limited to 252
> entries, but I'vn't made sure those 4 packets were indeed being dropped.
>
> I came across the missing PHY message in 9fans, and just wanted to put
> out there that I've only had the problem in the transition from Linux to
> Plan 9 (like when I was fetching docs for it), at which point removing
> power from the computer before booting fixed it.
>
> enjoy,
> tristan
>
> --
> All original matter is hereby placed immediately under the public domain.
>
>

Re: [9fans] VIA VT8122 (ethervgbe), 256 packets, and further no PHY

[geoff]

[-- Attachment #1: Type: text/plain, Size: 130 bytes --]

That's the wrong fix; ethernet drivers should always call

			etheriq(edev, block, 1);

The sole exception is in devether.c.

[-- Attachment #2: Type: message/rfc822, Size: 2784 bytes --]

From: Tristan Plumb <9p-st@imu.li>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: [9fans] VIA VT8122 (ethervgbe), 256 packets, and further no PHY
Date: Fri, 22 Jan 2010 05:33:01 -0500
Message-ID: <2576b2.e56dbf64.WiyS.mx@tumtum.plumbweb.net>

Is anybody else currently using the ethervgbe driver? I'm had some
problems with it which don't seem to be caused by my hardware.

After receiving 256 packets I was getting:
panic: freeb: ref -1; caller pc 0xf01b1754
panic: freeb: ref -1; caller pc 0xf01b1754

Turns out calling freeb was messing things up (so the second time through
the block list the data went to bung blocks) and the workaround simple:

537c537
<			etheriq(edev, block, 1);
---
>			etheriq(edev, block, 0);

Now, those of you who know more about this than I, are there any
side-effects of that? It seems to be working now... I also discovered
(from the chipset manual) that the RX ring is apparently limited to 252
entries, but I'vn't made sure those 4 packets were indeed being dropped.

I came across the missing PHY message in 9fans, and just wanted to put
out there that I've only had the problem in the transition from Linux to
Plan 9 (like when I was fetching docs for it), at which point removing
power from the computer before booting fixed it.

enjoy,
tristan

--
All original matter is hereby placed immediately under the public domain.