Hi Feyd,
On Tue, 1 Mar 2005 07:22:51 +0100
Feyd <[EMAIL PROTECTED]> wrote:
> On Mon, 28 Feb 2005 20:05:12 -0800
> David Brownell <[EMAIL PROTECTED]> wrote:
>
> > For hardware specifics, you'd use the pci revision ... which
> > I see in 'lspci', but not obviously in the kernel pci_dev.
> > Hmm ..
Le 05.03.2005 23:03, Alan Stern a écrit :
I'm never sure whether it's best to continue things like this on the
mailing list so everyone can follow along or in the Bugzilla entry...
Don't know. IMHO, the bugzilla entry should be filled if a solution is
found (or not found :-( ). It's up to you, USB
Hi,
I have got Motorola Phone and use it as ACM modem with cdc-acm module. My
working kernel is 2.6.11, cdc-acm build as kernel module. Once i forgot to
stop ppp connection, and disconnect device. Here is result:
=
kernel: ohci_hcd :00:02.1: urb cf46f0e0 path 1 ep2in 5e16 cc 5 -
Vojtech Pavlik wrote:
On Sat, Mar 05, 2005 at 10:23:25PM -0500, Adam Kropelin wrote:
hid-debug.h includes resolv_event, which is currently unused,
resulting
in a compiler warning. Since this function is presumably useful for
debugging and is only included when DEBUG is enabled for hid-core,
mark th
On Sun, Mar 06, 2005 at 09:03:18AM -0500, Adam Kropelin wrote:
> Vojtech Pavlik wrote:
> >On Sat, Mar 05, 2005 at 10:23:25PM -0500, Adam Kropelin wrote:
> >
> >>hid-debug.h includes resolv_event, which is currently unused,
> >>resulting
> >>in a compiler warning. Since this function is presumably u
Am Sonntag, 6. März 2005 11:20 schrieb Dmitry Nezhevenko:
> kernel: hub 2-0:1.0: port 1, status 0100, change 0003, 12 Mb/s
> kernel: usb 2-1: USB disconnect, address 3
> kernel: usb 2-1: usb_disable_device nuking all URBs
> kernel: ohci_hcd :00:02.1: shutdown urb cf46f0e0 pipe c0410380 ep2in-bu
hid-debug.h includes resolv_event, which is not used if DEBUG is only
enabled in hid-core, but _is_ used when DEBUG is also enabled in hid-input.
Mark the function with __attribute__((unused)) to silence the warning
when only hid-core is being DEBUGged.
Signed-off-by: Adam Kropelin <[EMAIL PROTECT
hid-core contains the following bit of code in hid_input_report:
if (hid->claimed & HID_CLAIMED_HIDDEV)
hiddev_report_event(hid, report);
for (n = 0; n < report->maxfield; n++)
hid_input_field(hid, report->field[n], data, regs);
if (hid->cl
On Sun, Mar 06, 2005 at 09:48:19AM -0500, Adam Kropelin wrote:
> hid-debug.h includes resolv_event, which is not used if DEBUG is only
> enabled in hid-core, but _is_ used when DEBUG is also enabled in hid-input.
> Mark the function with __attribute__((unused)) to silence the warning
> when only hi
On Sun, Mar 06, 2005 at 09:56:24AM -0500, Adam Kropelin wrote:
> hid-core contains the following bit of code in hid_input_report:
>
> if (hid->claimed & HID_CLAIMED_HIDDEV)
> hiddev_report_event(hid, report);
>
> for (n = 0; n < report->maxfield; n++)
> hi
Hi Alan,
> The tech support guy at Cypress wants to know which USB-IDE interface
> controller you are using. I told him the USB ID numbers, but he may need
> more information. Perhaps you can find a part number on the Cypress
> controller chip.
To get a view on the chip itself I have to dissect
Vojtech Pavlik wrote:
On Sun, Mar 06, 2005 at 09:56:24AM -0500, Adam Kropelin wrote:
hid-core contains the following bit of code in hid_input_report:
if (hid->claimed & HID_CLAIMED_HIDDEV)
hiddev_report_event(hid, report);
for (n = 0; n < report->maxfield; n++)
hid_input_field(hid, report->field[n]
Hi,
> > > Unclear. Did you say you'd tried this with a non-VIA controller?
> > > The VIA EHCI 0.95 has always been problematic.
> >
> > No, I do have 2 controllers here but both are VIA. If you say they are
> > problematic I'm now going to buy one that is not VIA and look if it is
> > working bet
Hi Alan,
> > But the disconnect looked different than without the patch
> > - without the device automatically reconnects with a
> > different id but it stayed disconnected this time. I don't
> > know if that is related to the patch or just luck - but I
> > have never seen a disconnect like this
On Sun, 6 Mar 2005, Gerd v. Egidy wrote:
> Switching the controller has helped!
>
> I bought an ALI as suggested. I still get a lot of usb resets but no
> disconnects anymore. This means the backup works without being
> killed but the overall speed is not good because of the time needed
> for t
On Sun, 6 Mar 2005, Gerd v. Egidy wrote:
> > Although I can't tell for sure from this log excerpt, it looks like you
> > had the drive connected through an external hub and the hub got unplugged
> > for a moment. Maybe its cable was jiggled. No wonder this appears
> > different from the times wh
On Sunday 06 March 2005 9:28 am, Alan Stern wrote:
> On Sun, 6 Mar 2005, Gerd v. Egidy wrote:
>
> > Switching the controller has helped!
> >
> > I bought an ALI as suggested. I still get a lot of usb resets but no
> > disconnects anymore. This means the backup works without being
> > killed but
Hi Alan,
> That could be another hardware problem. Are you using the ALI controller
> connected through an external hub? A number of other people have found
> they needed to that in order to fix a clock jitter problem in the ALI
> hardware.
I tried it with hub and without. Both times lots of re
> Given that sort of issue, switching cables could matter too. Not
> all "old" cables are evidently capable of handling high speed
> signals.
That as actually one of the first things I tried when I encountered the
problems. I tried 5 diffent cables, all marked with "USB 2.0 compatible". 4
of th
On Sunday 06 March 2005 11:02 am, Gerd v. Egidy wrote:
>
> This is from messages written by syslog. It seems like usb-storage is filling
> the
> kernel log buffer faster that syslogd can read. Syslogd constantly uses about
> 10% cpu on the machine and I still often see garbled log entries.
Ther
On Sunday 06 March 2005 11:42 am, Gerd v. Egidy wrote:
> Just found out that we have a Adaptec-brand controller using a EHCI 1.0 NEC
> chip in one of the servers at work:
>
> kernel: ehci_hcd :00:0e.2: EHCI Host Controller
> kernel: ehci_hcd :00:0e.2: irq 5, pci mem 0xde00
> kernel: e
Replace direct wait-queue usage with wait_event_timeout(). Removed
some local variables which help determine loop time, but which are now
compressed into the wait_event_timeout() macro. Patch is compile-tested.
Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
Signed-off-by: Domen Puncer <[E
Replace deprecated interruptible_sleep_on_timeout() with direct
wait-queue usage. Patch is compile-tested.
Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
---
kj-domen/drivers/usb/misc/rio500.c | 12 +---
1 files changed, 9 inser
Use wait_event_timeout() instead of custom wait-queue code. Remove
now unused variables.
Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
---
kj-domen/drivers/usb/class/usblp.c | 24 +++-
1 files changed, 7 insertion
compile warning cleanup - handle error return from
scsi_add_host
Signed-off-by: Stephen Biggs <[EMAIL PROTECTED]>
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
---
kj-domen/drivers/usb/image/microtek.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff -puN drivers/usb/
Replace deprecated interruptible_sleep_on_timeout() with direct
wait-queue usage. Also replace some rather odd wait-queue usage with the
existent macros. Also adjusted the wake_up_interruptible() call appropriately,
as I changed all the states to TASK_UNINTERRUPTIBLE (signals were not be checked
i
The while-loop seemed excessively blocked with
conditionals. By reorganizing the code so timeout is the condition for
the loop and changing the checks within the loop, several lines of code
were removed.
Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
Signed-off-by: Domen Puncer <[EMAIL P
On Sun, 6 Mar 2005, Gerd v. Egidy wrote:
> I tried it with hub and without. Both times lots of resets. With the hub I get
> resets right from the start. Without the hub there are very few resets at the
> beginning but after some time (like 30 min or so) they are coming in shorter
> cycles.
>
> W
On Sun, 6 Mar 2005 [EMAIL PROTECTED] wrote:
> Replace direct wait-queue usage with wait_event_timeout(). Removed
> some local variables which help determine loop time, but which are now
> compressed into the wait_event_timeout() macro. Patch is compile-tested.
>
> Signed-off-by: Nishanth Aravamud
Alan Stern <[EMAIL PROTECTED]> writes:
> Eric and Randy:
>
> Can you answer a question regarding kexec? How does it handle shared
> IRQs when shutting down the old kernel?
>
> The problem arises when the new kernel initializes a driver for the first
> device sharing an IRQ line. The driver wi
Sylvain ZIMMER wrote:
hi !
I've had such great feedback from you kernel guys, it really motivates
me to do other bug reports !! thanks !
Glad to help, but please respond to the list, not just me. I'm including
the text of both your emails below for the folks on the list see
something I missed.
I ha
On Sun, 06 Mar 2005 23:30:51 +0100 [EMAIL PROTECTED] wrote:
> Use wait_event_timeout() instead of custom wait-queue code. Remove
> now unused variables.
What is the purpose of this change?
-- Pete
---
SF email is sponsored by - The IT Product
On Sunday 06 March 2005 3:32 pm, Eric W. Biederman wrote:
>
> Then there is the primary case, kexec case where we can trust
> the kernel code. Before a reboot we call the reboot_notifiers
> and the device_shutdown() (which calls the appropriate device method).
> The expectation is that the driver
This fixes the problem Holger had with his Zaurus, and adds some
more class declarations to the headers.
Please merge.
- Dave
This patch resolves a recent problem with the Zaurus C-860 support.
A change to correct handling of Zaurii that are lying about their support
for the "CDC Ethernet" class
This patch applies with minor offsets against the latest USB BK,
adding status/interrupt transfer support to the infrastructure
and using it for CDC Ethernet for link status notifications.
Please merge.
- Dave
This adds status/interrupt transfer infrastructure to "usbnet", and
uses it for CDC Eth
This has several small updates; please merge.
- Dave
Various fixes to the Ethernet/RNDIS gadget core code:
- Pre-allocate the request used to transfer status back to the host.
Used initially for CDC Ethernet; RNDIS will change later. This
resolves a longstanding FIXME, elimininat
Driver was wrongly reporting failure in some cases; please merge.
- Dave
Minor bugfix to net2280: don't return incorrect dequeue() status.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
--- xu26/drivers/usb/gadget/net2280.c 2005-02-05 01:10:30.0 -0800
+++ gadget-2.6/drivers/usb/gadge
这里有千万个创业项目，万余个招商项目
网 址：www.xuzhou89189.com
徐州客服：0516-8990316 吴涛 QQ：356268656
北京客服：010-68405330
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which produc
David Brownell <[EMAIL PROTECTED]> writes:
> On Sunday 06 March 2005 3:32 pm, Eric W. Biederman wrote:
> >
> > Then there is the primary case, kexec case where we can trust
> > the kernel code. Before a reboot we call the reboot_notifiers
> > and the device_shutdown() (which calls the appropriat
39 matches
Mail list logo
