On Thu, 12 Apr 2012, Martin Mokrejs wrote:
> > The message in your log says what happened:
> >
> >> hub 2-1.2:1.0: port 1 disabled by hub (EMI?), re-enabling...
> >
> > Some sort of electrical noise caused the second hub to disable the port
> > that the keyboard was plugged into.
>
> I reproduced that again, but took 3.5" drive as I thought I am dealing with
> some "undercurrent" situation ... The external drive has its own power source,
> and turning it on and off does not trigger the issue. Only once, after I started
> up the drive and while it was spinning up its plates I plugged in the eSATA cable:
> Ah, /var/log/messages does not have all messages seen in dmesg(1). :( Are some
> written with different priority/severity?
Of course: the debug-level messages. That's part of the reason why I
always recommend that people use dmesg instead of the system log files
for kernel testing and debugging. In addition, the syslog daemon
sometimes drops messages if too many arrive too quickly.
> ata6: exception Emask 0x10 SAct 0x0 SErr 0x4040000 action 0xe frozen
> ata6: irq_stat 0x00000040, connection status changed
> ata6: SError: { CommWake DevExch }
> ata6: hard resetting link
> hub 2-1.2:1.0: port 4 disabled by hub (EMI?), re-enabling...
> usb 2-1.2.4: USB disconnect, device number 9
Unfortunately, the external hub says that is disabled the port, but
it gives no explanation of why it did so. The cause has to be some
sort of electrical noise, i.e., signals appearing on the USB data lines
at the wrong time.
> Interesting. The external USB hub has its own power supply. So once it reset the
> keyboard connection, now it reset the mouse. s it Linux making the external HUB
> to reset do you think it is the external hub itself?
Linux can't make the hub do that. This is entirely the hub's doing.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
