Re: Watchdog resets on 82575

On Tue, Aug 10, 2010 at 03:57:22AM -0700, Jeremy Chadwick wrote:
> On Tue, Aug 10, 2010 at 11:23:26AM +0100, Steven Hartland wrote:
> > Thanks Jeremy, from that we get:-
> > 
> > igb0_at_pci0:1:0:0:        class=0x020000 card=0x060015d9 chip=0x10c98086 rev=0x01 hdr=0x00
> >    vendor     = 'Intel Corporation'
> >    class      = network
> >    subclass   = ethernet
> >    cap 01[40] = powerspec 3  supports D0 D3  current D0
> >    cap 05[50] = MSI supports 1 message, 64 bit, vector masks
> >    cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled
> >    cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x4(x4)
> > igb1_at_pci0:1:0:1:        class=0x020000 card=0x060015d9 chip=0x10c98086 rev=0x01 hdr=0x00
> >    vendor     = 'Intel Corporation'
> >    class      = network
> >    subclass   = ethernet
> >    cap 01[40] = powerspec 3  supports D0 D3  current D0
> >    cap 05[50] = MSI supports 1 message, 64 bit, vector masks
> >    cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled
> >    cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x4(x4)
> > 
> > I assume there is a way to convert from the hex values to the human value
> > but not sure what it is?
> 
> The "card" and "chip" identifiers are part of the PCI ID specification.
> You can see what the "human value" is by examining the source code for
> the driver.  Sometimes it's easy to figure out, other times there's a
> series of #define's which you have to reverse engineer.
> 
> In this case, there's two places with relevant information:
> 
> src/sys/dev/e1000/if_igb.c
> src/sys/dev/e1000/e1000_hw.h
> 
> You have to split the Chip ID into two separate 16-bit portions, so
> 0x10c9 and 0x8086.
> 
> 0x8086 is Intel's vendor code.  0x10c9 is the device ID of the
> individual NIC/model type.  So:
> 
> $ grep -i 0x10c9 *
> e1000_hw.h:#define E1000_DEV_ID_82576                    0x10C9
> 
> For Jack: igb_vendor_info_array should really be extended to include
> actual ASCII strings for the individual chips/models/codenames.  I'm
> sure that's on your todo list somewhere.  I'd be willing to write this
> but would need a list of the models (or maybe the Linux driver has them
> in comments, etc. and I could go off of that).
> 

I guess em(4)/igb(4)/ixgb(4)/ixgbe(4) only shows vendor string and
driver version which effectively hides controller name/model
details in device attach phase. Personally I like to see more
detailed controller model information which may help narrowing down
affected lits of controllers when an issue is reported.
Currently we have to get this information by requesting the output
of pciconf(4) which in turn requires one more round trip of mail.