Alan Stern wrote:
> Sven-Olof, have you tried combining all three patches (turn off fsbr, fix
> up usb-storage, and use Windows-style initialization) on the UHCI machine?
I combined the patches from these messages
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=109111899830973
drive
Alan Stern wrote:
> > I'd really expect that a more MSFT-friendlly approach would work.
>
> Sven-Olof, do you still have patch for that? It's the one in
>
> http://marc.theaimsgroup.com/?l=linux-usb-users&m=109069803813114
>
> Maybe it'll work a little better, maybe not.
I have tried this patc
Alan Stern wrote:
> On this computer, you could try out the OHCI controller simply by plugging
> the camera into the USB 2.0 port after unloading the ehci_hcd driver.
I have tried this. Linux does not recognize the camera. Here is the dmesg
output.
ohci_hcd :00:0b.1: remote wakeup
ohci_hcd 0
Alan Stern wrote:
> > After that I can start to copy files. Coping files seems to work fine as
> > long as I dont issue any dmesg commands. It has happend to me twice when I run
> > tests with these patches that exactly when I issue a dmesg command the file
> > copy fails. See the debug messages be
Alan Stern wrote:
> In the meantime, there are two new patches below. The first is a
> replacement for the earlier UHCI driver patch. It should do about the
> same thing, but this one is suitable for submission (unlike the other,
> which was purely experimental). The second patch is for usb-s
Alan Stern wrote:
> Here's another possibility. I've seen this with a few embedded
> USB-Bluetooth interfaces, and maybe your cameras have the same problem.
> Those devices couldn't handle Full-Speed-Bandwidth-Reclamation for control
> messages. The patch below alters the UHCI driver to disable
Hi,
Alan Stern wrote:
> Below is a patch that adds two 5000ms delays to the hub driver, one in
> hub_port_reset() and one in hub_port_connect_change(). This patch is
> meant to apply on top of the previous one. I'm not sure where the delay
> needs to be (assuming it's needed at all!) so I put
Hi,
Alan Stern wrote:
> I recently got some information about how Windows assigns device addresses
> and reads device descriptors. Below is an experimental patch for 2.6.7;
> it changes the hub driver so that the second time it tries to assign the
> address it will use the Windows strategy. P
