Ben Greear wrote: Jeff Garzik wrote: Jon Mason wrote: I think I've found a (very hackish) way around the bad stats error. Tested on amd64, and "solves" the problem. Seems to me, we should instead fi
Hi Francois and Jon! Please find attached a patch that adds the hardware statistics ethtool operations to the r8169 driver. It's against 2.6.11-rc5. Signed-Off-By: Richard Dawe <rich@xxxxxxxxxxxxxxxx
Richard Dawe wrote: Hi Francois and Jon! Please find attached a patch that adds the hardware statistics ethtool operations to the r8169 driver. It's against 2.6.11-rc5. Signed-Off-By: Richard Dawe <r
Good Work! I'll give it a try here in a little bit. [...] Can you confirm that the registers are outputting these bogus values? See comments below. <paste from attachment> -- linux-2.6.11-rc5/drivers
Jon Mason wrote: On Saturday 26 February 2005 08:53 am, Richard Dawe wrote: Hi Francois and Jon! Please find attached a patch that adds the hardware statistics ethtool operations to the r8169 driver.
Jeff Garzik <jgarzik@xxxxxxxxx> : [...] Btw I'd simply remove the 'work' variable and schedule in an interruptible way until the dump is done. BUG() is a bit exagerated imho. -- Ueimor
Richard Dawe <rich@xxxxxxxxxxxxxxxxxxxx> : You don't want to free it it was not allocated. Please undo the previous step (init_ring probably) and: 1) use the form "goto err_descriptive_name_for_the_r
My suggestion was based on code uniformity (as the rest of the values are defined as dex or decimal numbers). Which takes presidense, uniformity or readablity? If it is the latter, should the rest of
I tested it on my amd64 system and it works great. I saw the same error if stats were gathered with the interface was down. As a sanity check, I preformed the same test on e1000 and it does not have
Thanks for reviewing, Francois, Jon & Jeff! Francois Romieu wrote: [snip] Btw I'd simply remove the 'work' variable and schedule in an interruptible way until the dump is done. OK, that will take me
Richard Dawe wrote: BUG() is a bit exagerated imho. It seems like a pretty good way of avoiding a buffer overrun to me. E.g.: you copy an extra statistic in rtl8169_get_ethtool_stats(), but forget to
I think I've found a (very hackish) way around the bad stats error. Tested on amd64, and "solves" the problem. -- drivers/net/r8169.c 2005-02-27 20:27:48.000000000 -0600 +++ drivers/net/r8169.c.new 2
Jon Mason wrote: I think I've found a (very hackish) way around the bad stats error. Tested on amd64, and "solves" the problem. Seems to me, we should instead find a way to avoid calling the stats fu
Jeff Garzik wrote: Jon Mason wrote: I think I've found a (very hackish) way around the bad stats error. Tested on amd64, and "solves" the problem. Seems to me, we should instead find a way to avoid c
Hello. I think I've found a (very hackish) way around the bad stats error. Tested on amd64, and "solves" the problem. Seems to me, we should instead find a way to avoid calling the stats function if
Hi Francois and Jon! Please find attached a patch that adds the hardware statistics ethtool operations to the r8169 driver. It's against 2.6.11-rc5. Signed-Off-By: Richard Dawe <rich@xxxxxxxxxxxxxxxx
Please find attached a patch that adds the hardware statistics ethtool operations to the r8169 driver. It's against 2.6.11-rc5. Signed-Off-By: Richard Dawe <rich@xxxxxxxxxxxxxxxxxxxx> Basically it's