> BTW: The USB-analyzer showed a very interesting init sequence for Windows:
>
> 20ms USB-Reset
> Get device descriptor (64bytes)
> 15ms USB-Reset
> Set address
> Get device descriptor
> ...
Where Linux doesn't do the first two, and doesn't do resets quite like that.
The USB spec certainly allow
Hi!
> > However, the modules are properly detected in Windows 2000, so Linux
> >apparently does something wrong.
> >
> Yeah, I don't have these problems under Win98 or WinME either.
>
> Speaking of hub problems, has anyone else noticed that Linux never
> reports overcurrent conditions? I can pl
Georg Acher wrote:
>
> Hi,
> I'm currently fighting with the timing in hub.c...
>
> The Polestar USB audio device (with the Philips UDA1321) doesn't work anymore
> with the current hub code (it worked a long time ago), the result after a
> plugin is the usual "USB device not accepting new addres
Mark McClelland wrote:
>
> Georg Acher wrote:
>
> >Hi,
> >I'm currently fighting with the timing in hub.c...
> >
> >The Polestar USB audio device (with the Philips UDA1321) doesn't work anymore
> >with the current hub code (it worked a long time ago), the result after a
> >plugin is the usual "U
Hi,
I have worked with both the Philips UDA1321 and UDA1325. They both have
very long reset times, during which they do not respond to bus traffic. I
think it is around 300ms of reset times. I don't recall if it was both from
power on AND USB bus reset or just power on. Windows retries enumera
Georg Acher wrote:
>Hi,
>I'm currently fighting with the timing in hub.c...
>
>The Polestar USB audio device (with the Philips UDA1321) doesn't work anymore
>with the current hub code (it worked a long time ago), the result after a
>plugin is the usual "USB device not accepting new address". This
