Hi Alan,
Thank you for reply. I can certainly appreciate the amount of
differences that might be in 2.6.34 compared to 2.6.18.
However, my 'problem' is the O/S I'm using is Oracle Enterprise
Linux(5.5) which has a lot of RedHat stuff, but then bundled and
packaged under Oracle brand.
And the OEL5.5 latest available kernel is 2.6.18, so not sure if I
should (or could) go outside oracle to obtain and try install newer
kernel package.
Additional research and data I found on my system might help shed some light:
I saved the 'dmesg' output to text and searched for relevant lines
(copied here):
<snippet from dmesg.txt>
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
...
input: No brand 2Port KVMSwicther as /class/input/input2 <<
misspelled exactly as in dmesg
input: USBHID v1.10 Keyboard [No brand 2Port KVMSwictch] on
usb-0000:00:0f.2-1.3
drivers/usb/input/hid-core.c: couldn't find an input interrupt endpoint
<output from $ lsusb>
Bus 001 Device 005: ID 105d:55a2 Uni Class Technology Co., 2Port
KVMSwitcher << note, spelled correctly in this output
Bus 001 Device 002: ID 058f:9254 Alcor Micro Corp. Hub
Bus 001 Device 001: ID 0000:0000
Bus 001 Device 003: ID 03f0:0024 Hewlett-Packard KU-0316 Keyboard
Bus 001 Device 004: ID 046d:c016 Logitech, Inc. M-UV69a/HP M-UV96
Optical Wheel Mouse
I included this data as the 'lsusb' output does identify the correct
keyboard and mouse, but also names the KVM switch (even though the
actual manufacturer is TrendNet TK-207 model); but odd that the 'dmesg'
output says "No brand"
Not sure if there is a correlation, but just my observations.
Would this "tell" anything to someone who understands this all?
I can't find it now, but one google hit suggested a possible fix is to
run (as root): mount usbfs
> there wasn't much info on this, suggestion, so I've not tried it yet
> would you recommend it ?
thank you very much!
shane.//
Quoting Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>:
Please use Reply-To-All so that your messages will be seen on the
mailing list.
On Mon, 21 Jun 2010 shane000@xxxxxxxxxxxxxx wrote:
> Hi Alan,
> Thank you very much for taking time to reply.
> I don't have the link to the original posting and can't recall what
> 'original solution' was;
> > but, i remember when I read the original posting, it did not have
> solution for my issue.
>
> You recommended upgrade kernel to 2.6.34;
> > I verified current kernel is 2.6.18
> > if you say "Linux does not turn off power to USB ports," how would
> a newer version kernel affect/fix the problem?
I don't know. But there have been so many changes between 2.6.18 and
2.6.34 (4 years of development!) that anything is possible.
Think of it like this: There are 16 Linux kernel releases from 2.6.18
to 2.6.34. That's more than the number of releases of Windows between
Windows-95 and Windows 7. (The analogy isn't really fair, but it does
make a point.)
> > if the O/S does not turn power off, (but the power is definitely
> 'off' as neither the keyboard or optical mouse has any lights after
> returning context from windows side to linux), then that implies the
> loss of power to the keyboard and mouse if caused by the TrendNet
> switch?
That's right. But are you certain the power is truly off? The fact
that the LEDs are off doesn't prove anything, because the LEDs don't
get turned on until the power is on _and_ the keyboard or mouse is
configured. It's possible that the power is on but the devices aren't
configured.
> Please correct me if my logic trail is incorrect, or if you can provide
> other insight.
> thank you.
> shane.//
When you build a newer kernel, I suggest you enable CONFIG_USB_DEBUG
and see what shows up in the dmesg log.
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
