Marvell Yukon 88E8062 - media selection problem

Pyun YongHyeon pyunyh at gmail.com
Tue Jul 8 06:26:55 UTC 2008


On Mon, Jul 07, 2008 at 08:43:59PM +0200, Krzysztof J??druczyk wrote:
 > Pyun YongHyeon wrote:
 > >Since the patch had lots of code not related with 88E8062 dual port
 > >controller, would you try attached patch again? I think the attached
 > >patch is minimal one that makes 88E8062 work.
 > >
 > >The patch also try to enable MSI for dual port controllers. At the 
 > >time of writing support for MSI I had no testers to experiment MSI so
 > >MSI on dual port controllers were ignored. Please see if msk(4) take
 > >advantage of MSI. irq256 or higher number would be showed in "vmstat
 > >-i" output if MSI is active.
 > >
 > # vmstat -i
 > interrupt                          total       rate
 > irq14: ata0                         1450          1
 > irq16: fxp0 uhci0                   2058          1
 > cpu0: timer                      2705189       1999
 > irq256: mskc0                         92          0
 > cpu1: timer                      2704883       1999
 > Total                            5413672       4001
 > 
 > I guess MSI is enabled.
 > 

That's great!

 > As of the results of tests I'm not sure what to start with... Initially 
 > both interfaces seemed non-functional with nothing getting transmitted 
 > to other machine. Then I noticed that it seems that msk1 seemed to 
 > receive packets that should be on msk0 (?):
 > 
 > ># tcpdump -i msk1
 > >tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
 > >listening on msk1, link-type EN10MB (Ethernet), capture size 96 bytes
 > >20:28:41.757722 arp who-has 192.168.0.1 tell 192.168.0.2
 > 
 > 192.168.0.2 is on em0 on other machine, and should be on the same switch
 > as msk0. At least this was the case on previous tests in which both 
 > interfaces worked...
 > 
 > Another time on the same test corrupted data was received:
 > 
 > >tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
 > >listening on msk1, link-type EN10MB (Ethernet), capture size 96 bytes
 > >20:31:29.806041 d3:04:ff:ff:ff:ff (oui Unknown) > 22:a0:00:00:02:f0 (oui 
 > >Unknown), ethertype Unknown (0x3cc0), length 60:
 > >        0x0000:  de07 0000 0000 0000 0000 0000 0000 0000  ................
 > >        0x0010:  0000 ffff ffff ffff 0002 0406 0800 0806  ................
 > >        0x0020:  0001 0800 0604 0001 0002 0406 0800       ..............
 > 
 > And later magically the msk1 <-> em0 link started working... Seems to 
 > work just fine after reboot (I didn't try to power down machine, just 
 > shutdown -r).
 > 
 > So to sum up - in the end mks1 interface worked in some weird way - but 
 > it seemed to represent the link that was under msk0 previously.

It may still have some odd cases for dual port controllers. I guess
the reset sequence of the controller is important as status LEs are
shared between ports. The patch you tried in previous patch(
msk.88E8040.patch5) has a couple of fixes which might also help to
stability under certain conditions. Orignally msk.88E8040.patch5
was generated for 88E8040 fast ethernet controller but it miserably
failed to support the controller so I had to think harder to make
it work. :-(

Anyway I'll commit the minimal patch in a couple of days as it
seems that it wouldn't affect other Yukon II controllers. 

Thanks a lot for your time and testing!
-- 
Regards,
Pyun YongHyeon


More information about the freebsd-stable mailing list