Hi Stephen, From the ereports, it seems that the device got hang and was reset by the driver automatically. From snv_77, the e1000g driver started to support FMA, so we see the FMA ereports now. The problem might have existed in snv_75.
We have not seen this problem before. The recent bug fixes in snv_95 have nothing to do with this problem. I need to try to reproduce the problem on our local systems. Could you please let me know what applications or tests you have been running on your system? Thanks, Ted Stephen Lau : > I'm seeing flaky outages on my snv_95 system (just recently LU'd from snv_75 > where I didn't have any issues). > > I seem to get outages of a few minutes (5-6) throughout the day, with no > rhyme or reason as to why. > > fmdump -e shows repeated occurrences of: > Aug 18 12:24:57.2612 ereport.io.device.stall > Aug 18 12:24:57.5985 ereport.io.service.restored > > /usr/X11/bin/scanpci shows my e1000g devices to be: > pci bus 0x000d cardnum 0x00 function 0x00: vendor 0x8086 device 0x108c > Intel Corporation 82573E Gigabit Ethernet Controller (Copper) > > pci bus 0x000e cardnum 0x00 function 0x00: vendor 0x8086 device 0x109a > Intel Corporation 82573L Gigabit Ethernet Controller > >>From my reading it looks like there were 1 or 2 e1000g issues that were >>purportedly fixed in snv_95, but I'm still seeing these problems. Anyone >>have any idea as to what might be the issue, and whether or not there is a >>workaround? I'm debating about pulling back the e1000g driver from my snv_75 >>LU slice and seeing if that works, but I'm hoping someone has a workaround >>for now. :) > > > This message posted from opensolaris.org > _______________________________________________ > networking-discuss mailing list > [email protected] _______________________________________________ networking-discuss mailing list [email protected]
