[PCMCIA] Solved: No USB 2.0 (ehci) in PCMCIA slot on E7110

[Andreas Mohr]

Hi,

On Tue, Aug 13, 2013 at 09:07:05PM +0200, Thomas Richter wrote:
> Andreas, and all others
> 
> >that means we're talking this one (have you had a look at Bugzilla #15014?
> >Might be useful...):
> 
> Which is too bad just because I found this approximately five
> minutes *after* making the report. And then saw the kernel
> parameter. Well, I afraid 8 hours of bisecting kernel sources when
> looking for the bug left some traces at my concentration.... (-;

Yeah, going through various modules to revert-test likely is no minor issue...


> >     O2-bridges can do read prefetch and write burst. However, for some combinations
> >     of older bridges and cards, this causes problems, so it is disabled for those
> >     bridges. Now, as some users know their setup works with the speedups enabled, a
> >     new parameter is introduced to the driver. Now, a user can specifically enable
> >     or disable these features, while the default is what we have today: detect the
> >     bridge and decide accordingly. Fixes Bugzilla entry 15014.
> 
> Is the author of the *original* bug report (15014) still reachable
> allowing you to make at least an educated guess as *when* to disable
> prefetch & burst?

Some comments there do contain the author's email address in the open,
so you could attempt to do that.


> >And of course there remains the question *why* such slow communication
> >would then cause such severe USB HC communication trouble.
> >There might be some safeguard missing there as well...
> 
> It seems to me that the bridge can otherwise not keep up with the
> ehci communications speed, but that's more a guess too.

You'd think that there are properly working wait cycles implemented
in USB HC hardware for such situations of PCI bridge implementations
not being able to keep up...
(or perhaps the USB kernel driver code is missing some checks/stalls
at some place or another?)



Hmm, and is there a difference between the PCI revision of
the original activist's lspci dump and a log that you have?


BTW, some semi-hackish way to adapt this to certain environments
might be to have a
if (have_intel_bridge_pci_id)
  speedup = true;
check.

Some drivers actually do implement such combined PCI ID checks
for rather entirely unrelated hardware in a system.
But it would obviously be more useful to get to the bottom of
this issue, if there is an issue to be corrected.


OTOH - what is your current PCI latency setting for affected hardware?
Perhaps that happens to be a relevant item here...


> What I would hope for would probably a warning when booting up the
> kernel, and probably disabling ehci on it, again with a warning and
> a hint for the kernel parameter. Just to avoid that others have to
> go through the data loss I had when just connecting an external USB
> 2 harddrive.

"USB" "data loss" - yeah, such an oh so familiar combination... (argh!)


BTW, there was no recovery possible??
extX filesystems contain many backup superblocks,
or if the MBR / partition table is gone
then one would be able to try "testdisk", etc.

Andreas Mohr