Am Dienstag, 26. September 2006 09:45 schrieb James:
If i blacklist cdc-ether and cdc-acm, I cannot reproduce the error,
and my phone works fine as a usb-storage device.
Please black list each driver independently. It looks like cdc-ether,
but verification is needed. Secondly, if you report a
Hey
Attempting to connect and use my Nokia 6280 with the supplied Nokia
USB cable (reads: 'Type: CA-53') causes the kernel to through BUG's,
and has on occasion caused a complete lock up of the system.
This is running 2.6.18, and also occurs on the 2.6.17 series, which
was what I was using when
Am Montag, 25. September 2006 20:22 schrieb Ryan Moszynski:
here is the info you requested. i got it with my 2.6.15 running as
well as 2.6.18. the dmesg's are different but the lsusb's are the
same.
just a guess, i think that this line from lsusb
##
bMaxPacketSize064
##
should be
Hi,
I have a multifunction PCMCIA card hosting a USB and UART port.
Basically I am facing two problems while doing some operations.
1. PCMCIA card removal while bulk transfer through USB key in progress
causes oops and crashes. The log is given bellow.
Unable to handle kernel paging request
I'm gutted, distraught and close to tears. But most of all I'm proud. The lads playedchampions was over for another four years.
Gerrard was far more impressive than Lampard in Germany, and McClaren mustArgentina lit up Group C with some great efforts, most notably Esteban Cambiasso'sInternet2
On Mon, 25 Sep 2006, Steve Calfee wrote:
This indicates that the problem is a small hardware incompatibility,
as I have said before.
We attached a High Speed hub to our system and inserted this disk in the
hub. The device works perfectly in such mode.
This is more than a small hardware
Hello,
I'm working with PXA27x hardware and going to check USB ethernet gadget (RNDIS
mode)
with 2.6.18 on PC host. After a short investigation, I was stucked because:
1) help on CONFIG_USB_ETH_RNDIS (taken from drivers/usb/gadget/Kconfig) says
that
RNDIS-aware configuration will be
pankaj chauhan wrote:
dave,
Thanks alot for useful information.
Is there any way in which i can verify that is it the
fault of device (i.e device is trying to draw more
current) or my host controller is faulty (as you
mentioned that some Host controllers behave in such
way)?
lsusb
On 9/26/06, Oliver Neukum [EMAIL PROTECTED] wrote:
Am Dienstag, 26. September 2006 09:45 schrieb James:
If i blacklist cdc-ether and cdc-acm, I cannot reproduce the error,
and my phone works fine as a usb-storage device.
Please black list each driver independently. It looks like cdc-ether,
On Tue, 2006-09-26 at 17:35 +1200, Shane wrote:
I have a USB webcam with no linux driver G
My windows driver names the device and driver as
CMOS 100K-X Rev 2.01.0025.0 #2
lsusb sees the device as
Bus 001 Device 007: ID 0572:0001 Conexant Systems (Rockwell), Inc. Ezcam II
WebCam
On Tue, 26 Sep 2006, Lisa Ray wrote:
Hi
I have HID device which has 2 interrupt endpoints 0x81 for output and
0x02 for input. I tried hiddev ioctl approach but was unable to get any
response from device my command is 6 bytes char array {0x01 ,
0x02,'C','v',-x03,0x06,0x00}.
In case you
Hi
hub was self powered, it indicates either your device took
too much VBUS current, your host could not supply enough vbus
power, your host transceiver has a problem, OR you have a
major fussy device in receiving data.
We have couple of other 1.1 devices who works with our system in bus
Hi
hub was self powered, it indicates either your device took
too much VBUS current, your host could not supply enough vbus
power, your host transceiver has a problem, OR you have a
major fussy device in receiving data.
We have couple of other 1.1 devices who works with our system in
This patch (as791b) fixes things up to avoid compiler warnings or
errors when CONFIG_USB_SUSPEND or CONFIG_PM isn't set.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
This revises the as791 patch (fix statement with no effect) submitted
yesterday. It fixes compile problems when either
This patch (as790b) adds autostop support to ohci-hcd: the driver
will automatically stop the host controller when no devices have been
connected for at least one second. This feature is useful when the
USB autosuspend facility isn't available, such as when
CONFIG_USB_SUSPEND hasn't been set.
The fact that device A works and device B doesn't on the same
port/cables etc does not eliminate the possibility of a VBUS
power problem. All devices use different amounts of power,
have different needs on vbus rise times, and even different
+- voltage level requirements on the data
On Wednesday 27 September 2006 04:11, Gerard Klaver wrote:
On Tue, 2006-09-26 at 17:35 +1200, Shane wrote:
I have a USB webcam with no linux driver G
My windows driver names the device and driver as
CMOS 100K-X Rev 2.01.0025.0 #2
lsusb sees the device as
Bus 001 Device 007: ID
On Tue, 26 Sep 2006, Vivek Dharmadhikari wrote:
I used the patch provided by Alan to increase the no. of retries. The
patch caused the ohci hardware to retry the command 4 times in a row
instead of 3 times.
For some strange reason, the OHCI specification document doesn't say
exactly how the
Actually the device is not dead. Not at all. If it were
then the class-specific device reset (which is nothing more
than a USB control transfer) would fail.
Agreed ! I actually meant to say that data path from device to host is
somehow broken. The fact that the device always responds to
Hi,
I have a nice little USB Bar Code Scanner. It is set up as a USB device,
but I can not connect to the default control pipe. I'm thinking that
attaching the usbhid driver will help.
I have an usb mouse and keyboard which work just fine. Kernel is
2.6.15-1-486.
Here are my questions
1)
What is your key string descriptors ?
3SYSTEM USB POCKET DISK
Thanks
Nope, this is not my problem device. Also, you said in another message that
it was not dead, just ignoring transmissions. That was not my devices
problem. Congrats you found another problem device.
Regards, Steve
On Mon, 25 Sep 2006 15:40:58 -0400 (EDT)
Alan Stern [EMAIL PROTECTED] wrote:
Patch 3 is much more experimental than the first two, and probably also
more controversial (I expect David will have a lot to say about it, even
if no one else does). In fact, I won't even CC: Andrew on this one;
Hello,
This set of patches implements abstracted budgeting logic for the ehci
scheduler that both takes advantage of hardware features not currently
exploited by the current schedulers (FSTNs and sITD backpointers) and
makes a greater effort to get the niggling corner cases of scheduling
Patch is against kernels 2.6.18 through at least 2.6.18-git7
patch 1: This patch slightly refactors isoch stream cleanup such that
stream state is more persistent; it is instantiated at first transfer
and not released until endpoint shutdown. This is to isoch transfers
something persistent to
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 2: Refactors periodic schedule startup and shutdown code such
that refcounting and code is centralized. Also adds hysteresis such
that shutdown does not occur until there's one full pass through the
periodic schedule
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 3: moves scattered interrupt endpoint (periodic QH) code to one
place. Also eliminates some vestigal patterning patterning after the
async QH code. There should be no functional difference after this
patch.
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 4: modes ehci_iso_sched funtions to one place. Trivial patch
that makes no funcitonal difference.
Signed-off-by: Christopher Monty Montgomery [EMAIL PROTECTED]
---
diff -X b/Documentation/dontdiff -upr
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 5: first half of untangling intermixed ehci_iso_sched, itd and
sitd code; moves/groups scattered code into self-contained sections.
Adds kernel-doc entries for functions. This patch should result in no
functional
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 6: Continue untangling ehci_iso_sched and sitd code. Remove
ifdefs and code for EHCI_URB_TRACE within ehci-sched in preference for
later additional debugging information tailored to the new code.
Aside from removal of
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 7: slightly rearrange sitd patching and linking code flow to
simplify addition of sITD backpointer support later. This should
result in no functional difference.
Signed-off-by: Christopher Monty Montgomery [EMAIL
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 8: split frame scanning code out of the scan_periodic schedule
walking loop so that the same code can be used to scan preceeding
frame for completions when FSTN and sITD frame spanning support are
added. Add
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 9:
Standardize/unify 'period' and 'interval' values on uFrame granularity
instead of mixing frame and uframe depending on endpoint type (there's
no reason to use urb-interval directly).
Implement QH tree depth limit
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 10: Drops in complete implementation of the shadow budget
abstraction, but does not yet call this code in any way. The shadow
budget is a means of indefinitely reserving bandwidth requested by a
periodic endpoint as
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 11: adds necessary calls such that the shadow budget is actively
maintained, but the rest of the scheduler is not yet using the shadow
budget to make any decisions.
Signed-off-by: Christopher Monty Montgomery [EMAIL
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 12: Switches the existing scheduler mechanisms over to using the
shadow budget for all scheduling decisions. Removes all unused
bandwidth allocation logic from previous scheduler versions.
Signed-off-by: Christopher
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 13: Adds low-level scheduler mechanisms for linking, unlinking,
manipulating and maintaining FSTNs. Turns on shadow budget logic to
allow/use FSTNs in budgeting.
Signed-off-by: Christopher Monty Montgomery [EMAIL
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 15: This fix is not actually to ehci-hcd, but is rather a fix to
usbaudio necessitated by fixing the isoch underrun detection/reporting
in ehci. usbaudio playback nominally causes one, specific harmless
underrun in
On Tue, Sep 26, 2006 at 05:45:26PM +1000, James wrote:
Hey
Attempting to connect and use my Nokia 6280 with the supplied Nokia
USB cable (reads: 'Type: CA-53') causes the kernel to through BUG's,
and has on occasion caused a complete lock up of the system.
This is running 2.6.18, and also
38 matches
Mail list logo
