Re: CFT: major update to if_ure (patch did not apply cleanly for head -r363510) (example PowerMac problem?)

2020-07-28 Thread Mark Millard
[I figured out how it appeared to go faster than USB2.]

On 2020-Jul-27, at 20:07, Mark Millard  wrote:

> On 2020-Jul-27, at 19:07, Mark Millard  wrote:
> 
>> On 2020-Jul-27, at 18:44, John-Mark Gurney  wrote:
>> 
>>> Mark Millard wrote this message on Mon, Jul 27, 2020 at 17:15 -0700:
 On 2020-Jul-27, at 16:43, Mark Millard  wrote:
 
> On 2020-Jul-26, at 18:20, John-Mark Gurney  wrote:
> 
>> Mark Millard wrote this message on Sat, Jul 25, 2020 at 19:13 -0700:
>>> For reference for what applying the patch
>>> reported (see Hunk #14):
>> 
>> Ok, updated it to be relative to r363583...
>> 
>> I had made a white spcae commit to if_ure.c, but hadn't made the
>> patch relative to it after that commit.. should work now..
> 
> I updated an old PowerMac G5 (2 sockets/2 cores each) to
> head -r363590 with the update patch and tjen plugged in the
> USB EtherNet device. The result (extracted from dmesg -a)
> was:
> 
> usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored)
> usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
> USB_ERR_TIMEOUT
> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, 
> ignored)
> usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
> USB_ERR_TIMEOUT
> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, 
> ignored)
> usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
> USB_ERR_TIMEOUT
> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, 
> ignored)
> usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
> USB_ERR_TIMEOUT
> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, 
> ignored)
> usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
> USB_ERR_TIMEOUT
> ugen2.2:  at usbus2 (disconnected)
> uhub_reattach_port: could not allocate new device
> 
> Unfortunately, I'd not tried a PowerMac with the type of
> device before the update. I do not know if the above is
> new behavior or not.
> 
> The PowerMac is big-endian, which is what got me to think
> about trying it there. The PowerMac is also 64-bit running
> a 64-bit FreeBSD. Its USB is 2.0.
> 
> (It also has 2 GigaBit EtherNet ports of its own so I'm not
> likely to use a USB device outside special testing.)
> 
 
 I tried what normally shows as an axge0, but
 trying on the PowerMac G5. It got the same sort
 of messages as above. The problem does not seem
 to be tied to your patch.
 
 It does prevent my testing the patch on the G5.
>>> 
>>> Yeah, I was going to say that the above messages are before any of
>>> may changes get run, so it's unlikely a problem w/ my patch...
>>> If the USB device can't get an address on the bus, then it can't
>>> even ask what type of device it is to load the driver.
>>> 
>>> Thanks for trying though, maybe someone on the -powerpc list knows
>>> of a fix for that.
>>> 
>> 
>> Turns out that having:
>> 
>> hw.usb.xhci.use_polling=1
>> 
>> in /boot/loader.conf allowed the old PowerMac context to
>> get:
>> 
>> ugen2.2:  at usbus2
>> ure0 numa-domain 0 on uhub2
>> ure0:  on 
>> usbus2
>> miibus2:  numa-domain 0 on ure0
>> rgephy0:  PHY 0 on miibus2
>> rgephy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 
>> 1000baseT-FDX, 1000baseT-FDX-master, auto
>> ue0:  on ure0
>> ue0: Ethernet address: ###
>> ue0: link state changed to DOWN
>> 
>> and:
>> 
>> ue0: flags=8843 metric 0 mtu 1500
>>  
>> options=68009b
>>  ether ###
>>  inet 192.168.1.149 netmask 0xff00 broadcast 192.168.1.255
>>  media: Ethernet autoselect (1000baseT )
>>  status: active
>>  nd6 options=29
>> 
>> So, with that context, . . .
>> (the two directions are widely mismatched)
>> 
>> . . .
> 
> The above is very odd for USB2 since USB2 is limited to
> 480Mbits/sec, if I understand right. May be it is a mode
> of use that is not getting data to send from USB
> regularly at all, say internally generated data or
> constant/repeated data only loaded from USB once?
> 
> If yes, then comparing to receiving is not useful and
> it need not be useful for comparing to data that does
> come from USB transfers.
> 
> I suppose another possibility is that it is an error
> that it appears to be going as fast as it appears
> above.

I isolated the problem: it was not really using
192.168.1.149, but instead 192.168.1.145 (the
builtin bge0). This is despite the -N and what
the output reported. FYI:

bge0: flags=8843 metric 0 mtu 1500

options=8009b
###
inet 192.168.1.145 netmask 0xff00 broadcast 192.168.1.255
media: Ethernet autoselect (1000baseT )
status: active
nd6 options=23

ue0: flags=8843 metric 0 mtu 1500

options=68009b
###
inet 192.168.1.149 netmask 0xff

Re: CFT: major update to if_ure (patch did not apply cleanly for head -r363510) (example PowerMac problem?)

2020-07-28 Thread Mark Millard
On 2020-Jul-27, at 19:07, Mark Millard  wrote:

> On 2020-Jul-27, at 18:44, John-Mark Gurney  wrote:
> 
>> Mark Millard wrote this message on Mon, Jul 27, 2020 at 17:15 -0700:
>>> On 2020-Jul-27, at 16:43, Mark Millard  wrote:
>>> 
 On 2020-Jul-26, at 18:20, John-Mark Gurney  wrote:
 
> Mark Millard wrote this message on Sat, Jul 25, 2020 at 19:13 -0700:
>> For reference for what applying the patch
>> reported (see Hunk #14):
> 
> Ok, updated it to be relative to r363583...
> 
> I had made a white spcae commit to if_ure.c, but hadn't made the
> patch relative to it after that commit.. should work now..
 
 I updated an old PowerMac G5 (2 sockets/2 cores each) to
 head -r363590 with the update patch and tjen plugged in the
 USB EtherNet device. The result (extracted from dmesg -a)
 was:
 
 usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored)
 usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
 USB_ERR_TIMEOUT
 usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, 
 ignored)
 usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
 USB_ERR_TIMEOUT
 usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, 
 ignored)
 usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
 USB_ERR_TIMEOUT
 usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, 
 ignored)
 usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
 USB_ERR_TIMEOUT
 usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, 
 ignored)
 usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
 USB_ERR_TIMEOUT
 ugen2.2:  at usbus2 (disconnected)
 uhub_reattach_port: could not allocate new device
 
 Unfortunately, I'd not tried a PowerMac with the type of
 device before the update. I do not know if the above is
 new behavior or not.
 
 The PowerMac is big-endian, which is what got me to think
 about trying it there. The PowerMac is also 64-bit running
 a 64-bit FreeBSD. Its USB is 2.0.
 
 (It also has 2 GigaBit EtherNet ports of its own so I'm not
 likely to use a USB device outside special testing.)
 
>>> 
>>> I tried what normally shows as an axge0, but
>>> trying on the PowerMac G5. It got the same sort
>>> of messages as above. The problem does not seem
>>> to be tied to your patch.
>>> 
>>> It does prevent my testing the patch on the G5.
>> 
>> Yeah, I was going to say that the above messages are before any of
>> may changes get run, so it's unlikely a problem w/ my patch...
>> If the USB device can't get an address on the bus, then it can't
>> even ask what type of device it is to load the driver.
>> 
>> Thanks for trying though, maybe someone on the -powerpc list knows
>> of a fix for that.
>> 
> 
> Turns out that having:
> 
> hw.usb.xhci.use_polling=1
> 
> in /boot/loader.conf allowed the old PowerMac context to
> get:
> 
> ugen2.2:  at usbus2
> ure0 numa-domain 0 on uhub2
> ure0:  on 
> usbus2
> miibus2:  numa-domain 0 on ure0
> rgephy0:  PHY 0 on miibus2
> rgephy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 
> 1000baseT-FDX, 1000baseT-FDX-master, auto
> ue0:  on ure0
> ue0: Ethernet address: ###
> ue0: link state changed to DOWN
> 
> and:
> 
> ue0: flags=8843 metric 0 mtu 1500
>   
> options=68009b
>   ether ###
>   inet 192.168.1.149 netmask 0xff00 broadcast 192.168.1.255
>   media: Ethernet autoselect (1000baseT )
>   status: active
>   nd6 options=29
> 
> So, with that context, . . .
> (the two directions are widely mismatched)
> 
> # iperf3 -c 192.168.1.120 -B 192.168.1.149 --get-server-output
> Connecting to host 192.168.1.120, port 5201
> [  5] local 192.168.1.149 port 31020 connected to 192.168.1.120 port 5201
> [ ID] Interval   Transfer Bitrate Retr  Cwnd
> [  5]   0.00-1.00   sec   113 MBytes   949 Mbits/sec   12564 KBytes   
> [  5]   1.00-2.00   sec   112 MBytes   941 Mbits/sec   98549 KBytes   
> [  5]   2.00-3.00   sec   113 MBytes   944 Mbits/sec   94   1.06 MBytes   
> [  5]   3.00-4.00   sec   112 MBytes   942 Mbits/sec   96719 KBytes   
> [  5]   4.00-5.00   sec   112 MBytes   941 Mbits/sec   98883 KBytes   
> [  5]   5.00-6.00   sec   112 MBytes   941 Mbits/sec   93439 KBytes   
> [  5]   6.00-7.00   sec   112 MBytes   942 Mbits/sec   93221 KBytes   
> [  5]   7.00-8.00   sec   112 MBytes   941 Mbits/sec   96419 KBytes   
> [  5]   8.00-9.00   sec   112 MBytes   941 Mbits/sec   94632 KBytes   
> [  5]   9.00-10.00  sec   112 MBytes   941 Mbits/sec   97175 KBytes   
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval   Transfer Bitrate Retr
> [  5]   0.00-10.00  sec  1.10 GBytes   942 Mbits/sec  871 sender
> [  5]   0.00

Re: CFT: major update to if_ure (patch did not apply cleanly for head -r363510) (example PowerMac problem?)

2020-07-27 Thread Mark Millard



On 2020-Jul-27, at 18:44, John-Mark Gurney  wrote:

> Mark Millard wrote this message on Mon, Jul 27, 2020 at 17:15 -0700:
>> On 2020-Jul-27, at 16:43, Mark Millard  wrote:
>> 
>>> On 2020-Jul-26, at 18:20, John-Mark Gurney  wrote:
>>> 
 Mark Millard wrote this message on Sat, Jul 25, 2020 at 19:13 -0700:
> For reference for what applying the patch
> reported (see Hunk #14):
 
 Ok, updated it to be relative to r363583...
 
 I had made a white spcae commit to if_ure.c, but hadn't made the
 patch relative to it after that commit.. should work now..
>>> 
>>> I updated an old PowerMac G5 (2 sockets/2 cores each) to
>>> head -r363590 with the update patch and tjen plugged in the
>>> USB EtherNet device. The result (extracted from dmesg -a)
>>> was:
>>> 
>>> usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored)
>>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
>>> USB_ERR_TIMEOUT
>>> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, 
>>> ignored)
>>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
>>> USB_ERR_TIMEOUT
>>> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, 
>>> ignored)
>>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
>>> USB_ERR_TIMEOUT
>>> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, 
>>> ignored)
>>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
>>> USB_ERR_TIMEOUT
>>> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, 
>>> ignored)
>>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
>>> USB_ERR_TIMEOUT
>>> ugen2.2:  at usbus2 (disconnected)
>>> uhub_reattach_port: could not allocate new device
>>> 
>>> Unfortunately, I'd not tried a PowerMac with the type of
>>> device before the update. I do not know if the above is
>>> new behavior or not.
>>> 
>>> The PowerMac is big-endian, which is what got me to think
>>> about trying it there. The PowerMac is also 64-bit running
>>> a 64-bit FreeBSD. Its USB is 2.0.
>>> 
>>> (It also has 2 GigaBit EtherNet ports of its own so I'm not
>>> likely to use a USB device outside special testing.)
>>> 
>> 
>> I tried what normally shows as an axge0, but
>> trying on the PowerMac G5. It got the same sort
>> of messages as above. The problem does not seem
>> to be tied to your patch.
>> 
>> It does prevent my testing the patch on the G5.
> 
> Yeah, I was going to say that the above messages are before any of
> may changes get run, so it's unlikely a problem w/ my patch...
> If the USB device can't get an address on the bus, then it can't
> even ask what type of device it is to load the driver.
> 
> Thanks for trying though, maybe someone on the -powerpc list knows
> of a fix for that.
> 

Turns out that having:

hw.usb.xhci.use_polling=1

in /boot/loader.conf allowed the old PowerMac context to
get:

ugen2.2:  at usbus2
ure0 numa-domain 0 on uhub2
ure0:  on usbus2
miibus2:  numa-domain 0 on ure0
rgephy0:  PHY 0 on miibus2
rgephy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 
1000baseT-FDX-master, auto
ue0:  on ure0
ue0: Ethernet address: ###
ue0: link state changed to DOWN

and:

ue0: flags=8843 metric 0 mtu 1500

options=68009b
ether ###
inet 192.168.1.149 netmask 0xff00 broadcast 192.168.1.255
media: Ethernet autoselect (1000baseT )
status: active
nd6 options=29

So, with that context, . . .
(the two directions are widely mismatched)

# iperf3 -c 192.168.1.120 -B 192.168.1.149 --get-server-output
Connecting to host 192.168.1.120, port 5201
[  5] local 192.168.1.149 port 31020 connected to 192.168.1.120 port 5201
[ ID] Interval   Transfer Bitrate Retr  Cwnd
[  5]   0.00-1.00   sec   113 MBytes   949 Mbits/sec   12564 KBytes   
[  5]   1.00-2.00   sec   112 MBytes   941 Mbits/sec   98549 KBytes   
[  5]   2.00-3.00   sec   113 MBytes   944 Mbits/sec   94   1.06 MBytes   
[  5]   3.00-4.00   sec   112 MBytes   942 Mbits/sec   96719 KBytes   
[  5]   4.00-5.00   sec   112 MBytes   941 Mbits/sec   98883 KBytes   
[  5]   5.00-6.00   sec   112 MBytes   941 Mbits/sec   93439 KBytes   
[  5]   6.00-7.00   sec   112 MBytes   942 Mbits/sec   93221 KBytes   
[  5]   7.00-8.00   sec   112 MBytes   941 Mbits/sec   96419 KBytes   
[  5]   8.00-9.00   sec   112 MBytes   941 Mbits/sec   94632 KBytes   
[  5]   9.00-10.00  sec   112 MBytes   941 Mbits/sec   97175 KBytes   
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bitrate Retr
[  5]   0.00-10.00  sec  1.10 GBytes   942 Mbits/sec  871 sender
[  5]   0.00-10.62  sec  1.10 GBytes   887 Mbits/sec  receiver

Server output:
---
Server listening on 5201
--

Re: CFT: major update to if_ure (patch did not apply cleanly for head -r363510) (example PowerMac problem?)

2020-07-27 Thread Mark Millard
On 2020-Jul-27, at 16:43, Mark Millard  wrote:

> On 2020-Jul-26, at 18:20, John-Mark Gurney  wrote:
> 
>> Mark Millard wrote this message on Sat, Jul 25, 2020 at 19:13 -0700:
>>> For reference for what applying the patch
>>> reported (see Hunk #14):
>> 
>> Ok, updated it to be relative to r363583...
>> 
>> I had made a white spcae commit to if_ure.c, but hadn't made the
>> patch relative to it after that commit.. should work now..
> 
> I updated an old PowerMac G5 (2 sockets/2 cores each) to
> head -r363590 with the update patch and tjen plugged in the
> USB EtherNet device. The result (extracted from dmesg -a)
> was:
> 
> usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored)
> usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
> USB_ERR_TIMEOUT
> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored)
> usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
> USB_ERR_TIMEOUT
> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored)
> usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
> USB_ERR_TIMEOUT
> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored)
> usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
> USB_ERR_TIMEOUT
> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored)
> usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
> USB_ERR_TIMEOUT
> ugen2.2:  at usbus2 (disconnected)
> uhub_reattach_port: could not allocate new device
> 
> Unfortunately, I'd not tried a PowerMac with the type of
> device before the update. I do not know if the above is
> new behavior or not.
> 
> The PowerMac is big-endian, which is what got me to think
> about trying it there. The PowerMac is also 64-bit running
> a 64-bit FreeBSD. Its USB is 2.0.
> 
> (It also has 2 GigaBit EtherNet ports of its own so I'm not
> likely to use a USB device outside special testing.)
> 

I tried what normally shows as an axge0, but
trying on the PowerMac G5. It got the same sort
of messages as above. The problem does not seem
to be tied to your patch.

It does prevent my testing the patch on the G5.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: CFT: major update to if_ure (patch did not apply cleanly for head -r363510) (example PowerMac problem?)

2020-07-27 Thread Mark Millard



On 2020-Jul-26, at 18:20, John-Mark Gurney  wrote:

> Mark Millard wrote this message on Sat, Jul 25, 2020 at 19:13 -0700:
>> For reference for what applying the patch
>> reported (see Hunk #14):
> 
> Ok, updated it to be relative to r363583...
> 
> I had made a white spcae commit to if_ure.c, but hadn't made the
> patch relative to it after that commit.. should work now..

I updated an old PowerMac G5 (2 sockets/2 cores each) to
head -r363590 with the update patch and tjen plugged in the
USB EtherNet device. The result (extracted from dmesg -a)
was:

usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored)
usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
USB_ERR_TIMEOUT
usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored)
usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
USB_ERR_TIMEOUT
usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored)
usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
USB_ERR_TIMEOUT
usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored)
usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
USB_ERR_TIMEOUT
usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored)
usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
USB_ERR_TIMEOUT
ugen2.2:  at usbus2 (disconnected)
uhub_reattach_port: could not allocate new device

Unfortunately, I'd not tried a PowerMac with the type of
device before the update. I do not know if the above is
new behavior or not.

The PowerMac is big-endian, which is what got me to think
about trying it there. The PowerMac is also 64-bit running
a 64-bit FreeBSD. Its USB is 2.0.

(It also has 2 GigaBit EtherNet ports of its own so I'm not
likely to use a USB device outside special testing.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: CFT: major update to if_ure (patch did not apply cleanly for head -r363510) (example PowerMac problem?)

2020-07-27 Thread John-Mark Gurney
Mark Millard wrote this message on Mon, Jul 27, 2020 at 17:15 -0700:
> On 2020-Jul-27, at 16:43, Mark Millard  wrote:
> 
> > On 2020-Jul-26, at 18:20, John-Mark Gurney  wrote:
> > 
> >> Mark Millard wrote this message on Sat, Jul 25, 2020 at 19:13 -0700:
> >>> For reference for what applying the patch
> >>> reported (see Hunk #14):
> >> 
> >> Ok, updated it to be relative to r363583...
> >> 
> >> I had made a white spcae commit to if_ure.c, but hadn't made the
> >> patch relative to it after that commit.. should work now..
> > 
> > I updated an old PowerMac G5 (2 sockets/2 cores each) to
> > head -r363590 with the update patch and tjen plugged in the
> > USB EtherNet device. The result (extracted from dmesg -a)
> > was:
> > 
> > usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored)
> > usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
> > USB_ERR_TIMEOUT
> > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, 
> > ignored)
> > usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
> > USB_ERR_TIMEOUT
> > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, 
> > ignored)
> > usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
> > USB_ERR_TIMEOUT
> > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, 
> > ignored)
> > usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
> > USB_ERR_TIMEOUT
> > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, 
> > ignored)
> > usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
> > USB_ERR_TIMEOUT
> > ugen2.2:  at usbus2 (disconnected)
> > uhub_reattach_port: could not allocate new device
> > 
> > Unfortunately, I'd not tried a PowerMac with the type of
> > device before the update. I do not know if the above is
> > new behavior or not.
> > 
> > The PowerMac is big-endian, which is what got me to think
> > about trying it there. The PowerMac is also 64-bit running
> > a 64-bit FreeBSD. Its USB is 2.0.
> > 
> > (It also has 2 GigaBit EtherNet ports of its own so I'm not
> > likely to use a USB device outside special testing.)
> > 
> 
> I tried what normally shows as an axge0, but
> trying on the PowerMac G5. It got the same sort
> of messages as above. The problem does not seem
> to be tied to your patch.
> 
> It does prevent my testing the patch on the G5.

Yeah, I was going to say that the above messages are before any of
may changes get run, so it's unlikely a problem w/ my patch...
If the USB device can't get an address on the bus, then it can't
even ask what type of device it is to load the driver.

Thanks for trying though, maybe someone on the -powerpc list knows
of a fix for that.

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"