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