Hi Matty,

Could you tell me what is the type of your chipset? You can check it like this:
[r...@silverdollar]~# kstat -m bge | grep type
       bus_type                        PCI-X
       chip_type                       5715
       bus_type                        PCI-X
       chip_type                       5715
[r...@silverdollar]~# kstat -m bge | grep -i asic
       asic_rev                        2416115712
       asic_rev                        2416115712

If you can send me the output of "kstat -m bge", that's much better.

Thanks,
Carson


------------------------------------------------------------------------

Subject:
Re: [networking-discuss] dladm bug?
From:
Peter Memishian <[email protected]>
Date:
Sat, 30 May 2009 11:38:58 -0700
To:
Matty <[email protected]>

To:
Matty <[email protected]>
CC:
networking-discuss <[email protected]>


 > I was monitoring bytes in/out on one of my Nevada build 110 hosts, and
 > noticed a number of samples similar to this:
> > bash-3.2# dladm show-link bge0 -s -i 1
 >  .......
 > bge0            54685      83001694 0          9177         655350       0
 > bge0            53692      81484360 0          9004         644020       0
 > bge0            52153      79153774 0          8741         623334       0
 > bge0            47985      18446744069487416862 0 8058      576704       0
 > bge0            54690      83015076 0          9174         654468       0
> > Is this a known issue? I didn't see a bug related to this in bugster,
 > so I thought I would ask here.

The RBYTES counter often comes directly from networking hardware, so I'd
suspect that either the hardware provided a bad value or the value was
being changed while it was being read by the driver.  It might be worth
DTracing bge_m_stat() to see (a) whether the statistics_type is
BGE_STAT_BLK and (b) what the *val ends up being for MAC_STAT_RBYTES.  As
an aside, the driver has a comment stating:

        /*
         * Transfer the statistics values from the copy that the
         * chip updates via DMA to the named-kstat structure.
         *
         * As above, we don't bother to sync or stop updates to the
         * statistics, 'cos it doesn't really matter if they're a few
         * microseconds out of date or less than 100% consistent ...
         */

Perhaps not syncing/stopping has a more pathological effect than just
being a little out-of-date.  Or perhaps this a bug somewhere else ...



--
Thanks and Regards,
Carson (Yong Tan)
Sun Microsystems China (ERI)
Email: [email protected]
Tel : (86-10)6267-3681 (x51681)
_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to