On Mon, Mar 07, 2005 at 06:23:05PM -0800, Nishanth Aravamudan wrote:
> On Sun, Mar 06, 2005 at 11:30:48PM +0100, [EMAIL PROTECTED] wrote:
> >
> >
> > The while-loop seemed excessively blocked with
> > conditionals. By reorganizing the code so timeout is the condition for
> > the loop and changing
On Monday 07 March 2005 3:18 pm, Mark Hurenkamp wrote:
>
> Mar 7 23:21:31 ws1 kernel: drivers/usb/input/hid-core.c: input irq status
> -32
> received
> Mar 7 23:21:31 ws1 kernel: drivers/usb/input/hid-core.c: input irq status
> -71
> received
> Mar 7 23:21:33 ws1 kernel: drivers/usb/input/h
> The problem comes when two devices share an IRQ line and at least one of
> them is actively generating interrupt requests. An ethernet interface or
> a USB controller would make a good example, if they weren't shut down
> properly during a kexec reboot.
>
> Let's say devices A and B share t
On Sun, Mar 06, 2005 at 11:30:48PM +0100, [EMAIL PROTECTED] wrote:
>
>
> 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-of
On Sun, Mar 06, 2005 at 11:30:48PM +0100, [EMAIL PROTECTED] wrote:
>
>
> 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-of
On Mon, Mar 07, 2005 at 06:01:46PM -0800, Pete Zaitcev wrote:
> On Mon, 7 Mar 2005 16:25:36 -0800 Nishanth Aravamudan <[EMAIL PROTECTED]>
> wrote:
>
> > > > Use wait_event_timeout() instead of custom wait-queue code. Remove
> > > > now unused variables.
> > >
> > > What is the purpose of this ch
On Mon, 7 Mar 2005 16:25:36 -0800 Nishanth Aravamudan <[EMAIL PROTECTED]> wrote:
> > > Use wait_event_timeout() instead of custom wait-queue code. Remove
> > > now unused variables.
> >
> > What is the purpose of this change?
> [...] It provides a
> *good* example to copy&paste developers. It al
David Brownell <[EMAIL PROTECTED]> writes:
> On Monday 07 March 2005 2:08 pm, Eric W. Biederman wrote:
>
> >
> > The ongoing DMA transfers which are companions of the irq generating
> > events are what really concern me, as we could get all kinds of
> > interesting memory stomps. Do you think y
On Sun, Mar 06, 2005 at 05:00:45PM -0800, Pete Zaitcev wrote:
> 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?
We have an interface that does ex
On Sun, Mar 06, 2005 at 06:14:00PM -0500, Alan Stern wrote:
> 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()
Hi,
I've had some problems lately with the usb subsystem (not sure if previous
kernel just didn't have the problem, or I just had my hardware connected
differently).
On 2.6.10 I sometimes noticed the following message:
ws1 kernel: drivers/usb/input/hid-core.c: input irq status -71 received
and it
The Thu, 3 Mar 2005 22:50:34 +0100
"Gerd v. Egidy" <[EMAIL PROTECTED]> wrote:
> Hi Samuel,
>
Hello again,
> > When issuing a command which I knew produced the errors, I got the
> > surprise to see that no usb reset happened when the transfers were made
> > through the hub. I tested it several ti
On Monday 07 March 2005 2:08 pm, Eric W. Biederman wrote:
>
> The ongoing DMA transfers which are companions of the irq generating
> events are what really concern me, as we could get all kinds of
> interesting memory stomps. Do you think you could implement
> a reboot notifier or a shutdown() m
Alan Stern <[EMAIL PROTECTED]> writes:
> On 7 Mar 2005, Eric W. Biederman wrote:
>
> > Alan Stern <[EMAIL PROTECTED]> writes:
> >
> > > Shared IRQs will always be a problem. And the PCI subsystem doesn't
> > > implement shutdown() methods; that seems like a pretty big hole. I guess
> > > indi
On Monday 07 March 2005 1:48 pm, David Hollis wrote:
> On Mon, 2005-03-07 at 11:26 -0800, David Brownell wrote:
> > > How about Jamie's use of the kevent to take care of the
> > > link/speed negotiation bits?
> >
> > You mean, as found in his usbnet-ax8817x-medium-mode-take2.patch?
> > I see tha
On Mon, 2005-03-07 at 11:26 -0800, David Brownell wrote:
> On Monday 07 March 2005 9:47 am, David Hollis wrote:
> >
> > It seems that I can re-factor the ax8817x code to make use of this
> > instead of manually creating/handling the INT URB to reduce the
> > duplicity eh?
>
> I'd sure hope so!
On 7 Mar 2005, Eric W. Biederman wrote:
> Alan Stern <[EMAIL PROTECTED]> writes:
>
> > Shared IRQs will always be a problem. And the PCI subsystem doesn't
> > implement shutdown() methods; that seems like a pretty big hole. I guess
> > individual drivers can always create their own, however.
>
Alan Stern <[EMAIL PROTECTED]> writes:
> Shared IRQs will always be a problem. And the PCI subsystem doesn't
> implement shutdown() methods; that seems like a pretty big hole. I guess
> individual drivers can always create their own, however.
Not having seen this in practice what is the bad ef
On Monday 07 March 2005 9:47 am, David Hollis wrote:
>
> It seems that I can re-factor the ax8817x code to make use of this
> instead of manually creating/handling the INT URB to reduce the
> duplicity eh?
I'd sure hope so! Ideally, without needing to tweak any of
the infrastructure; but if it'
Various folk have been having problems with certain full speed ISO transfers
through USB 2.0 transaction translating hubs ... where "certain transfers"
starts at about 192 data bytes per transfer, and goes up. (And thus it
involves more than one microframe to transfer the data ... and some messy
m
¤?⌒? ?⌒?
? ?? ⌒? www.51097757.com
?田?田田| ?-
?
注册上海公司 1000元起 验资资金由我们垫
个人创业的良机 --- 自己做老板
网址：www.51097757.com
电话：021- 51097757， 13391355761
网络实名：注册上海公司招商代理
－－－
On Sun, 2005-03-06 at 20:50 -0800, David Brownell wrote:
> 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
>
It seems that I
On Monday 07 March 2005 7:17 am, Jordan, Kyle wrote:
>
> I have been reading the USB Testing on Linux document. It states that
> usbtest is not supported with the 2.4 kernel. I was wondering if anyone
> has used usbtest with the 2.4 kernel.
If anyone's backported the parts that aren't specific
On Mon, 7 Mar 2005, Sara Fonseca wrote:
> Hi,
>
> I am using libusb clear_halt function, to set the data toggle bits to
> 0. It suceeds in the first bulk endpoint, but not in the second. In
> that case it returns:
>
> Clear Halt EP3: could not clear/halt ep 131: Connection timed out
>
> What mi
On 7 Mar 2005, Eric W. Biederman wrote:
> > Seems that if kexec were to use remove() methods that'd
> > probably resolve a lot of those issues. I confess I
> > still don't see much point to a shutdown() method, unless
> > maybe it's to avoid using reboot notifiers for that subset
> > of remove()
I have been reading the USB Testing on Linux document. It states that
usbtest is not supported with the 2.4 kernel. I was wondering if anyone
has used usbtest with the 2.4 kernel.
For some background information, I am currently using Linux 2.4.21 on an
embedded system with a Freescale (Motorola
Hi,
I am using libusb clear_halt function, to set the data toggle bits to
0. It suceeds in the first bulk endpoint, but not in the second. In
that case it returns:
Clear Halt EP3: could not clear/halt ep 131: Connection timed out
What might be happening?
I also tried to use usb_reset. Every tim
В Вашей компании есть отдел продаж? Мы можем утроить его эффективность в поиске
новых клиентов для Вашей компании! Всё дело в том, что 3/4 времени сотрудников
при этой работе тратится на телефонные звонки, мы же можем взять эту работу на
себя, но несколько в ином русле. Мы разошлем Ваше предложе
On Sun, 2005-02-20 at 09:34 +0100, Oliver Neukum wrote:
> Am Sonntag, 20. Februar 2005 03:13 schrieb Craig Keogh:
> > kernel 2.6.6: Modem works.
> > kernel 2.6.7: Modem works.
> > kernel 2.6.8.1: No device present (/dev/ttyACM0). Only logged message
> > is:
> >
> > drivers/usb/class/cdc-acm.c: v0.
Am Sonntag, 6. März 2005 23:30 schrieb [EMAIL PROTECTED]:
> + if (!wait_event_timeout(ep->wait, (ep->urb->status != -EINPROGRESS),
> 500)) {
> + printk(KERN_ERR "usbmidi: usb_bulk_msg timed out\n");
> + ret = -ETIME;
No sorry. You really should not test for EINPR
30 matches
Mail list logo
