freebsd-usb Digest, Vol 281, Issue 2
freebsd-u...@freebsd.org
freeb...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
or, via email, send a message with subject or body 'help' to
freebsd-u...@freebsd.org
You can reach the person managing the list at
freebsd-...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-usb digest..."
Today's Topics:
1. uslcom drops chars(?) when used with hub (Steve Franks)
2. Re: uslcom drops chars(?) when used with hub (Hans Petter Selasky)
3. Re: 10Mbps+ throughput usb based ethernet recommendation
(Pyun YongHyeon)
4. Re: 10Mbps+ throughput usb based ethernet recommendation
(Nenhum_de_Nos)
5. Re: 10Mbps+ throughput usb based ethernet recommendation
(Pyun YongHyeon)
6. Re: 10Mbps+ throughput usb based ethernet recommendation
(Pyun YongHyeon)
7. Re: 10Mbps+ throughput usb based ethernet recommendation
(Pyun YongHyeon)
8. Re: usb/128803: [usbdevs] [patch] Quirk for I-Tuner Networks
USBLCD4X20 support (Andre Guibert de Bruet)
9. Re: 10Mbps+ throughput usb based ethernet recommendation
(Nenhum_de_Nos)
10. Re: 10Mbps+ throughput usb based ethernet recommendation
(Pyun YongHyeon)
11. Re: 10Mbps+ throughput usb based ethernet recommendation
(Nenhum_de_Nos)
12. Re: 10Mbps+ throughput usb based ethernet recommendation
(Pyun YongHyeon)
13. Re: 10Mbps+ throughput usb based ethernet recommendation
(Nenhum_de_Nos)
14. resetting USB after suspend (Nicholas 0)
15. Re: resetting USB after suspend (Hans Petter Selasky)
16. Re: uslcom drops chars(?) when used with hub (Steve Franks)
17. Re: uslcom drops chars(?) when used with hub (Hans Petter Selasky)
18. Re: 10Mbps+ throughput usb based ethernet recommendation
(Pyun YongHyeon)
19. Re: uslcom drops chars(?) when used with hub (Steve Franks)
----------------------------------------------------------------------
Message: 1
Date: Tue, 23 Mar 2010 11:44:55 -0700
From: Steve Franks <bahama...@gmail.com>
Subject: uslcom drops chars(?) when used with hub
To: freebsd-usb <freeb...@freebsd.org>
Message-ID:
<539c60b91003231144n37c...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
After my last 8-stable buildworld, I can't upgrade firmware on uslcom
devices plugged into a hub. I can still talk to them over a terminal,
but it seems anything that slams bits at them 'fast' dies an early
death. Works fine in motherboard usb slot, however. Also, had
identical hub that's rarely ever used, which has same behavior, so all
things point to an OS/quirks type issue.
How do I even begin debugging this? This is a major problem for my
day to day workflow. I do *a lot* of firmware upgrades.
Steve
------------------------------
Message: 2
Date: Tue, 23 Mar 2010 21:57:30 +0100
From: Hans Petter Selasky <hsel...@c2i.net>
Subject: Re: uslcom drops chars(?) when used with hub
To: freeb...@freebsd.org
Message-ID: <201003232157....@c2i.net>
Content-Type: Text/Plain; charset="iso-8859-1"
On Tuesday 23 March 2010 19:44:55 Steve Franks wrote:
> After my last 8-stable buildworld, I can't upgrade firmware on uslcom
> devices plugged into a hub. I can still talk to them over a terminal,
> but it seems anything that slams bits at them 'fast' dies an early
> death. Works fine in motherboard usb slot, however. Also, had
> identical hub that's rarely ever used, which has same behavior, so all
> things point to an OS/quirks type issue.
>
> How do I even begin debugging this? This is a major problem for my
> day to day workflow. I do *a lot* of firmware upgrades.
Hi,
You can try:
sysctl hw.usb.uslcom.debug=15
What does usbconfig say about your device when you use the HUB and without
HUB?
Also check the version history for /sys/dev/usb/serial/uslcom.c at
freebsd.org.
--HPS
------------------------------
Message: 3
Date: Tue, 23 Mar 2010 18:01:07 -0700
From: Pyun YongHyeon <pyu...@gmail.com>
Subject: Re: 10Mbps+ throughput usb based ethernet recommendation
To: Nenhum_de_Nos <mat...@eternamente.info>
Cc: freeb...@freebsd.org
Message-ID: <2010032401...@michelle.cdnetworks.com>
Content-Type: text/plain; charset=us-ascii
On Tue, Mar 23, 2010 at 12:13:26AM -0300, Nenhum_de_Nos wrote:
>
> On Mon, March 22, 2010 23:29, Nenhum_de_Nos wrote:
> >
> >
> > On Mon, March 1, 2010 16:10, Pyun YongHyeon wrote:
> >> On Mon, Mar 01, 2010 at 03:57:02PM -0300, Nenhum_de_Nos wrote:
> >>> hail,
> >>>
> >>> I need an usb nic that is able to push more then 10Mbps on wire. if is
> > altq capable better.
> >>>
> >>
> >> AFAIK all USB ethernet drivers support altq(4).
> >>
> >>> I use pfsense as router, but my next upgrade will use 10Mbps link and
> > my aue and rue nic's can't pass the 5Mbps barrier. I need to use three
> > to make 11Mbps on it, and its not a good thing for me in production.
> >>>
> >>> I've seen some axe based on its manual page, but I'm afraid to buy and
> >>> it
> >>> won't solve my problem. if anyone has any leads/experience on this
> >>> please
> >>> broadcast :)
> >>>
> >>
> >> Last time I tried AX88178 based axe(4) controller, I can push more than
> > 200Mbps. Related change already MFCed to stable/8.
> >
> > well, I did that but using that chip on windows :(
> >
> > I got two nics based on these chips but they are unstable as hell in
> > FreeBSD. on pfSense (FreeBSD 7.1 and 7.2 versions) I never got the axe0
> > media to be active. on 8-stable (this box), one got issues with media link
> > and the other can set link state ok, but looses 10% of ping packets. iperf
> > gets cut every now and then and this makes the throughput suffer :(
> >
> > I plan to use pfSense 1.2.3 (7.2 based) and when available pfSense 2.0
> > (8.0 based).
> >
> > are there any patches to try ? it is really unstable here ...
> >
> > some logs:
> >
> > Client connecting to 192.168.1.2, TCP port 5001
> > TCP window size: 32.5 KByte (default)
> > ------------------------------------------------------------
> > [ 3] local 192.168.1.1 port 42556 connected with 192.168.1.2 port 5001
> > [ ID] Interval Transfer Bandwidth
> > [ 3] 0.0-32.7 sec 69.5 MBytes 17.8 Mbits/sec
> > [root@darkside ~]# iperf -c 192.168.1.2 -t 30
> > ------------------------------------------------------------
> > Client connecting to 192.168.1.2, TCP port 5001
> > TCP window size: 32.5 KByte (default)
> > ------------------------------------------------------------
> > [ 3] local 192.168.1.1 port 45725 connected with 192.168.1.2 port 5001
> > [ ID] Interval Transfer Bandwidth
> > [ 3] 0.0-30.6 sec 128 MBytes 35.1 Mbits/sec
> > [root@darkside ~]# iperf -c 192.168.1.2 -t 30
> > ------------------------------------------------------------
> > Client connecting to 192.168.1.2, TCP port 5001
> > TCP window size: 32.5 KByte (default)
> > ------------------------------------------------------------
> > [ 3] local 192.168.1.1 port 38546 connected with 192.168.1.2 port 5001
> > [ ID] Interval Transfer Bandwidth
> > [ 3] 0.0-31.0 sec 129 MBytes 35.0 Mbits/sec
> >
> > this is:
> >
> > FreeBSD xxx 8.0-STABLE FreeBSD 8.0-STABLE #7: Sun Mar 21 03:45:47 BRT 2010
> > root@xxx:/usr/obj/usr/src/sys/xxx amd64
> >
> > and on both ends there is a nic using this chip, here is this freebsd and
> > the other on windows xp.
> >
> > as said above, when run iperf on this nic on windows and my nfe gigabit I
> > got those 228Mbps said above.
> >
> > thanks,
> >
> > matheus
> >
> > --
> > We will call you cygnus,
> > The God of balance you shall be
> >
> > A: Because it messes up the order in which people normally read text. Q:
> > Why is top-posting such a bad thing?
> >
> > http://en.wikipedia.org/wiki/Posting_style
> >
> >
> >
> > --
> > We will call you cygnus,
> > The God of balance you shall be
> >
> > A: Because it messes up the order in which people normally read text.
> > Q: Why is top-posting such a bad thing?
> >
> > http://en.wikipedia.org/wiki/Posting_style
> > _______________________________________________
> > freeb...@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-usb
> > To unsubscribe, send any mail to "freebsd-usb...@freebsd.org"
> >
>
> Just adding info, I keep getting these outputs from ifconfig:
>
> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> ether 00:11:50:e7:39:e9
> inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
> media: Ethernet autoselect (1000baseT <full-duplex>)
> status: active
> and:
> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> ether 00:11:50:e7:39:e9
> inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
> media: Ethernet autoselect (100baseTX <full-duplex,hw-loopback>)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> status: active
>
> and this keeps repeating over and over. iperf and on the other end an
Maybe this is real problem. It seems PHY have trouble to establish
link. This is FreeBSD stable/8 right?
Would you show me the output of "devinfo -rv| grep phy"?
> intel gigabit pcie nic:
>
------------------------------
Message: 4
Date: Wed, 24 Mar 2010 18:16:21 -0300 (BRT)
From: "Nenhum_de_Nos" <mat...@eternamente.info>
Subject: Re: 10Mbps+ throughput usb based ethernet recommendation
To: pyu...@gmail.com
Cc: freeb...@freebsd.org
Message-ID:
<3e164e2fc77415a67bd7...@cygnus.homeunix.com>
Content-Type: text/plain;charset=iso-8859-1
On Tue, March 23, 2010 22:01, Pyun YongHyeon wrote:
> On Tue, Mar 23, 2010 at 12:13:26AM -0300, Nenhum_de_Nos wrote:
>>
>> On Mon, March 22, 2010 23:29, Nenhum_de_Nos wrote:
>> >
>> >
>> > On Mon, March 1, 2010 16:10, Pyun YongHyeon wrote:
>> >> On Mon, Mar 01, 2010 at 03:57:02PM -0300, Nenhum_de_Nos wrote:
>> >>> hail,
>> >>>
>> >>> I need an usb nic that is able to push more then 10Mbps on wire. if
>> is
>> > altq capable better.
>> >>>
>> >>
>> >> AFAIK all USB ethernet drivers support altq(4).
>> >>
>> >>> I use pfsense as router, but my next upgrade will use 10Mbps link
>> and
>> > my aue and rue nic's can't pass the 5Mbps barrier. I need to use three
>> > to make 11Mbps on it, and its not a good thing for me in production.
>> >>>
>> >>> I've seen some axe based on its manual page, but I'm afraid to buy
>> and
>> >>> it
>> >>> won't solve my problem. if anyone has any leads/experience on this
>> >>> please
>> >>> broadcast :)
>> >>>
>> >>
>> >> Last time I tried AX88178 based axe(4) controller, I can push more
>> than
>> > 200Mbps. Related change already MFCed to stable/8.
>> >
>> > well, I did that but using that chip on windows :(
>> >
>> > I got two nics based on these chips but they are unstable as hell in
>> > FreeBSD. on pfSense (FreeBSD 7.1 and 7.2 versions) I never got the
>> axe0
>> > media to be active. on 8-stable (this box), one got issues with media
>> link
>> > and the other can set link state ok, but looses 10% of ping packets.
>> iperf
>> > gets cut every now and then and this makes the throughput suffer :(
>> >
>> > I plan to use pfSense 1.2.3 (7.2 based) and when available pfSense 2.0
>> > (8.0 based).
>> >
>> > are there any patches to try ? it is really unstable here ...
>> >
>> > some logs:
>> >
>> > Client connecting to 192.168.1.2, TCP port 5001
>> > TCP window size: 32.5 KByte (default)
>> > ------------------------------------------------------------
>> > [ 3] local 192.168.1.1 port 42556 connected with 192.168.1.2 port
>> 5001
>> > [ ID] Interval Transfer Bandwidth
>> > [ 3] 0.0-32.7 sec 69.5 MBytes 17.8 Mbits/sec
>> > [root@darkside ~]# iperf -c 192.168.1.2 -t 30
>> > ------------------------------------------------------------
>> > Client connecting to 192.168.1.2, TCP port 5001
>> > TCP window size: 32.5 KByte (default)
>> > ------------------------------------------------------------
>> > [ 3] local 192.168.1.1 port 45725 connected with 192.168.1.2 port
>> 5001
>> > [ ID] Interval Transfer Bandwidth
>> > [ 3] 0.0-30.6 sec 128 MBytes 35.1 Mbits/sec
>> > [root@darkside ~]# iperf -c 192.168.1.2 -t 30
>> > ------------------------------------------------------------
>> > Client connecting to 192.168.1.2, TCP port 5001
>> > TCP window size: 32.5 KByte (default)
>> > ------------------------------------------------------------
>> > [ 3] local 192.168.1.1 port 38546 connected with 192.168.1.2 port
>> 5001
>> > [ ID] Interval Transfer Bandwidth
>> > [ 3] 0.0-31.0 sec 129 MBytes 35.0 Mbits/sec
>> >
>> > this is:
>> >
>> > FreeBSD xxx 8.0-STABLE FreeBSD 8.0-STABLE #7: Sun Mar 21 03:45:47 BRT
>> 2010
>> > root@xxx:/usr/obj/usr/src/sys/xxx amd64
>> >
>> > and on both ends there is a nic using this chip, here is this freebsd
>> and
>> > the other on windows xp.
>> >
>> > as said above, when run iperf on this nic on windows and my nfe
>> gigabit I
>> > got those 228Mbps said above.
>> >
>> > thanks,
>> >
>> > matheus
>> >
>> > --
>> > We will call you cygnus,
>> > The God of balance you shall be
>> >
>> > A: Because it messes up the order in which people normally read text.
>> Q:
>> > Why is top-posting such a bad thing?
>> >
>> > http://en.wikipedia.org/wiki/Posting_style
>> >
>> >
>> >
>> > --
>> > We will call you cygnus,
>> > The God of balance you shall be
>> >
>> > A: Because it messes up the order in which people normally read text.
>> > Q: Why is top-posting such a bad thing?
>> >
>> > http://en.wikipedia.org/wiki/Posting_style
>> > _______________________________________________
>> > freeb...@freebsd.org mailing list
>> > http://lists.freebsd.org/mailman/listinfo/freebsd-usb
>> > To unsubscribe, send any mail to "freebsd-usb...@freebsd.org"
>> >
>>
>> Just adding info, I keep getting these outputs from ifconfig:
>>
>> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
>> 1500
>> ether 00:11:50:e7:39:e9
>> inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
>> media: Ethernet autoselect (1000baseT <full-duplex>)
>> status: active
>> and:
>> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
>> 1500
>> ether 00:11:50:e7:39:e9
>> inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
>> media: Ethernet autoselect (100baseTX <full-duplex,hw-loopback>)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> status: active
>>
>> and this keeps repeating over and over. iperf and on the other end an
>
> Maybe this is real problem. It seems PHY have trouble to establish
> link. This is FreeBSD stable/8 right?
yes. on 7.2 is even worse :(
> Would you show me the output of "devinfo -rv| grep phy"?
/usr/home/matheus]$ devinfo -rv| grep phy
ukphy0 pnpinfo oui=0x1e model=0x14 rev=0x9 at phyno=1
I'm trying to test it on current, but I think it will be the same (I saw
cvs commits till releng 8 creating and all commits are the same ).
still looking for better performance usb nic :) you think the slower
linksys usb200m (axe based also) will have better luck in this link
negotiation issue ? (I don't need gigabit, just to break the 10Mbps at
start - though breaking the 50Mpbs would be perfert).
thanks,
matheus
>> intel gigabit pcie nic:
>>
>
--
We will call you cygnus,
The God of balance you shall be
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
http://en.wikipedia.org/wiki/Posting_style
------------------------------
Message: 5
Date: Wed, 24 Mar 2010 14:42:30 -0700
From: Pyun YongHyeon <pyu...@gmail.com>
Subject: Re: 10Mbps+ throughput usb based ethernet recommendation
To: Nenhum_de_Nos <mat...@eternamente.info>
Cc: freeb...@freebsd.org
Message-ID: <2010032421...@michelle.cdnetworks.com>
Content-Type: text/plain; charset=us-ascii
On Wed, Mar 24, 2010 at 06:16:21PM -0300, Nenhum_de_Nos wrote:
>
> On Tue, March 23, 2010 22:01, Pyun YongHyeon wrote:
[...]
> >> Just adding info, I keep getting these outputs from ifconfig:
> >>
> >> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
> >> 1500
> >> ether 00:11:50:e7:39:e9
> >> inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
> >> media: Ethernet autoselect (1000baseT <full-duplex>)
> >> status: active
> >> and:
> >> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
> >> 1500
> >> ether 00:11:50:e7:39:e9
> >> inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
> >> media: Ethernet autoselect (100baseTX <full-duplex,hw-loopback>)
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> status: active
> >>
> >> and this keeps repeating over and over. iperf and on the other end an
> >
> > Maybe this is real problem. It seems PHY have trouble to establish
> > link. This is FreeBSD stable/8 right?
>
> yes. on 7.2 is even worse :(
>
> > Would you show me the output of "devinfo -rv| grep phy"?
>
> /usr/home/matheus]$ devinfo -rv| grep phy
> ukphy0 pnpinfo oui=0x1e model=0x14 rev=0x9 at phyno=1
axe(4) requires correct resolved speed/link status reported from
PHY driver. Otherwise it will incorrectly reprogram some registers
and this can result in unexpected result.
The OUI 0x1e from the above looks odd and I'm not aware of any PHY
vendors that reports such OUI. Because FreeBSD does not strictly
follows OUI decoding defined by IEEE it's also possible that
FreeBSD incorrectly showed wrong OUI. What is your USB ethernet
controller model?
>
> I'm trying to test it on current, but I think it will be the same (I saw
> cvs commits till releng 8 creating and all commits are the same ).
>
Unless we fix the PHY issue you would get the same result on
stable/8.
> still looking for better performance usb nic :) you think the slower
> linksys usb200m (axe based also) will have better luck in this link
> negotiation issue ? (I don't need gigabit, just to break the 10Mbps at
I have no experience with usb200m so I don't know.
> start - though breaking the 50Mpbs would be perfert).
>
> thanks,
------------------------------
Message: 6
Date: Wed, 24 Mar 2010 14:58:27 -0700
From: Pyun YongHyeon <pyu...@gmail.com>
Subject: Re: 10Mbps+ throughput usb based ethernet recommendation
To: Nenhum_de_Nos <mat...@eternamente.info>
Cc: freeb...@freebsd.org
Message-ID: <2010032421...@michelle.cdnetworks.com>
Content-Type: text/plain; charset="us-ascii"
On Wed, Mar 24, 2010 at 02:42:30PM -0700, Pyun YongHyeon wrote:
> On Wed, Mar 24, 2010 at 06:16:21PM -0300, Nenhum_de_Nos wrote:
> >
> > On Tue, March 23, 2010 22:01, Pyun YongHyeon wrote:
>
> [...]
>
> > >> Just adding info, I keep getting these outputs from ifconfig:
> > >>
> > >> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
> > >> 1500
> > >> ether 00:11:50:e7:39:e9
> > >> inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
> > >> media: Ethernet autoselect (1000baseT <full-duplex>)
> > >> status: active
> > >> and:
> > >> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
> > >> 1500
> > >> ether 00:11:50:e7:39:e9
> > >> inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
> > >> media: Ethernet autoselect (100baseTX <full-duplex,hw-loopback>)
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > >> status: active
> > >>
> > >> and this keeps repeating over and over. iperf and on the other end an
> > >
> > > Maybe this is real problem. It seems PHY have trouble to establish
> > > link. This is FreeBSD stable/8 right?
> >
> > yes. on 7.2 is even worse :(
> >
> > > Would you show me the output of "devinfo -rv| grep phy"?
> >
> > /usr/home/matheus]$ devinfo -rv| grep phy
> > ukphy0 pnpinfo oui=0x1e model=0x14 rev=0x9 at phyno=1
>
> axe(4) requires correct resolved speed/link status reported from
> PHY driver. Otherwise it will incorrectly reprogram some registers
> and this can result in unexpected result.
> The OUI 0x1e from the above looks odd and I'm not aware of any PHY
> vendors that reports such OUI. Because FreeBSD does not strictly
> follows OUI decoding defined by IEEE it's also possible that
> FreeBSD incorrectly showed wrong OUI. What is your USB ethernet
> controller model?
>
Please try this patch and let me know the output on your console.
It will show you "XXX ID1 = 0xYYYY, ID2 = 0xZZZZ".
> >
> > I'm trying to test it on current, but I think it will be the same (I saw
> > cvs commits till releng 8 creating and all commits are the same ).
> >
>
> Unless we fix the PHY issue you would get the same result on
> stable/8.
>
> > still looking for better performance usb nic :) you think the slower
> > linksys usb200m (axe based also) will have better luck in this link
> > negotiation issue ? (I don't need gigabit, just to break the 10Mbps at
>
> I have no experience with usb200m so I don't know.
>
> > start - though breaking the 50Mpbs would be perfert).
> >
> > thanks,
------------------------------
Message: 7
Date: Wed, 24 Mar 2010 16:18:33 -0700
From: Pyun YongHyeon <pyu...@gmail.com>
Subject: Re: 10Mbps+ throughput usb based ethernet recommendation
To: Nenhum_de_Nos <mat...@eternamente.info>
Cc: freeb...@freebsd.org
Message-ID: <2010032423...@michelle.cdnetworks.com>
Content-Type: text/plain; charset="us-ascii"
On Wed, Mar 24, 2010 at 02:58:27PM -0700, Pyun YongHyeon wrote:
> On Wed, Mar 24, 2010 at 02:42:30PM -0700, Pyun YongHyeon wrote:
> > On Wed, Mar 24, 2010 at 06:16:21PM -0300, Nenhum_de_Nos wrote:
> > >
> > > On Tue, March 23, 2010 22:01, Pyun YongHyeon wrote:
> >
> > [...]
> >
> > > >> Just adding info, I keep getting these outputs from ifconfig:
> > > >>
> > > >> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
> > > >> 1500
> > > >> ether 00:11:50:e7:39:e9
> > > >> inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
> > > >> media: Ethernet autoselect (1000baseT <full-duplex>)
> > > >> status: active
> > > >> and:
> > > >> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
> > > >> 1500
> > > >> ether 00:11:50:e7:39:e9
> > > >> inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
> > > >> media: Ethernet autoselect (100baseTX <full-duplex,hw-loopback>)
> > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > >> status: active
> > > >>
> > > >> and this keeps repeating over and over. iperf and on the other end an
> > > >
> > > > Maybe this is real problem. It seems PHY have trouble to establish
> > > > link. This is FreeBSD stable/8 right?
> > >
> > > yes. on 7.2 is even worse :(
> > >
> > > > Would you show me the output of "devinfo -rv| grep phy"?
> > >
> > > /usr/home/matheus]$ devinfo -rv| grep phy
> > > ukphy0 pnpinfo oui=0x1e model=0x14 rev=0x9 at phyno=1
> >
> > axe(4) requires correct resolved speed/link status reported from
> > PHY driver. Otherwise it will incorrectly reprogram some registers
> > and this can result in unexpected result.
> > The OUI 0x1e from the above looks odd and I'm not aware of any PHY
> > vendors that reports such OUI. Because FreeBSD does not strictly
> > follows OUI decoding defined by IEEE it's also possible that
> > FreeBSD incorrectly showed wrong OUI. What is your USB ethernet
> > controller model?
> >
>
> Please try this patch and let me know the output on your console.
> It will show you "XXX ID1 = 0xYYYY, ID2 = 0xZZZZ".
>
Use this patch instead of previous one.
-------------- next part --------------
Index: sys/dev/mii/ukphy.c
===================================================================
--- sys/dev/mii/ukphy.c (revision 205608)
+++ sys/dev/mii/ukphy.c (working copy)
@@ -141,6 +141,8 @@
device_printf(dev, "OUI 0x%06x, model 0x%04x, rev. %d\n",
MII_OUI(ma->mii_id1, ma->mii_id2),
MII_MODEL(ma->mii_id2), MII_REV(ma->mii_id2));
+ device_printf(dev, "XXX ID1 = 0x%04x, ID2 = 0x%04x\n",
+ ma->mii_id1, ma->mii_id2);
sc->mii_inst = mii->mii_instance;
sc->mii_phy = ma->mii_phyno;
------------------------------
Message: 8
Date: Thu, 25 Mar 2010 11:38:42 -0400
From: Andre Guibert de Bruet <an...@siliconlandmark.com>
Subject: Re: usb/128803: [usbdevs] [patch] Quirk for I-Tuner Networks
USBLCD4X20 support
To: Mark Linimon <lin...@freebsd.org>
Cc: freeb...@freebsd.org
Message-ID: <BC9BFC06-0152-44DB...@siliconlandmark.com>
Content-Type: text/plain; charset=us-ascii
I will try to get the time to do so on Friday. Stay tuned.
Regards,
/* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */
/* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */
/* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */
/* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */
On Mar 22, 2010, at 7:57 PM, lin...@freebsd.org wrote:
> Synopsis: [usbdevs] [patch] Quirk for I-Tuner Networks USBLCD4X20 support
>
> State-Changed-From-To: open->feedback
> State-Changed-By: linimon
> State-Changed-When: Mon Mar 22 23:57:32 UTC 2010
> State-Changed-Why:
> To submitter: have you tried this with the new USB stack in FreeBSD 8?
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=128803
------------------------------
Message: 9
Date: Thu, 25 Mar 2010 14:22:32 -0300 (BRT)
From: "Nenhum_de_Nos" <mat...@eternamente.info>
Subject: Re: 10Mbps+ throughput usb based ethernet recommendation
To: pyu...@gmail.com
Cc: freeb...@freebsd.org
Message-ID:
<35a626b67a1556071f4c...@cygnus.homeunix.com>
Content-Type: text/plain;charset=iso-8859-1
On Wed, March 24, 2010 20:18, Pyun YongHyeon wrote:
> On Wed, Mar 24, 2010 at 02:58:27PM -0700, Pyun YongHyeon wrote:
>> On Wed, Mar 24, 2010 at 02:42:30PM -0700, Pyun YongHyeon wrote:
>> > On Wed, Mar 24, 2010 at 06:16:21PM -0300, Nenhum_de_Nos wrote:
>> > >
>> > > On Tue, March 23, 2010 22:01, Pyun YongHyeon wrote:
>> >
>> > [...]
>> >
>> > > >> Just adding info, I keep getting these outputs from ifconfig:
>> > > >>
>> > > >> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0
>> mtu
>> > > >> 1500
>> > > >> ether 00:11:50:e7:39:e9
>> > > >> inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
>> > > >> media: Ethernet autoselect (1000baseT <full-duplex>)
>> > > >> status: active
>> > > >> and:
>> > > >> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0
>> mtu
>> > > >> 1500
>> > > >> ether 00:11:50:e7:39:e9
>> > > >> inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
>> > > >> media: Ethernet autoselect (100baseTX <full-duplex,hw-loopback>)
>> > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > > >> status: active
>> > > >>
>> > > >> and this keeps repeating over and over. iperf and on the other
>> end an
>> > > >
>> > > > Maybe this is real problem. It seems PHY have trouble to establish
>> > > > link. This is FreeBSD stable/8 right?
>> > >
>> > > yes. on 7.2 is even worse :(
>> > >
>> > > > Would you show me the output of "devinfo -rv| grep phy"?
>> > >
>> > > /usr/home/matheus]$ devinfo -rv| grep phy
>> > > ukphy0 pnpinfo oui=0x1e model=0x14 rev=0x9 at
>> phyno=1
>> >
>> > axe(4) requires correct resolved speed/link status reported from
>> > PHY driver. Otherwise it will incorrectly reprogram some registers
>> > and this can result in unexpected result.
>> > The OUI 0x1e from the above looks odd and I'm not aware of any PHY
>> > vendors that reports such OUI. Because FreeBSD does not strictly
>> > follows OUI decoding defined by IEEE it's also possible that
>> > FreeBSD incorrectly showed wrong OUI. What is your USB ethernet
>> > controller model?
>> >
>>
>> Please try this patch and let me know the output on your console.
>> It will show you "XXX ID1 = 0xYYYY, ID2 = 0xZZZZ".
>>
>
> Use this patch instead of previous one.
I applied the patch, and recompiled just the module. no good, then mii
module also recompiled. this time I can ping from inside the
freebsd-current vm (vbox) using bridged networking (notebook ethernet nfe
adapter) connected to this axe device (this on 8-stable native).
ping runs, but yet looses packets:
64 bytes from 192.168.1.1: icmp_seq=125 ttl=64 time=0.507 ms
load: 0.54 cmd: ping 15245 [select] 125.96r 0.01u 0.00s 0% 1372k
95/126 packets received (75.4%) 0.450 min / 1.359 avg / 51.108 max
64 bytes from 192.168.1.1: icmp_seq=126 ttl=64 time=0.499 ms
but I see no messages on console/dmesg/messages file:
Mar 25 14:04:40 darkside kernel: ue0: link state changed to DOWN
Mar 25 14:04:40 darkside kernel: ue0: link state changed to UP
Mar 25 14:06:17 darkside kernel: ue0: promiscuous mode enabled
Mar 25 14:06:35 darkside kernel: ue0: promiscuous mode disabled
Mar 25 14:15:59 darkside kernel: ugen1.4: <vendor 0x050d> at usbus1
(disconnected)
Mar 25 14:15:59 darkside kernel: axe0: at uhub1, port 3, addr 4
(disconnected)
Mar 25 14:15:59 darkside kernel: ukphy0: detached
Mar 25 14:15:59 darkside kernel: miibus1: detached
Mar 25 14:16:00 darkside kernel: nfe0: link state changed to DOWN
Mar 25 14:16:19 darkside kernel: ugen1.4: <vendor 0x050d> at usbus1
Mar 25 14:16:19 darkside kernel: axe0: <vendor 0x050d product 0x5055, rev
2.00/0.01, addr 4> on usbus1
Mar 25 14:16:19 darkside kernel: axe0: PHYADDR 0xe0:0x01
Mar 25 14:16:20 darkside kernel: miibus1: <MII bus> on axe0
Mar 25 14:16:20 darkside kernel: ukphy0: <Generic IEEE 802.3u media
interface> PHY 1 on miibus1
Mar 25 14:16:20 darkside kernel: ukphy0: 10baseT, 10baseT-FDX, 100baseTX,
100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
Mar 25 14:16:20 darkside kernel: ue0: <USB Ethernet> on axe0
Mar 25 14:16:20 darkside kernel: ue0: Ethernet address: 00:11:50:e7:39:e9
Mar 25 14:16:21 darkside kernel: ue0: link state changed to DOWN
Mar 25 14:16:23 darkside kernel: nfe0: link state changed to UP
Mar 25 14:17:06 darkside kernel: ue0: link state changed to UP
do I need to recompile kernel ? (I will as soon as I get home anyway)
media keeps looping though:
ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 00:11:50:e7:39:e9
inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
media: Ethernet autoselect (1000baseT <full-duplex,hw-loopback>)
status: active
[root@xxx ~]# ifconfig ue0
ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 00:11:50:e7:39:e9
inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
thanks,
matheus
--
We will call you cygnus,
The God of balance you shall be
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
http://en.wikipedia.org/wiki/Posting_style
------------------------------
Message: 10
Date: Thu, 25 Mar 2010 10:35:56 -0700
From: Pyun YongHyeon <pyu...@gmail.com>
Subject: Re: 10Mbps+ throughput usb based ethernet recommendation
To: Nenhum_de_Nos <mat...@eternamente.info>
Cc: freeb...@freebsd.org
Message-ID: <2010032517...@michelle.cdnetworks.com>
Content-Type: text/plain; charset=us-ascii
On Thu, Mar 25, 2010 at 02:22:32PM -0300, Nenhum_de_Nos wrote:
>
> On Wed, March 24, 2010 20:18, Pyun YongHyeon wrote:
> > On Wed, Mar 24, 2010 at 02:58:27PM -0700, Pyun YongHyeon wrote:
> >> On Wed, Mar 24, 2010 at 02:42:30PM -0700, Pyun YongHyeon wrote:
> >> > On Wed, Mar 24, 2010 at 06:16:21PM -0300, Nenhum_de_Nos wrote:
> >> > >
> >> > > On Tue, March 23, 2010 22:01, Pyun YongHyeon wrote:
> >> >
> >> > [...]
> >> >
> >> > > >> Just adding info, I keep getting these outputs from ifconfig:
> >> > > >>
> >> > > >> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0
> >> mtu
> >> > > >> 1500
> >> > > >> ether 00:11:50:e7:39:e9
> >> > > >> inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
> >> > > >> media: Ethernet autoselect (1000baseT <full-duplex>)
> >> > > >> status: active
> >> > > >> and:
> >> > > >> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0
> >> mtu
> >> > > >> 1500
> >> > > >> ether 00:11:50:e7:39:e9
> >> > > >> inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
> >> > > >> media: Ethernet autoselect (100baseTX <full-duplex,hw-loopback>)
> >> > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> > > >> status: active
> >> > > >>
> >> > > >> and this keeps repeating over and over. iperf and on the other
> >> end an
> >> > > >
> >> > > > Maybe this is real problem. It seems PHY have trouble to establish
> >> > > > link. This is FreeBSD stable/8 right?
> >> > >
> >> > > yes. on 7.2 is even worse :(
> >> > >
> >> > > > Would you show me the output of "devinfo -rv| grep phy"?
> >> > >
> >> > > /usr/home/matheus]$ devinfo -rv| grep phy
> >> > > ukphy0 pnpinfo oui=0x1e model=0x14 rev=0x9 at
> >> phyno=1
> >> >
> >> > axe(4) requires correct resolved speed/link status reported from
> >> > PHY driver. Otherwise it will incorrectly reprogram some registers
> >> > and this can result in unexpected result.
> >> > The OUI 0x1e from the above looks odd and I'm not aware of any PHY
> >> > vendors that reports such OUI. Because FreeBSD does not strictly
> >> > follows OUI decoding defined by IEEE it's also possible that
> >> > FreeBSD incorrectly showed wrong OUI. What is your USB ethernet
> >> > controller model?
> >> >
> >>
> >> Please try this patch and let me know the output on your console.
> >> It will show you "XXX ID1 = 0xYYYY, ID2 = 0xZZZZ".
> >>
> >
> > Use this patch instead of previous one.
>
> I applied the patch, and recompiled just the module. no good, then mii
> module also recompiled. this time I can ping from inside the
> freebsd-current vm (vbox) using bridged networking (notebook ethernet nfe
> adapter) connected to this axe device (this on 8-stable native).
>
> ping runs, but yet looses packets:
>
The patch just prints some register information which could be used
to track down PHY issues. So it's expected one as the patch has no
functional changes.
> 64 bytes from 192.168.1.1: icmp_seq=125 ttl=64 time=0.507 ms
> load: 0.54 cmd: ping 15245 [select] 125.96r 0.01u 0.00s 0% 1372k
> 95/126 packets received (75.4%) 0.450 min / 1.359 avg / 51.108 max
> 64 bytes from 192.168.1.1: icmp_seq=126 ttl=64 time=0.499 ms
>
> but I see no messages on console/dmesg/messages file:
>
> Mar 25 14:04:40 darkside kernel: ue0: link state changed to DOWN
> Mar 25 14:04:40 darkside kernel: ue0: link state changed to UP
> Mar 25 14:06:17 darkside kernel: ue0: promiscuous mode enabled
> Mar 25 14:06:35 darkside kernel: ue0: promiscuous mode disabled
> Mar 25 14:15:59 darkside kernel: ugen1.4: <vendor 0x050d> at usbus1
> (disconnected)
> Mar 25 14:15:59 darkside kernel: axe0: at uhub1, port 3, addr 4
> (disconnected)
> Mar 25 14:15:59 darkside kernel: ukphy0: detached
> Mar 25 14:15:59 darkside kernel: miibus1: detached
> Mar 25 14:16:00 darkside kernel: nfe0: link state changed to DOWN
> Mar 25 14:16:19 darkside kernel: ugen1.4: <vendor 0x050d> at usbus1
> Mar 25 14:16:19 darkside kernel: axe0: <vendor 0x050d product 0x5055, rev
> 2.00/0.01, addr 4> on usbus1
> Mar 25 14:16:19 darkside kernel: axe0: PHYADDR 0xe0:0x01
> Mar 25 14:16:20 darkside kernel: miibus1: <MII bus> on axe0
> Mar 25 14:16:20 darkside kernel: ukphy0: <Generic IEEE 802.3u media
> interface> PHY 1 on miibus1
> Mar 25 14:16:20 darkside kernel: ukphy0: 10baseT, 10baseT-FDX, 100baseTX,
> 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
> Mar 25 14:16:20 darkside kernel: ue0: <USB Ethernet> on axe0
> Mar 25 14:16:20 darkside kernel: ue0: Ethernet address: 00:11:50:e7:39:e9
> Mar 25 14:16:21 darkside kernel: ue0: link state changed to DOWN
> Mar 25 14:16:23 darkside kernel: nfe0: link state changed to UP
> Mar 25 14:17:06 darkside kernel: ue0: link state changed to UP
>
> do I need to recompile kernel ? (I will as soon as I get home anyway)
>
Yes, mii(4) should be recompiled to get the register information.
Let me know ukphy(4) output after rebuilding kernel.
------------------------------
Message: 11
Date: Thu, 25 Mar 2010 16:42:19 -0300 (BRT)
From: "Nenhum_de_Nos" <mat...@eternamente.info>
Subject: Re: 10Mbps+ throughput usb based ethernet recommendation
To: pyu...@gmail.com
Cc: freeb...@freebsd.org
Message-ID:
<b5b7224dd079150dcb9c...@cygnus.homeunix.com>
Content-Type: text/plain;charset=iso-8859-1
On Thu, March 25, 2010 14:35, Pyun YongHyeon wrote:
> On Thu, Mar 25, 2010 at 02:22:32PM -0300, Nenhum_de_Nos wrote:
>>
>> On Wed, March 24, 2010 20:18, Pyun YongHyeon wrote:
>> > On Wed, Mar 24, 2010 at 02:58:27PM -0700, Pyun YongHyeon wrote:
>> >> On Wed, Mar 24, 2010 at 02:42:30PM -0700, Pyun YongHyeon wrote:
>> >> > On Wed, Mar 24, 2010 at 06:16:21PM -0300, Nenhum_de_Nos wrote:
>> >> > >
>> >> > > On Tue, March 23, 2010 22:01, Pyun YongHyeon wrote:
>> >> >
>> >> > [...]
>> >> >
>> >> > > >> Just adding info, I keep getting these outputs from ifconfig:
>> >> > > >>
>> >> > > >> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric
>> 0
>> >> mtu
>> >> > > >> 1500
>> >> > > >> ether 00:11:50:e7:39:e9
>> >> > > >> inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
>> >> > > >> media: Ethernet autoselect (1000baseT <full-duplex>)
>> >> > > >> status: active
>> >> > > >> and:
>> >> > > >> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric
>> 0
>> >> mtu
>> >> > > >> 1500
>> >> > > >> ether 00:11:50:e7:39:e9
>> >> > > >> inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
>> >> > > >> media: Ethernet autoselect (100baseTX
>> <full-duplex,hw-loopback>)
>> >> > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >> > > >> status: active
>> >> > > >>
>> >> > > >> and this keeps repeating over and over. iperf and on the other
>> >> end an
>> >> > > >
>> >> > > > Maybe this is real problem. It seems PHY have trouble to
>> establish
>> >> > > > link. This is FreeBSD stable/8 right?
>> >> > >
>> >> > > yes. on 7.2 is even worse :(
>> >> > >
>> >> > > > Would you show me the output of "devinfo -rv| grep phy"?
>> >> > >
>> >> > > /usr/home/matheus]$ devinfo -rv| grep phy
>> >> > > ukphy0 pnpinfo oui=0x1e model=0x14 rev=0x9 at
>> >> phyno=1
>> >> >
>> >> > axe(4) requires correct resolved speed/link status reported from
>> >> > PHY driver. Otherwise it will incorrectly reprogram some registers
>> >> > and this can result in unexpected result.
>> >> > The OUI 0x1e from the above looks odd and I'm not aware of any PHY
>> >> > vendors that reports such OUI. Because FreeBSD does not strictly
>> >> > follows OUI decoding defined by IEEE it's also possible that
>> >> > FreeBSD incorrectly showed wrong OUI. What is your USB ethernet
>> >> > controller model?
>> >> >
>> >>
>> >> Please try this patch and let me know the output on your console.
>> >> It will show you "XXX ID1 = 0xYYYY, ID2 = 0xZZZZ".
>> >>
>> >
>> > Use this patch instead of previous one.
>>
>> I applied the patch, and recompiled just the module. no good, then mii
>> module also recompiled. this time I can ping from inside the
>> freebsd-current vm (vbox) using bridged networking (notebook ethernet
>> nfe
>> adapter) connected to this axe device (this on 8-stable native).
>>
>> ping runs, but yet looses packets:
>>
>
> The patch just prints some register information which could be used
> to track down PHY issues. So it's expected one as the patch has no
> functional changes.
>
>> 64 bytes from 192.168.1.1: icmp_seq=125 ttl=64 time=0.507 ms
>> load: 0.54 cmd: ping 15245 [select] 125.96r 0.01u 0.00s 0% 1372k
>> 95/126 packets received (75.4%) 0.450 min / 1.359 avg / 51.108 max
>> 64 bytes from 192.168.1.1: icmp_seq=126 ttl=64 time=0.499 ms
>>
>> but I see no messages on console/dmesg/messages file:
>>
>> Mar 25 14:04:40 darkside kernel: ue0: link state changed to DOWN
>> Mar 25 14:04:40 darkside kernel: ue0: link state changed to UP
>> Mar 25 14:06:17 darkside kernel: ue0: promiscuous mode enabled
>> Mar 25 14:06:35 darkside kernel: ue0: promiscuous mode disabled
>> Mar 25 14:15:59 darkside kernel: ugen1.4: <vendor 0x050d> at usbus1
>> (disconnected)
>> Mar 25 14:15:59 darkside kernel: axe0: at uhub1, port 3, addr 4
>> (disconnected)
>> Mar 25 14:15:59 darkside kernel: ukphy0: detached
>> Mar 25 14:15:59 darkside kernel: miibus1: detached
>> Mar 25 14:16:00 darkside kernel: nfe0: link state changed to DOWN
>> Mar 25 14:16:19 darkside kernel: ugen1.4: <vendor 0x050d> at usbus1
>> Mar 25 14:16:19 darkside kernel: axe0: <vendor 0x050d product 0x5055,
>> rev
>> 2.00/0.01, addr 4> on usbus1
>> Mar 25 14:16:19 darkside kernel: axe0: PHYADDR 0xe0:0x01
>> Mar 25 14:16:20 darkside kernel: miibus1: <MII bus> on axe0
>> Mar 25 14:16:20 darkside kernel: ukphy0: <Generic IEEE 802.3u media
>> interface> PHY 1 on miibus1
>> Mar 25 14:16:20 darkside kernel: ukphy0: 10baseT, 10baseT-FDX,
>> 100baseTX,
>> 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
>> Mar 25 14:16:20 darkside kernel: ue0: <USB Ethernet> on axe0
>> Mar 25 14:16:20 darkside kernel: ue0: Ethernet address:
>> 00:11:50:e7:39:e9
>> Mar 25 14:16:21 darkside kernel: ue0: link state changed to DOWN
>> Mar 25 14:16:23 darkside kernel: nfe0: link state changed to UP
>> Mar 25 14:17:06 darkside kernel: ue0: link state changed to UP
>>
>> do I need to recompile kernel ? (I will as soon as I get home anyway)
>>
>
> Yes, mii(4) should be recompiled to get the register information.
> Let me know ukphy(4) output after rebuilding kernel.
there you are:
miibus1: <MII bus> on axe0
ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus1
ukphy0: XXX ID1 = 0x7949, ID2 = 0x7949
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseSX,
1000baseT, 1000baseT-FDX, auto
ue0: <USB Ethernet> on axe0
ue0: Ethernet address: xx:xx:xx:xx:xx:xx
let me know if you need anything else :)
thanks,
matheus
--
We will call you cygnus,
The God of balance you shall be
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
http://en.wikipedia.org/wiki/Posting_style
------------------------------
Message: 12
Date: Thu, 25 Mar 2010 17:31:50 -0700
From: Pyun YongHyeon <pyu...@gmail.com>
Subject: Re: 10Mbps+ throughput usb based ethernet recommendation
To: Nenhum_de_Nos <mat...@eternamente.info>
Cc: freeb...@freebsd.org
Message-ID: <2010032600...@michelle.cdnetworks.com>
Content-Type: text/plain; charset=us-ascii
On Thu, Mar 25, 2010 at 04:42:19PM -0300, Nenhum_de_Nos wrote:
>
> On Thu, March 25, 2010 14:35, Pyun YongHyeon wrote:
> > On Thu, Mar 25, 2010 at 02:22:32PM -0300, Nenhum_de_Nos wrote:
> >>
> >> On Wed, March 24, 2010 20:18, Pyun YongHyeon wrote:
> >> > On Wed, Mar 24, 2010 at 02:58:27PM -0700, Pyun YongHyeon wrote:
> >> >> On Wed, Mar 24, 2010 at 02:42:30PM -0700, Pyun YongHyeon wrote:
> >> >> > On Wed, Mar 24, 2010 at 06:16:21PM -0300, Nenhum_de_Nos wrote:
> >> >> > >
> >> >> > > On Tue, March 23, 2010 22:01, Pyun YongHyeon wrote:
> >> >> >
> >> >> > [...]
> >> >> >
> >> >> > > >> Just adding info, I keep getting these outputs from ifconfig:
> >> >> > > >>
> >> >> > > >> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric
> >> 0
> >> >> mtu
> >> >> > > >> 1500
> >> >> > > >> ether 00:11:50:e7:39:e9
> >> >> > > >> inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
> >> >> > > >> media: Ethernet autoselect (1000baseT <full-duplex>)
> >> >> > > >> status: active
> >> >> > > >> and:
> >> >> > > >> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric
> >> 0
> >> >> mtu
> >> >> > > >> 1500
> >> >> > > >> ether 00:11:50:e7:39:e9
> >> >> > > >> inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
> >> >> > > >> media: Ethernet autoselect (100baseTX
> >> <full-duplex,hw-loopback>)
> >> >> > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> >> > > >> status: active
> >> >> > > >>
> >> >> > > >> and this keeps repeating over and over. iperf and on the other
> >> >> end an
> >> >> > > >
> >> >> > > > Maybe this is real problem. It seems PHY have trouble to
> >> establish
> >> >> > > > link. This is FreeBSD stable/8 right?
> >> >> > >
> >> >> > > yes. on 7.2 is even worse :(
> >> >> > >
> >> >> > > > Would you show me the output of "devinfo -rv| grep phy"?
> >> >> > >
> >> >> > > /usr/home/matheus]$ devinfo -rv| grep phy
> >> >> > > ukphy0 pnpinfo oui=0x1e model=0x14 rev=0x9 at
> >> >> phyno=1
> >> >> >
> >> >> > axe(4) requires correct resolved speed/link status reported from
> >> >> > PHY driver. Otherwise it will incorrectly reprogram some registers
> >> >> > and this can result in unexpected result.
> >> >> > The OUI 0x1e from the above looks odd and I'm not aware of any PHY
> >> >> > vendors that reports such OUI. Because FreeBSD does not strictly
> >> >> > follows OUI decoding defined by IEEE it's also possible that
> >> >> > FreeBSD incorrectly showed wrong OUI. What is your USB ethernet
> >> >> > controller model?
> >> >> >
> >> >>
> >> >> Please try this patch and let me know the output on your console.
> >> >> It will show you "XXX ID1 = 0xYYYY, ID2 = 0xZZZZ".
> >> >>
> >> >
> >> > Use this patch instead of previous one.
> >>
> >> I applied the patch, and recompiled just the module. no good, then mii
> >> module also recompiled. this time I can ping from inside the
> >> freebsd-current vm (vbox) using bridged networking (notebook ethernet
> >> nfe
> >> adapter) connected to this axe device (this on 8-stable native).
> >>
> >> ping runs, but yet looses packets:
> >>
> >
> > The patch just prints some register information which could be used
> > to track down PHY issues. So it's expected one as the patch has no
> > functional changes.
> >
> >> 64 bytes from 192.168.1.1: icmp_seq=125 ttl=64 time=0.507 ms
> >> load: 0.54 cmd: ping 15245 [select] 125.96r 0.01u 0.00s 0% 1372k
> >> 95/126 packets received (75.4%) 0.450 min / 1.359 avg / 51.108 max
> >> 64 bytes from 192.168.1.1: icmp_seq=126 ttl=64 time=0.499 ms
> >>
> >> but I see no messages on console/dmesg/messages file:
> >>
> >> Mar 25 14:04:40 darkside kernel: ue0: link state changed to DOWN
> >> Mar 25 14:04:40 darkside kernel: ue0: link state changed to UP
> >> Mar 25 14:06:17 darkside kernel: ue0: promiscuous mode enabled
> >> Mar 25 14:06:35 darkside kernel: ue0: promiscuous mode disabled
> >> Mar 25 14:15:59 darkside kernel: ugen1.4: <vendor 0x050d> at usbus1
> >> (disconnected)
> >> Mar 25 14:15:59 darkside kernel: axe0: at uhub1, port 3, addr 4
> >> (disconnected)
> >> Mar 25 14:15:59 darkside kernel: ukphy0: detached
> >> Mar 25 14:15:59 darkside kernel: miibus1: detached
> >> Mar 25 14:16:00 darkside kernel: nfe0: link state changed to DOWN
> >> Mar 25 14:16:19 darkside kernel: ugen1.4: <vendor 0x050d> at usbus1
> >> Mar 25 14:16:19 darkside kernel: axe0: <vendor 0x050d product 0x5055,
> >> rev
> >> 2.00/0.01, addr 4> on usbus1
> >> Mar 25 14:16:19 darkside kernel: axe0: PHYADDR 0xe0:0x01
> >> Mar 25 14:16:20 darkside kernel: miibus1: <MII bus> on axe0
> >> Mar 25 14:16:20 darkside kernel: ukphy0: <Generic IEEE 802.3u media
> >> interface> PHY 1 on miibus1
> >> Mar 25 14:16:20 darkside kernel: ukphy0: 10baseT, 10baseT-FDX,
> >> 100baseTX,
> >> 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
> >> Mar 25 14:16:20 darkside kernel: ue0: <USB Ethernet> on axe0
> >> Mar 25 14:16:20 darkside kernel: ue0: Ethernet address:
> >> 00:11:50:e7:39:e9
> >> Mar 25 14:16:21 darkside kernel: ue0: link state changed to DOWN
> >> Mar 25 14:16:23 darkside kernel: nfe0: link state changed to UP
> >> Mar 25 14:17:06 darkside kernel: ue0: link state changed to UP
> >>
> >> do I need to recompile kernel ? (I will as soon as I get home anyway)
> >>
> >
> > Yes, mii(4) should be recompiled to get the register information.
> > Let me know ukphy(4) output after rebuilding kernel.
>
> there you are:
>
> miibus1: <MII bus> on axe0
> ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus1
> ukphy0: XXX ID1 = 0x7949, ID2 = 0x7949
This value looks garbage.
> ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseSX,
> 1000baseT, 1000baseT-FDX, auto
And this time, ukphy(4) also thinks your PHY supports 1000baseSX.
Of course it's wrong because PHY is copper type.
By chance, are you using Belkin F5D5055 USB controller? I remember
another user also reported similar issue.
Hans, I guess there is not much thing left to do in PHY driver
because accessing these MII registers return garbage. What could be
done in USB subsystem to get more information to know why
controller returns garbage for accessing MII registers?
------------------------------
Message: 13
Date: Thu, 25 Mar 2010 21:57:22 -0300 (BRT)
From: "Nenhum_de_Nos" <mat...@eternamente.info>
Subject: Re: 10Mbps+ throughput usb based ethernet recommendation
To: pyu...@gmail.com
Cc: freeb...@freebsd.org
Message-ID:
<e15b32df866e9001a9f0...@cygnus.homeunix.com>
Content-Type: text/plain;charset=iso-8859-1
On Thu, March 25, 2010 21:31, Pyun YongHyeon wrote:
> On Thu, Mar 25, 2010 at 04:42:19PM -0300, Nenhum_de_Nos wrote:
>>
>> On Thu, March 25, 2010 14:35, Pyun YongHyeon wrote:
>> > On Thu, Mar 25, 2010 at 02:22:32PM -0300, Nenhum_de_Nos wrote:
>> >>
>> >> On Wed, March 24, 2010 20:18, Pyun YongHyeon wrote:
>> >> > On Wed, Mar 24, 2010 at 02:58:27PM -0700, Pyun YongHyeon wrote:
>> >> >> On Wed, Mar 24, 2010 at 02:42:30PM -0700, Pyun YongHyeon wrote:
>> >> >> > On Wed, Mar 24, 2010 at 06:16:21PM -0300, Nenhum_de_Nos wrote:
>> >> >> > >
>> >> >> > > On Tue, March 23, 2010 22:01, Pyun YongHyeon wrote:
>> >> >> >
>> >> >> > [...]
>> >> >> >
>> >> >> > > >> Just adding info, I keep getting these outputs from
>> ifconfig:
>> >> >> > > >>
>> >> >> > > >> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST>
>> metric
>> >> 0
>> >> >> mtu
>> >> >> > > >> 1500
>> >> >> > > >> ether 00:11:50:e7:39:e9
>> >> >> > > >> inet 192.168.1.1 netmask 0xffffff00 broadcast
>> 192.168.1.255
>> >> >> > > >> media: Ethernet autoselect (1000baseT <full-duplex>)
>> >> >> > > >> status: active
>> >> >> > > >> and:
>> >> >> > > >> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST>
>> metric
>> >> 0
>> >> >> mtu
>> >> >> > > >> 1500
>> >> >> > > >> ether 00:11:50:e7:39:e9
>> >> >> > > >> inet 192.168.1.1 netmask 0xffffff00 broadcast
>> 192.168.1.255
>> >> >> > > >> media: Ethernet autoselect (100baseTX
>> >> <full-duplex,hw-loopback>)
>> >> >> > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >> >> > > >> status: active
>> >> >> > > >>
>> >> >> > > >> and this keeps repeating over and over. iperf and on the
>> other
>> >> >> end an
>> >> >> > > >
>> >> >> > > > Maybe this is real problem. It seems PHY have trouble to
>> >> establish
>> >> >> > > > link. This is FreeBSD stable/8 right?
>> >> >> > >
>> >> >> > > yes. on 7.2 is even worse :(
>> >> >> > >
>> >> >> > > > Would you show me the output of "devinfo -rv| grep phy"?
>> >> >> > >
>> >> >> > > /usr/home/matheus]$ devinfo -rv| grep phy
>> >> >> > > ukphy0 pnpinfo oui=0x1e model=0x14 rev=0x9
>> at
>> >> >> phyno=1
>> >> >> >
>> >> >> > axe(4) requires correct resolved speed/link status reported from
>> >> >> > PHY driver. Otherwise it will incorrectly reprogram some
>> registers
>> >> >> > and this can result in unexpected result.
>> >> >> > The OUI 0x1e from the above looks odd and I'm not aware of any
>> PHY
>> >> >> > vendors that reports such OUI. Because FreeBSD does not strictly
>> >> >> > follows OUI decoding defined by IEEE it's also possible that
>> >> >> > FreeBSD incorrectly showed wrong OUI. What is your USB ethernet
>> >> >> > controller model?
>> >> >> >
>> >> >>
>> >> >> Please try this patch and let me know the output on your console.
>> >> >> It will show you "XXX ID1 = 0xYYYY, ID2 = 0xZZZZ".
>> >> >>
>> >> >
>> >> > Use this patch instead of previous one.
>> >>
>> >> I applied the patch, and recompiled just the module. no good, then
>> mii
>> >> module also recompiled. this time I can ping from inside the
>> >> freebsd-current vm (vbox) using bridged networking (notebook ethernet
>> >> nfe
>> >> adapter) connected to this axe device (this on 8-stable native).
>> >>
>> >> ping runs, but yet looses packets:
>> >>
>> >
>> > The patch just prints some register information which could be used
>> > to track down PHY issues. So it's expected one as the patch has no
>> > functional changes.
>> >
>> >> 64 bytes from 192.168.1.1: icmp_seq=125 ttl=64 time=0.507 ms
>> >> load: 0.54 cmd: ping 15245 [select] 125.96r 0.01u 0.00s 0% 1372k
>> >> 95/126 packets received (75.4%) 0.450 min / 1.359 avg / 51.108 max
>> >> 64 bytes from 192.168.1.1: icmp_seq=126 ttl=64 time=0.499 ms
>> >>
>> >> but I see no messages on console/dmesg/messages file:
>> >>
>> >> Mar 25 14:04:40 darkside kernel: ue0: link state changed to DOWN
>> >> Mar 25 14:04:40 darkside kernel: ue0: link state changed to UP
>> >> Mar 25 14:06:17 darkside kernel: ue0: promiscuous mode enabled
>> >> Mar 25 14:06:35 darkside kernel: ue0: promiscuous mode disabled
>> >> Mar 25 14:15:59 darkside kernel: ugen1.4: <vendor 0x050d> at usbus1
>> >> (disconnected)
>> >> Mar 25 14:15:59 darkside kernel: axe0: at uhub1, port 3, addr 4
>> >> (disconnected)
>> >> Mar 25 14:15:59 darkside kernel: ukphy0: detached
>> >> Mar 25 14:15:59 darkside kernel: miibus1: detached
>> >> Mar 25 14:16:00 darkside kernel: nfe0: link state changed to DOWN
>> >> Mar 25 14:16:19 darkside kernel: ugen1.4: <vendor 0x050d> at usbus1
>> >> Mar 25 14:16:19 darkside kernel: axe0: <vendor 0x050d product 0x5055,
>> >> rev
>> >> 2.00/0.01, addr 4> on usbus1
>> >> Mar 25 14:16:19 darkside kernel: axe0: PHYADDR 0xe0:0x01
>> >> Mar 25 14:16:20 darkside kernel: miibus1: <MII bus> on axe0
>> >> Mar 25 14:16:20 darkside kernel: ukphy0: <Generic IEEE 802.3u media
>> >> interface> PHY 1 on miibus1
>> >> Mar 25 14:16:20 darkside kernel: ukphy0: 10baseT, 10baseT-FDX,
>> >> 100baseTX,
>> >> 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
>> >> Mar 25 14:16:20 darkside kernel: ue0: <USB Ethernet> on axe0
>> >> Mar 25 14:16:20 darkside kernel: ue0: Ethernet address:
>> >> 00:11:50:e7:39:e9
>> >> Mar 25 14:16:21 darkside kernel: ue0: link state changed to DOWN
>> >> Mar 25 14:16:23 darkside kernel: nfe0: link state changed to UP
>> >> Mar 25 14:17:06 darkside kernel: ue0: link state changed to UP
>> >>
>> >> do I need to recompile kernel ? (I will as soon as I get home anyway)
>> >>
>> >
>> > Yes, mii(4) should be recompiled to get the register information.
>> > Let me know ukphy(4) output after rebuilding kernel.
>>
>> there you are:
>>
>> miibus1: <MII bus> on axe0
>> ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus1
>> ukphy0: XXX ID1 = 0x7949, ID2 = 0x7949
>
> This value looks garbage.
:(
>> ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseSX,
>> 1000baseT, 1000baseT-FDX, auto
>
> And this time, ukphy(4) also thinks your PHY supports 1000baseSX.
> Of course it's wrong because PHY is copper type.
> By chance, are you using Belkin F5D5055 USB controller? I remember
> another user also reported similar issue.
yes. I have two of them.
thanks,
matheus
> Hans, I guess there is not much thing left to do in PHY driver
> because accessing these MII registers return garbage. What could be
> done in USB subsystem to get more information to know why
> controller returns garbage for accessing MII registers?
>
--
We will call you cygnus,
The God of balance you shall be
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
http://en.wikipedia.org/wiki/Posting_style
------------------------------
Message: 14
Date: Fri, 26 Mar 2010 19:34:42 +0100
From: Nicholas 0 <absint...@gmail.com>
Subject: resetting USB after suspend
To: freeb...@freebsd.org
Message-ID: <20100326193442.6bd27799@dimitri>
Content-Type: text/plain; charset=US-ASCII
Dear list.
I'm not sure if this belongs here or on the ACPI list. Please forgive.
Sometimes when I resume my ThinkPad X200 (Core 2 Duo, 8.0-RELEASE,
amd64), my USB ports don't come back online - that is, no power to
things that I plug in and nothing shows up in dmesg. Reboot fixes it.
It doesn't seem entirely consistent, sometimes USB is fine after
suspend, sometimes it isn't.
I'm trying to see if I can find some rhyme or reason as to when this
occcurs so I can file a bug report and work with someone to get this
fixed, but in the mean time is there any way to reset the USB
subsystem/reload the drivers that I can try as a work around? It's
annoying having to reboot to charge my phone.
Nicholas
------------------------------
Message: 15
Date: Fri, 26 Mar 2010 19:59:15 +0100
From: Hans Petter Selasky <hsel...@c2i.net>
Subject: Re: resetting USB after suspend
To: freeb...@freebsd.org
Message-ID: <201003261959....@c2i.net>
Content-Type: Text/Plain; charset="iso-8859-1"
On Friday 26 March 2010 19:34:42 Nicholas 0 wrote:
> Dear list.
>
> I'm not sure if this belongs here or on the ACPI list. Please forgive.
>
> Sometimes when I resume my ThinkPad X200 (Core 2 Duo, 8.0-RELEASE,
> amd64), my USB ports don't come back online - that is, no power to
> things that I plug in and nothing shows up in dmesg. Reboot fixes it.
> It doesn't seem entirely consistent, sometimes USB is fine after
> suspend, sometimes it isn't.
>
> I'm trying to see if I can find some rhyme or reason as to when this
> occcurs so I can file a bug report and work with someone to get this
> fixed, but in the mean time is there any way to reset the USB
> subsystem/reload the drivers that I can try as a work around? It's
> annoying having to reboot to charge my phone.
>
> Nicholas
>
Hi,
This use-case has not been tested that much. USB can probably do more to
recover the state after PC resume.
--HPS
------------------------------
Message: 16
Date: Fri, 26 Mar 2010 12:24:40 -0700
From: Steve Franks <bahama...@gmail.com>
Subject: Re: uslcom drops chars(?) when used with hub
To: Hans Petter Selasky <hsel...@c2i.net>
Cc: freeb...@freebsd.org
Message-ID:
<539c60b91003261224t6af...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
> Hi,
>
> You can try:
> sysctl hw.usb.uslcom.debug=15
**plugged into hub**
[steve@dystant /usr/home/steve]$ dmesg
uslcom_set_dtr:332: onoff = 1
uslcom_set_rts:356: onoff = 1
uslcom_set_dtr:332: onoff = 0
uslcom_set_rts:356: onoff = 0
uslcom_get_status:445:
uslcom_param:388:
uslcom_param:388:
uslcom_set_dtr:332: onoff = 0
uslcom_set_rts:356: onoff = 1
uslcom_set_dtr:332: onoff = 1
uslcom_write_callback:485: actlen = 1
uslcom_set_rts:356: onoff = 1
uslcom_write_callback:485: actlen = 13
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 8
uslcom_write_callback:485: actlen = 2
uslcom_write_callback:485: actlen = 2
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 18
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 7
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
**at this point, the bootloader program talking to the usb freezes**
**plugged into root hub***
...
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 7
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 20
uslcom_write_callback:485: actlen = 6
uslcom_set_dtr:332: onoff = 1
uslcom_set_rts:356: onoff = 0
uslcom_set_dtr:332: onoff = 1
uslcom_set_rts:356: onoff = 1
uslcom_param:388:
uslcom_set_dtr:332: onoff = 0
uslcom_set_rts:356: onoff = 1
**bootloader program exits sucessfully**
> What does usbconfig say about your device when you use the HUB and without
> HUB?
**root hub**
[steve@dystant /usr/home/steve]$ usbconfig
ugen0.1: <UHCI root HUB Intel> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen1.1: <UHCI root HUB Intel> at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen2.1: <UHCI root HUB Intel> at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen3.1: <UHCI root HUB Intel> at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen4.1: <EHCI root HUB Intel> at usbus4, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=ON
ugen4.2: <USB Storage vendor 0x05e3> at usbus4, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=ON
ugen4.3: <USB2.0 Hub vendor 0x05e3> at usbus4, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=SAVE
ugen2.2: <Kensington Expert Mouse Kensington> at usbus2, cfg=0 md=HOST
spd=LOW (1.5Mbps) pwr=ON
ugen4.4: <USB2.0 Hub vendor 0x05e3> at usbus4, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=SAVE
ugen4.5: <Olimex OpenOCD JTAG Olimex> at usbus4, cfg=0 md=HOST
spd=FULL (12Mbps) pwr=ON
ugen0.2: <CP2103 USB to UART Bridge Contr Silicon Labs> at usbus0,
cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
**ext hub**
[steve@dystant /usr/home/steve]$ usbconfig
ugen0.1: <UHCI root HUB Intel> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen1.1: <UHCI root HUB Intel> at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen2.1: <UHCI root HUB Intel> at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen3.1: <UHCI root HUB Intel> at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen4.1: <EHCI root HUB Intel> at usbus4, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=ON
ugen4.2: <USB Storage vendor 0x05e3> at usbus4, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=ON
ugen4.3: <USB2.0 Hub vendor 0x05e3> at usbus4, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=SAVE
ugen2.2: <Kensington Expert Mouse Kensington> at usbus2, cfg=0 md=HOST
spd=LOW (1.5Mbps) pwr=ON
ugen4.4: <USB2.0 Hub vendor 0x05e3> at usbus4, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=SAVE
ugen4.5: <Olimex OpenOCD JTAG Olimex> at usbus4, cfg=0 md=HOST
spd=FULL (12Mbps) pwr=ON
ugen4.6: <CP2103 USB to UART Bridge Contr Silicon Labs> at usbus4,
cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
Pretty much looks indecipherably the same in each to me...
Thanks,
Steve
------------------------------
Message: 17
Date: Fri, 26 Mar 2010 20:35:16 +0100
From: Hans Petter Selasky <hsel...@c2i.net>
Subject: Re: uslcom drops chars(?) when used with hub
To: Steve Franks <bahama...@gmail.com>
Cc: freeb...@freebsd.org
Message-ID: <201003262035....@c2i.net>
Content-Type: Text/Plain; charset="iso-8859-1"
On Friday 26 March 2010 20:24:40 Steve Franks wrote:
> > Hi,
> >
> > You can try:
> > sysctl hw.usb.uslcom.debug=15
>
Hi,
I see that your USB HUB is HIGH speed, while your device is FULL speed. That
means the USB HUB will translate the speed from HIGH to FULL speed, which
might be one part of the problem. Could you try another branded USB 2.0 HUB
and see if the problem is the same?
--HPS
------------------------------
Message: 18
Date: Fri, 26 Mar 2010 12:50:12 -0700
From: Pyun YongHyeon <pyu...@gmail.com>
Subject: Re: 10Mbps+ throughput usb based ethernet recommendation
To: Nenhum_de_Nos <mat...@eternamente.info>
Cc: freeb...@freebsd.org
Message-ID: <2010032619...@michelle.cdnetworks.com>
Content-Type: text/plain; charset="us-ascii"
On Thu, Mar 25, 2010 at 09:57:22PM -0300, Nenhum_de_Nos wrote:
[...]
> >> miibus1: <MII bus> on axe0
> >> ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus1
> >> ukphy0: XXX ID1 = 0x7949, ID2 = 0x7949
> >
> > This value looks garbage.
>
> :(
>
> >> ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseSX,
> >> 1000baseT, 1000baseT-FDX, auto
> >
> > And this time, ukphy(4) also thinks your PHY supports 1000baseSX.
> > Of course it's wrong because PHY is copper type.
> > By chance, are you using Belkin F5D5055 USB controller? I remember
> > another user also reported similar issue.
>
> yes. I have two of them.
>
Ok, would you try attached patch and check whether the patch prints
some error messages on your console? I guess some commands are
timed out here.
> thanks,
>
> matheus
>
> > Hans, I guess there is not much thing left to do in PHY driver
> > because accessing these MII registers return garbage. What could be
> > done in USB subsystem to get more information to know why
> > controller returns garbage for accessing MII registers?
> >
-------------- next part --------------
Index: sys/dev/usb/net/if_axe.c
===================================================================
--- sys/dev/usb/net/if_axe.c (revision 205700)
+++ sys/dev/usb/net/if_axe.c (working copy)
@@ -295,7 +295,7 @@
{
struct axe_softc *sc = device_get_softc(dev);
uint16_t val;
- int locked;
+ int error, locked;
if (sc->sc_phyno != phy)
return (0);
@@ -304,9 +304,15 @@
if (!locked)
AXE_LOCK(sc);
- axe_cmd(sc, AXE_CMD_MII_OPMODE_SW, 0, 0, NULL);
- axe_cmd(sc, AXE_CMD_MII_READ_REG, reg, phy, &val);
- axe_cmd(sc, AXE_CMD_MII_OPMODE_HW, 0, 0, NULL);
+ error = axe_cmd(sc, AXE_CMD_MII_OPMODE_SW, 0, 0, NULL);
+ if (error != 0)
+ printf("AXE_CMD_MII_OPMODE_SW failed : %d:%d\n", reg, error);
+ error = axe_cmd(sc, AXE_CMD_MII_READ_REG, reg, phy, &val);
+ if (error != 0)
+ printf("AXE_CMD_MII_READ_REG failed : %d:%d\n", reg, error);
+ error = axe_cmd(sc, AXE_CMD_MII_OPMODE_HW, 0, 0, NULL);
+ if (error != 0)
+ printf("AXE_CMD_MII_OPMODE_HW failed : %d:%d\n", reg, error);
val = le16toh(val);
if ((sc->sc_flags & AXE_FLAG_772) != 0 && reg == MII_BMSR) {
------------------------------
Message: 19
Date: Fri, 26 Mar 2010 13:06:49 -0700
From: Steve Franks <bahama...@gmail.com>
Subject: Re: uslcom drops chars(?) when used with hub
To: Hans Petter Selasky <hsel...@c2i.net>
Cc: freeb...@freebsd.org
Message-ID:
<539c60b91003261306v758...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Mar 26, 2010 at 12:35 PM, Hans Petter Selasky <hsel...@c2i.net> wrote:
> On Friday 26 March 2010 20:24:40 Steve Franks wrote:
>> > Hi,
>> >
>> > You can try:
>> > sysctl hw.usb.uslcom.debug=15
>>
>
> Hi,
>
> I see that your USB HUB is HIGH speed, while your device is FULL speed. That
> means the USB HUB will translate the speed from HIGH to FULL speed, which
> might be one part of the problem. Could you try another branded USB 2.0 HUB
> and see if the problem is the same?
>
> --HPS
>
Hans,
Oldest hub in the office (which happens also to be high-speed) does
the same behavior, although it gets significantly farther thru the
process before it locks up (see below).
Steve
ugen4.6: <vendor 0x0409> at usbus4
uhub7: <vendor 0x0409 product 0x0050, class 9/0, rev 2.00/1.00, addr
6> on usbus4
uhub7: 7 ports with 7 removable, self powered
ugen4.7: <Silicon Labs> at usbus4
uslcom_probe:221:
uslcom_attach:242:
uslcom0: <CP2103 USB to UART Bridge Controller> on usbus4
uslcom_set_dtr:332: onoff = 1
uslcom_set_rts:356: onoff = 1
uslcom_set_dtr:332: onoff = 0
uslcom_set_rts:356: onoff = 0
uslcom_get_status:445:
uslcom_param:388:
uslcom_param:388:
uslcom_set_dtr:332: onoff = 0
uslcom_set_rts:356: onoff = 1
uslcom_set_dtr:332: onoff = 1
uslcom_set_rts:356: onoff = 1
uslcom_write_callback:485: actlen = 1
uslcom_write_callback:485: actlen = 13
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 8
uslcom_write_callback:485: actlen = 2
uslcom_write_callback:485: actlen = 2
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 18
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 7
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 7
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 23
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 18
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 23
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 18
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 7
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 7
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 24
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 18
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 7
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 7
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 7
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 7
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 24
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 6
uslcom_write_callback:485: actlen = 18
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 7
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 7
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 7
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_write_callback:485: actlen = 62
uslcom_param:388:
uslcom_set_dtr:332: onoff = 0
uslcom_set_rts:356: onoff = 1
FYI, here's the actual output of the loader program, it's a pretty
common program in the OSS embedded micro world:
lpc21isp -control -controlswap -controlinv Main.hex /dev/cuaU0 230400 14745
lpc21isp version 1.79
File Main.hex:
loaded...
converted to binary format...
image size : 202092
Image size : 202092
Synchronizing (ESC to abort). OK
Read bootcode version: 12
2
Read part ID: LPC2138, 512 kiB ROM / 32 kiB SRAM (0x2FF25)
Will start programming at Sector 1 if possible, and conclude with
Sector 0 to ensure that checksum is written last.
Erasing sector 0 first, to invalidate checksum. OK
Sector 1: ...............................................................................................
Sector 2: ...............................................................................................
Sector 3: ...............................................................................................
Sector 4: ...............................................................................................
Sector 5: .......................Error on writing block_CRC (1)
gmake: *** [burn] Error 7
>Exit code: 2
------------------------------
End of freebsd-usb Digest, Vol 281, Issue 2
*******************************************