Hello,
I am not sure if I am contacting the right group (I apologize if not).
I have USB keyboard Chicony KU-8933
(lsusb):
ID 04f2:0001 Chicony Electronics Co., Ltd KU-8933 Keyboard
and in kernel 2.4.21-pre6 does not work NumLock, CapsLock and ScrollLock LEDs
(all lightning in default :
Oops in 2.5.66 when removing the module uhci_hcd
Other modules can be removed.
(Please CC me, I'm not on the list. )
command to trigger the Oops:
rmmod uhci_hcd
printing eip:
c012ee53
*pde = 0
Oops: 0002 [#1]
CPU: 0
EIP: 0060:c012ee53 Not tainted
EFLAGS: 00010002
EIP is at
Greg KH wrote:
On Thu, Mar 27, 2003 at 06:48:38PM -0800, David Brownell wrote:
This tweaks the hardware in two minor ways, being more forgiving
of what are either hardware bugs or hard-to-see driver bugs.
- Some silicon seems to mis-handle dummy qtds on occasion,
writing them into the qh and
Hi.
Here are two patches that convert the files to use C99 initializers. The
patches are against current BK.
Art Haas
= drivers/usb/input/kbtab.c 1.1 vs edited =
--- 1.1/drivers/usb/input/kbtab.c Sat Feb 22 02:07:20 2003
+++ edited/drivers/usb/input/kbtab.cWed Apr 2 06:56:26
I got a report of a problem with a high speed CD-ROM that
could be reproduced by a simple loop:
dd if=/dev/scd0 of=cdrom.iso
cmp /dev/scd0 cdrom.iso
The failure was reported on 2.4, so I wanted to know if it
showed up on 2.5 too. (Since usb-storage on 2.5 seems to
be more robust.) So I tried
On Wed, 2 Apr 2003, David Brownell wrote:
I got a report of a problem with a high speed CD-ROM that
could be reproduced by a simple loop:
dd if=/dev/scd0 of=cdrom.iso
cmp /dev/scd0 cdrom.iso
The failure was reported on 2.4, so I wanted to know if it
showed up on 2.5 too. (Since
Hi Alan,
Alan Stern wrote:
On Wed, 2 Apr 2003, David Brownell wrote:
...
Looking at the system state, there were no requests queued
to the EHCI driver; it wasn't even doing async schedule
processing any more. And the next level up was usb-storage,
which seemed to be waiting for requests too ...
On Wed, 2 Apr 2003, David Brownell wrote:
I generally find the usb-storage messages to be unusable; there's
so much this worked right, that too, hey so did this going on
(surely at least a dozen per request!) that any messages about
things that went wrong get drowned in the noise. And those
Alan Stern wrote:
On Wed, 2 Apr 2003, David Brownell wrote:
I generally find the usb-storage messages to be unusable; there's
so much this worked right, that too, hey so did this going on
(surely at least a dozen per request!) that any messages about
things that went wrong get drowned in the
This patch:
- Makes usbnet pay attention to device descriptors in
the most common cases; there's less need to embed device
hardware details. This lets it work with high speed
devices, and should help interop with the newer ARM/PXA
kernels usb-eth (same vid/pid, but different
On Wed, 2 Apr 2003, David Brownell wrote:
Well, all the evidence points to it being quiescent. It would
be more useful to teach usb-storage to dump useful state in
a sysfs file, so it can be accessed on-demand rather than
needing to be stored in dmesg output ... :)
That's an intriguing
, [EMAIL PROTECTED], 20030402 */
+/* based on a posting by Mikko Ahonen found on the web */
+#ifdef CONFIG_USB_STORAGE_PENTAX_OPTIO
+UNUSUAL_DEV( 0x0a17, 0x0004, 0x, 0x,
+PENTAX,
+DIGITAL_CAMERA,
+US_SC_8070, US_PR_CB, NULL,
+US_FL_MODE_XLATE|US_FL_FIX_INQUIRY ),
+#endif
+
#ifdef
On Wed, 2 Apr 2003, David Brownell wrote:
Alan Stern wrote:
What sort of information would it be useful to expose in this way? A few
possibilities that would be easy to implement (stored in the per-device
data structure in usb-storage) are:
1. The current state of the driver:
Pete Zaitcev wrote:
From: David Brownell [EMAIL PROTECTED]
Date: Wed, 02 Apr 2003 07:52:05 -0800
I got a report of a problem with a high speed CD-ROM that
could be reproduced by a simple loop:
dd if=/dev/scd0 of=cdrom.iso
cmp /dev/scd0 cdrom.iso
The failure was reported on 2.4, so I wanted
So far as I know, usbfs was never documented ... so
here's a patch with some text I've had sitting around,
merging it into the other USB kerneldoc.
It should be accurate, down to the warnings about why
not to use several of the calls, though cross-review
with the code would be good too. A notable
3. Address of the current scsi_cmnd block (if any).
Is the actual address at all useful?
What's important is which request, and the pointer serves
as a good enough ID in most contexts. Especially if this
code ever starts to queue more than one request at a time.
4. Count values for
Related to a comment from Pete Zaitcev:
... Make sure ... that you
do not have any of this crap:
p = kmalloc(N, in_interrupt()? GFP_ATOMIC: GFP_NOIO);
-- it's a sure way to deadlock
This patch fixes up two similar places. The fix is actually
pessimizing behavior. In 2.5 the API passes the
Alan Stern wrote:
On Wed, 2 Apr 2003, David Brownell wrote:
Well, all the evidence points to it being quiescent. It would
be more useful to teach usb-storage to dump useful state in
a sysfs file, so it can be accessed on-demand rather than
needing to be stored in dmesg output ... :)
That's an
18 matches
Mail list logo
