of how much of
the descriptor information has available the corresponding string (human
readable) representation.
--
Jiri Kosina
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?
://bugzilla.kernel.org/attachment.cgi?id=12228&action=view -- solves
your issues, right?
Stuart, did you submit this fix for upstream already please?
--
Jiri Kosina
-
This SF.net email is sponsored by: Splunk Inc.
rprised
if they would advertise remote wakeup capability ... ?
Thanks,
--
Jiri Kosina
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configur
remember
Alan saying that he triggered it on OHCI too, right?
Seemed like a timing issue - by lowering the polling timeout we were able
to make things much better, but that of course costs us more power etc.
and it's even not sure
during OLS and it seemed
quite hopeless.
A few keyboards we have been testing with seemed to be losing keypressess
when coming out of suspend (if and only if the root hub wasn't suspended
too, etc. Magic).
--
Jiri Kosina
---
it.
We have been playing with runtime autosuspend of HID devices, are
currently postponed the full support, as it turns out that many devices
don't support this feature properly (probably due to not being tested in
Windows).
--
Jir
Yes - that's correct. This patch fixes the bug. Thanks.
> Does it also fix the "dma_pool_free" error?
I believe it should -- caused by calling usb_buffer_free() with bogus
dma_addr_t, as corresponding usbhid_device has been already kfree()d.
--
Jiri Kosina
--
n behind it?
I find the blacklist sorted by quirk type more convenient - we typically
want to know "who has this particular quirk", but we generally don't care
"what quirks does this particular vendor have".
--
Jiri Kosina
-
(CCs adjusted)
On Wed, 1 Aug 2007, Andrew Morton wrote:
> > usb 2-1: USB disconnect, address 2
> > BUG: atomic counter underflow at:
> > [] show_trace_log_lvl+0x1a/0x30
> > [] show_trace+0x12/0x14
> > [] dump_stack+0x15/0x17
> > [] __free_pages+0x50/0x52
> > [] free_pages+0x1f/0x21
> > [] d
You want to make your USB keyboard to send the reports even if no key was
pressed, or what?
Thanks,
--
Jiri Kosina
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
N
gt; HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_IGNORE_MOUSE }
> be:
> {..., ..., HID_QUIRK_IGNORE_MOUSE | HID_QUIRK_POWERBOOK_HAS_FN }
This could be a possible cleanup for hid_blacklist[], if you are going to
make a patch I will happily
stian,
I have slightly modified your patch (let's keep the hid_blacklist[]
properly sorted) and applied it into my tree.
Thanks,
--
Jiri Kosina
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log fil
t; http://www.sf.net/projects/harmonycontrol
I applied your cleaned-up .23 patch to my tree, thanks (sorry for not
replying sooner, I was offline on vacation for quite some time).
--
Jiri Kosina
-
This SF.net email is sp
o the patch.
Hi Greg,
sorry for late reply, I was on vacation.
Yes, this has been sitting in my tree for quite a some time already.
Thanks a lot,
--
Jiri Kosina
-
This SF.net email is sponsored by: Splunk Inc.
Still grep
ike this patch until the ultimate solution comes (if there is any at
all). Thanks,
--
Jiri Kosina
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control o
db] Result: hostbyte=DID_NO_CONNECT
> driverbyte=DRIVER_OK,SUGGEST_OK
> [ 4771.448000] end_request: I/O error, dev sdb, sector 163846928
> [ 4771.448000] printk: 84 messages suppressed.
> [ 4771.448000] Buffer I/O error on device sdb, logical block 20480866
> [ 4771.448000] Buffer I/O err
ick and before the '23 03' request goes to the
mouse).
--
Jiri Kosina
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No
absolutely the opposite situation to what we have observed on my
uhci-based notebook! (i.e. the resume worked well if and only if the root
hub *was* suspended).
> And I continue to believe that it would be a big mistake to increase the
> CPU overhead by polling more frequently when a device
hich does precisely this? (i.e. calls spin_lock() with interrupts
disabled).
Do you convert all such code to something different as a part of the RT
work?
--
Jiri Kosina
-
This SF.net email is sponsored by DB2 Express
Dow
(&some_lock);
...
spin_unlock(&some_lock);
usb_hcd_giveback_urb(hcd, urb);
local_irq_restore(flags);
which is safe even against future removal of preempt inc/dec from
spin_lock_irq{save,restore}() functions.
--
Jiri Kosina
---
ck_urb(hcd, urb);
local_irq_restore(flags);
preempt_enable();
Would make it working in both cases. Not a nice thing, indeed :)
--
Jiri Kosina
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C
a
good way to treat patches.
--
Jiri Kosina
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to ge
omething new when trying out your keyboard.
Sure, see you in Ottawa.
Thanks,
--
Jiri Kosina
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. N
ule out purely keyboard issue here.
I'll put some printk()s into the uhci root hub code to understand better
what is going on. If you have any idea, please let me know.
Thanks,
--
Jiri Kosina
-
This SF.net email is spons
pyright (c) 2000-2005 Vojtech Pavlik <[EMAIL PROTECTED]>
* Copyright (c) 2005 Michael Haboustak <[EMAIL PROTECTED]> for Concept2, Inc
* Copyright (c) 2006-2007 Jiri Kosina
+ * Copyright (c) 2007 Oliver Neukum
*/
/*
@@ -26,6 +27,7 @@
#include
#include
#include
+#include
ooks
OK, but if it is only the device, without root hub going to suspend, it
doesn't work.
Alan, could this possibly be some race in uhci hub suspend handling (i.e.
when the keyboard tries to resume while the root hub is trying to go to
suspend, or something like
On Mon, 25 Jun 2007, Oliver Neukum wrote:
> > I grabbed a random HUB (usbhub4c from Linksys) and this made it work
> > nicely even on UHCI-based system I am testing on.
> Is it a 1.1 hub or a 2.0 hub?
1.1, the device is still handled by uhci_hcd.
When I change the autosuspend values of all devices in system from 2
(default) to 5, the value described in the previous paragraph (i.e. the
minimum time for which the keyboard must be suspended before it could be
woken up flawlessly) is still 2 second
mmediately and no
loss of keypressess happens.
I will verify on more various systems whether it is really related only to
UHCI, but so far it seems like the best guess.
Thanks,
--
Jiri Kosina
-
This SF.net email is sponsor
, just in case, and leaving the full
original message below ]
On Tue, 19 Jun 2007, Renato S. Yamane wrote:
> Jiri Kosina wrote:
> > On Tue, 19 Jun 2007, Renato S. Yamane wrote:
> > > I see this in dmesg:
> > > usb 1-1: device descriptor read/all, error -71
> >
g entry).
And more generally - the patches seem a little bit bigger than they could
be, I am not sure whether the layering and data structures you have are
not a little bit overdesigned. But this will need some more revi
linux-usb-devel list added
On Fri, 8 Jun 2007, Robert de Rooy wrote:
> Jiri Kosina wrote:
> > On Thu, 7 Jun 2007, Robert de Rooy wrote:
> >
> >
> > > Yes I figured it was a hardware problem, but that was not really the point
> > > I was trying to raise
On Tue, 5 Jun 2007, Alan Stern wrote:
> What you need to do is reduce the amount of memory used for I/O buffers.
> However I don't know how you can control it. Maybe people on LKML can
> provide some advice.
Playing with /proc/sys/vm/dirty* might be worthwile.
-
SR: 4000
> [ 76.487763] TASK = dff119f0[83] 'khubd' THREAD: dff12000
> [ 76.487947] GPR00: c02c1ca8 dff13e40 dff119f0 c0536020 c04687e0 0006
> 0011
> [ 76.488930] GPR08: 0002 6b6b6b6b 22004242 dff12000
>
&
kernel driver from USB device...
> failed to detach kernel driver from USB device...
> trying again to claim USB device...
> failed to claim USB device, trying 0 more time(s)...
> detaching kernel driver from USB device...
> failed to detach kernel driver from USB device...
> trying ag
Stern <[EMAIL PROTECTED]>
> CC: Jiri Kosina <[EMAIL PROTECTED]>
> CC: Matthew Dharm <[EMAIL PROTECTED]>
Greg,
as the changes to usbhid are really trivial (just prototype changes), it'd
be probably the best way if you take it through your tree together with
the rest of th
could very probably use the hotplug-safer cancel_work_sync()
elsewhere in your patch where you introduce flush_scheduled_work(), right?
Thanks,
--
Jiri Kosina
SUSE Labs
-
This SF.net email is sponsored by DB2 Express
Downl
(EVIOCGID) to obtain vendor id/product id corresponding
to the given input device, so you can easily look up the event device
corresponding to the device you are looking for.
--
Jiri Kosina
-
This SF.net email is sponsored by
nicely.
Sure, it still could be a HW issue (I have experienced this with two
random keyboards I used for testing), but I'd guess it would be something
different than what you describe. What do you think?
Thanks,
--
Jiri Kosina
SUSE Labs
-
On Fri, 25 May 2007, Jiri Kosina wrote:
> This is now handled in bugzilla [1]. Zan Lynx also reported this problem,
> and from the HID_DEBUG output he provided is evident that it is caused by
> HID layer receiving a report of size 4294967284 (which corresponds to
> urb->actua
SB_DEBUG and also
collect the usbmon trace, so that we can clearly understand what happens.
I am now inclined to think that this is caused by USB core messing up the
URB somehow, HID core seems to receive the URB with already bogus values.
[1] http://bugzilla.kernel.org/show_bug.cgi?id=
quot;default y if !EMBEDDED" and controlling debug
> output via a module parameter? -ENOPATCH though...
Hi Dmitry,
this is exactly what I have been thinking a couple of days ago, I am
currently in the process of creating a patch, it's quite annoying to ask
people to recompile kernel
rate report.
Do you please have any indication which kernel versions were OK with the
same .config, with respect to the USB mouse/keyboard hogs you are seeing
with 2.6.22-rc2-mm1?
Thanks,
--
Jiri Kosina
-
This SF.net emai
d lots of USB HID devices suffering from
> this kind of problem.
Which unfortunately would render suspending them quite impossible, as
losing keypresses this often is a big no-no :(
I will work on this a little bit more.
Thanks,
--
Jiri Kosina
SUSE Labs
---
one
second is not enough, it still loses data).
I will debug. Maybe just this particular keyboard is clumsy. I will try
with various different hardware. But if there are lots of HID hardware out
there which expose this broken behavior, it would be bad.
--
Jiri Kosina
SUSE Labs
-
27; or something like that.
It seems that this is not reproducible after some time (a few seconds) the
device is suspended.
Are you able to reproduce this? I will try to figure out what is going on.
--
Jiri Kosina
SUSE Labs
--
s a virtue in that regard.
I have quite a lot of things pending, but will test this ASAP.
Thanks,
--
Jiri Kosina
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and tak
t will prevent other keyboard
(PS/2 or even USB keyboard, which is not yet suspended) to generate an
input event (user presses CapsLock/NumLock at a 'right' time). Then you'll
get out of sync, won't you?
Thanks,
--
Jiri Kosina
SUSE Labs
--
; - }
> -
> - usbhid->out[usbhid->outhead] = report;
> - usbhid->outhead = head;
> + usbhid_queue_report_out(hid, report);
Is it OK that we don't check the return value of
usbhid_queue_report_out()? What if the queue becomes full
nd, that makes sense.
BTW I think there actually might be devices which won't be claimed neither
by hid-input nor hiddev - I mean devices with
hid->collection[i].type == HID_COLLECTION_PHYSICAL &&
ot;busy style" autosuspend only for devices we positively identify,
> is the point rendered moot?
Sorry, could you be please more specific? I don't think I understand the
point here. Thanks.
> > - (and of course coding style)
> It shall be done, but not until the principal
ch with proper
> > =Signed-off-by line?
> Oh yes, sorry.
And also proper Changelog please (i.e. "this device has that many input
interfaces and so it needs HID_QUIRK_MULTI_INPUT and it acts so and so and
there
preciate if you could test
whether really both of the quirks are needed - we don't want to add
unneeded quirks to devices, that would just spread confusion.
Also, could you please resend the patch with proper Signed-off-by l
On Thu, 17 May 2007, Jason Brewster wrote:
> Thanks,
What kind of device is that? (could you please post at least output of
lsusb, etc.).
It might be that the device is standard-compliant (for example HID), so
wouldn't require any extra driver.
Thanks,
--
Jir
userspace could want to deliver the output
report to it immediately, without any queuing)
- (and of course coding style)
Thanks,
--
Jiri Kosina
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the
very strange (and broken in many ways) usb mouse
attached in a situation when things didn't suspend. After unplugging it,
it seems to work.
I will look at it in more detail now, thanks.
--
Jiri Kosina
SUSE Labs
-
This SF
ume that the effect playback has been
already completed.
--
Jiri Kosina
SUSE Labs
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits.
the queue is too long. Or we can
simply just make any output report wake the device up.
So this is going to make the leds state consistent as soon as the keyboard
is woken up.
This is also a reason why this is not going to fly with PID devices - we
really want the force feedback t
es you sent me some weeks/months ago.
--
Jiri Kosina
SUSE Labs
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click
sysfs
> > in order to suspend it immediately.
> > I will investigate.
> You have compiled it with CONFIG_USB_SUSPEND, haven't you?
I have, of course :) Otherwise I won't even have the 'autosuspend' file in
sysfs, for example.
--
Jiri Kosina
SUSE Labs
--
scribe to).
You don't have to be subscribed to post into this mailinglist.
Thanks,
--
Jiri Kosina
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
contro
or me - the USB keyboard still seems to be awake
(leds are on), even if I echo 0 into 'autosuspend' file in sysfs in order
to suspend it immediately.
I will investigate.
Thanks,
--
Jiri Kosina
SUSE Labs
-
raise this on linux-input mailing list (and CC at
least me and Dmitry).
Thanks,
--
Jiri Kosina
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XM
) patches some time ago. So autosuspending of USB
keyboards/mice/etc. is being worked on.
Oliver, do you have any update please?
Thanks,
--
Jiri Kosina
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the
t; > I will apply this into my tree, thanks.
> Great thanks. Does this mean it will go into your tree and then into the
> mainline kernel, or is there an additional step needed?
No further steps needed on your side. Applied, thanks,
--
Jiri Kosina---
respect to maintaining backward compatibility in
userspace (ok, we have already been fiddling with this parameter anyway
during the usbhid code split, but anyway).
If you would care to make the patch which maintains backwards
compatibility (for example by aliasing the variable pb_fnmode behing two
rdesc[n2] = rdesc[n1]; \
> > + rdesc[n1] = tmp;
> wont someone complain about having a #define in a .c file?
Sure, this was just for you to test, I will commit cleaned up version in
my tree (you'll rece
On Tue, 1 May 2007, Jiri Kosina wrote:
> Thanks for the report - it clearly shows that Cypress produces different
> hardware with different report descriptors, all broken in a very similar
> way (improper order of usage minimum and maximum items), but not
> identical. This would
, but not
identical. This would require more general handling and care ... I will
send you updated patch for test.
--
Jiri Kosina
SUSE Labs
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE ve
th using hid
Is it possible that you will have chance to test it with patched
hid-core.c in near future? (you will have to modify that if() condition
trivially, so that it matches 0xde61 instead of 0xde64).
Thanks,
--
Jiri Kosina
SUSE Labs
-
on)
> Bus 001 Device 003: ID 04b4:de61 Cypress Semiconductor Corp.
So this one worked even previously without the patch?
Thanks,
--
Jiri Kosina
SUSE Labs
-
This SF.net email is sponsored by DB2 Express
Download DB2 E
.
Hi Li,
is there any chance that you rather split up the hid bus patch you have
been working on recently into independent reviewable patches instead, as
we were discussing it previously?
Thanks,
--
Jiri Kosina
-
This SF
On Sun, 29 Apr 2007, Bret Towe wrote:
> > There might be various reasons for this, most probably the report
> > descriptor of the device is broken. It might then be easy to fix the
> > report descriptor on the fly before it gets parsed, we are doing this
> > for various broken hardware already.
x27;s broken in it - I'll hopefully find time to do it
tomorrow and will send you a patch to test.
Thanks,
--
Jiri Kosina
SUSE Labs
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version o
evice, everything should be
fine. I have removed the WARN_ON from the code in my tree. I think we
still don't want users to add quirks for such broken devices (as it would
collide with hid_blakclist[] terminator), so I have left the initial
condition in usbhid_modify_dquirk() untouched.
F
d to CC (full thread here:
http://lkml.org/lkml/2007/4/27/496)
So this definitely isn't a HID-specific problem, something is confusing
the USB VID/PIDs.
--
Jiri Kosina
SUSE Labs
-
This SF.net email is sponsored by
if there is a possibility how to fix this on-the-fly, but maybe
writing a separate (userland, using hiddev or just-being-created hidraw
interface) driver would be better.
Thanks for the report,
--
Jiri Kosina
SUSE Labs
-
output corresponsing both
to the time the device is connected to the system and also when the data
is being processed?
Thanks,
--
Jiri Kosina
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FRE
srq fails me. But that is another story.
[...]
> The (first) "hanging" patch in 2.6.21-rc6-mm1 is: git-acpi.patch
Hi Helge,
thanks for the effort. If you take stock rc6-mm1 and revert just
git-acpi.patch, doesn the machine behave co
convenient with "bisecting by hand" Andrew's quilt
patchset, don't forget that it is also possible to obtain -mm tree through
git, which provides very convenient means for bisecting. This is what I
usually do.
--
Jiri Kosina
--
Hi,
recently I have been looking into bugreports against xpad driver - the
complaints were that for some devices (I am aware of at least
0x045e/0x028e and 0x0738/0x4716), the driver doesn't work at all even if
the device ids are added into xpad_device[] array. In fact the driver
doesn't even g
putting device to suspend, etc.
--
Jiri Kosina
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it no
bit more, but when you send
a broken-out version with separate changes, that'd be great.
Thanks,
--
Jiri Kosina
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express
transport, or you can experiment with kernel-provided lightweight
hidraw interface in -mm, but it's not guaranteed to be in a frozen-API
state yet.
Hope this helps,
--
Jiri Kosina
-
Take Surveys. Earn Cash. Influence
on information you have provided in your later messages, it
seems that it is probably not necessairly related neither to USB nor HID,
as you are getting hangs at different stages of boot, depending on your
local configuration/ker
On Thu, 12 Apr 2007, Helge Hafting wrote:
> The last messages (handwritten, somewhat shortened)
> calling hid_init+0x0/0x10()
> returned 0
> ran for 0 msec
> calling hid_init+0x0/0x50()
> usbcore registered new interface driver hiddev
> and then it hangs completely.
OK, so it hangs somewhere near
On Thu, 12 Apr 2007, Jiri Kosina wrote:
> CONFIG_IPMI_SI=y
> hangs upon boot on the already mentioned printk from ipmi_si. With
> CONFIG_IPMI_SI=m
> the boot succeeds. When manually trying to modprobe ipmi_si after that,
> the modprobe itself hangs, but the machine remains u
I_SI=m
the boot succeeds. When manually trying to modprobe ipmi_si after that,
the modprobe itself hangs, but the machine remains usable otherwise.
I still wonder if this could be related to what Helge was originally
reporting.
--
Jiri
On Thu, 12 Apr 2007, Jiri Kosina wrote:
> > - try booting without any HID devices plugged in (i.e. usb mice, usb
> > keyboards) if the problem persists?
> > - recompile 2.6.21-rc6-mm1 with git-hid.patch reverted to see if it helps?
> Do you compile with CONFIG_HIDRA
On Thu, 12 Apr 2007, Jiri Kosina wrote:
> Could you please
> - try booting without any HID devices plugged in (i.e. usb mice, usb
> keyboards) if the problem persists?
> - recompile 2.6.21-rc6-mm1 with git-hid.patch reverted to see if it helps?
Do you compile with CONFIG_HIDRA
s?
- recompile 2.6.21-rc6-mm1 with git-hid.patch reverted to see if it helps?
I am unfortunately not able to reproduce it here on x86_64.
Thanks,
--
Jiri Kosina
-
Take Surveys. Earn Cash. Influence the Future of IT
Join Sour
ut special drivers?
It definitely makes sense - at least due to the fact that such (hopelessly
broken) devices have already been supported by the linux kernel, so
accidentaly removing the support definitely is a regression, which is a
thing we don't want to happen.
T
quite unfortunate. I'll try to review it nevertheless, but it'd be
much more convenient if you manage to send a patch.
Thanks,
--
Jiri Kosina
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net&#
On Thu, 5 Apr 2007, Adam Kropelin wrote:
> Truncated reports should not be discarded since it prevents buggy
> devices from communicating with userspace.
Will push this for 2.6.21.
Thanks,
--
Jiri Kosina
-
Take S
to properly reset leds after all.
Pete, could you please resend your patch, with proper metadata, we need to
merge your one then.
Thanks,
--
Jiri Kosina
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceF
d events? Could you by any chance
look at current implementation of hidraw (it's in -mm or I can send it to
you as a separate patch) and check whether you have any comments on this?
It would be good if you could use hidraw rather than reading
y there are some). I won't
allow it to vanish, don't worry.
We just have to make sure that new users will use hidraw instead, as it
provides more flexibility for the user, is not dependent on the underlying
transport p
On Tue, 3 Apr 2007, Wael Adel wrote:
> how can i use usbmon module to calculate the rate of the traffic i
> sent over the usb bus?
Big apologizes, I have completely overlooked the word 'rate' in the
original question.
On Tue, 3 Apr 2007, nesta wrote:
> i want to catch the usb traffic rate over the usb bus. is there any gui
> for linux that enables me from monitoring the traffic rate over the usb?
Read Documentation/usb/usbmon.txt
I am not confident about your "gui" requirement though :)
s rejected by Greg.
The issue is that 32 bits of the quirk bitmask are going to be taken by
the quirk entries (so no, it's not related to the size of the table).
Thanks,
--
Jiri Kosina
-
Take Surveys. Earn Cash. Inf
1 - 100 of 184 matches
Mail list logo
