[9fans] VIA VT8122 (ethervgbe), 256 packets, and further no PHY
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
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.
Re: [9fans] VIA VT8122 (ethervgbe), 256 packets, and further no PHY
That's the wrong fix; ethernet drivers should always call etheriq(edev, block, 1); The sole exception is in devether.c. ---BeginMessage--- 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. ---End Message---
