> > I could easily imagine the slower CPU changed the timing in > > such a way that the bug in that DSL driver showed up, where > > previously it was for some reason masked. > > > > I've seen that phenomenon before... the fact that the bug is > > _detected_ in the OHCI code has nothing to do with where the > > actual bug is located. > > I have discovered something new. The old board I used has got a USB > connector on board, although it was never supplied with an internal > cable/connectors, so I never realised until now... Turns out the onboard > USB is UHCI and the add-on card I have added is OHCI. Maybe that is were > the problem comes from?
I doubt it. Using either of the UHCI drivers will change the timings seen by your DSL driver yet again ... and I seem to recall that the UHCIs won't detect/report such bugs either. Boxes with both UHCI and OHCI, or with onboard vs addin adapters of either type, have no real reason to act particularly different. Unless the PCI is itself flakey ... a motherboard as old as you mentioned might have bugs that have gotten rare lately. > I Still thinks there is something fishy about > the PCI timings and one of the drivers. I have ordered an internal > cable/connector and will remove the add-on card and will publish the > results. The timings are likely fine, except that they combine to expose a refcounting bug. What was the name of the device driver being used for that DSL driver? I don't think you mentioned it. - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
