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...@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. > >
