Hi All,
I am here with some set of doubts... Hope you people guide me right
direction.
I would like to know, all USB devices (like BT dongle, camera) connected to my
system . To know this , i would like to have a kernel module with callback
function. This callback function would b
Kernel version 2.6.13 introduced a regression in the generic USB
serial converter driver (usbserial.o, drivers/usb/serial/generic.c).
The bug manifests, as far as I can tell, whenever you attempt to write
to the device -- the write will never complete (write() returns 0, or
blocks).
Signed-off-by:
> We will still have the problem that the HCDs don't have access to the
> spinlock that protects the queue pointers. I suppose the spinlock could
> be EXPORTed.
That problem is ... what? Exporting that lock would imply there's some
good reason for code other than usbcore to use it. I haven't
On Thu, 13 Oct 2005, Greg KH wrote:
> On Thu, Oct 13, 2005 at 05:00:24PM -0400, Alan Stern wrote:
> >
> > The new BUG_ON line isn't going to be permanent; it's there just in case
> > there's someing wrong with the new code.
>
> Can I change it into a WARN_ON() instead so we don't take down the w
On Thu, Oct 13, 2005 at 05:00:24PM -0400, Alan Stern wrote:
>
> The new BUG_ON line isn't going to be permanent; it's there just in case
> there's someing wrong with the new code.
Can I change it into a WARN_ON() instead so we don't take down the whole
machine?
thanks,
greg k-h
--
On Thu, 13 Oct 2005 16:16:58 -0700 (PDT), Linus Torvalds <[EMAIL PROTECTED]>
wrote:
> "release()" won't be called until the _last_ close, and the task that
> opened the fd can certainly exit before that.
>[...]
> It's a fundamental mistake to think that file descriptors stay with the
> process
On Thu, 13 Oct 2005, Pete Zaitcev wrote:
>
> The whole application cannot exit and leave URBs running behind,
> because usbdevio_release() blocks until they are terminated.
Wrong.
You just do a fork(), and a close in the parent.
"release()" won't be called until the _last_ close, and the task
On Tue, 27 Sep 2005 17:58:00 +0100, Alan Cox <[EMAIL PROTECTED]> wrote:
> On Maw, 2005-09-27 at 09:09 -0700, Linus Torvalds wrote:
> > > root-owned), then the urb completes, and kill_proc_info() sends the
> > > signal to the unsuspecting process.
> >
> > Ehh.. pid's don't get re-used until they w
err, guys?
Begin forwarded message:
Date: Thu, 13 Oct 2005 14:35:16 -0700
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 5433] New: modprobe ehci-hcd freezes system
http://bugzilla.kernel.org/show_bug.cgi?id=5433
Summary: modprobe ehci-hcd freezes system
Greg:
This patch (as580) is perhaps the only result from the long discussion I
had with David about his changes to the root-hub suspend/resume code. It
renames the hub_suspend and hub_resume methods in struct usb_hcd to
bus_suspend and bus_resume. These are more descriptive names, since the
Greg:
The uhci-hcd driver is fairly lax about the way it handles isochronous
transfers. This patch (as579) improves it in three respects:
TDs for a new URB aren't added to the schedule until all of
them have been allocated. This way there's no risk of the
controller exe
> "Alan" == Alan Stern <[EMAIL PROTECTED]> writes:
Hi,
Alan> Ideally for testing you should use a separate host; it makes
Alan> some things simpler. But it's not necessary. I would assume
Alan> that you have a separate computer anyway; doing driver
Alan> development on an iPod -- even a
On Thu, 13 Oct 2005, Franck wrote:
> > If every HCD is careful not to use URBs that aren't marked (i.e., for
> > which urb->hcpriv is NULL), then a single endpoint queue would be okay.
> > And it wouldn't be necessary to move the usb_get_urb and atomic_inc
> > statements either (or the DMA stuff).
On Thu, 13 Oct 2005, Franck wrote:
> 2005/10/12, Alan Stern <[EMAIL PROTECTED]>:
> > On Wed, 12 Oct 2005, Franck wrote:
> > > Does a patch that do this have any chance to be accepted ?
> >
> > I think we should decide on the _correct_ solution first. Then acceptance
> > will be obvious.
> >
>
>
2005/10/13, Alan Stern <[EMAIL PROTECTED]>:
> On Wed, 12 Oct 2005, David Brownell wrote:
> > The sl811 code should probably refuse to start() urbs it hasn't marked
> > yet (by setting urb->hcpriv) too. There's no point to maintaining a
> > parallel queue for each endpoint, but it should still igno
2005/10/12, Alan Stern <[EMAIL PROTECTED]>:
> On Wed, 12 Oct 2005, Franck wrote:
> > Does a patch that do this have any chance to be accepted ?
>
> I think we should decide on the _correct_ solution first. Then acceptance
> will be obvious.
>
ok, but my question was more: "does the usbcore need t
On Wed, 12 Oct 2005, David Brownell wrote:
> Potentially; the usb_get_urb() and atomic_inc() should be paired with the
> list_add_tail() -- under spinlock protection -- rather than being done as
> late as it's now done by hcd_submit_urb(). That's what Alan's patch does.
>
> Similarly, the urb->*
Christian Iversen wrote:
> ehci_hcd :00:10.3: iso sched full d24fd5e0 (now 572 max 2620)
> ALSA usbaudio.c:767: cannot submit datapipe for urb 0, err = -28
>
> Now, I've searched a bit, and -28 i supposed to be ENOSPC, which
> had (in one explanation) something to do with bandwidth handling.
>
On Wed, 12 Oct 2005, Erik Paulson wrote:
> Hi,
>
> I want to create a USB gadget that is also a mass-store device, and I'm
> looking for advice on how to get started.
>
> The gist of what I want to create is an external USB hard drive, but one
> that is running some sort of host software that I
On Thu, 13 Oct 2005, Olav Kongas wrote:
>
> Hi,
>
> I have a fancy flash drive with embedded hub. It provides no
> end of surprises and has turned out to be invaluable in
> exposing all kinds of corner cases in HCD development.
>
> This flash drive worked on 2.6.13 and earlier kernels, but
20 matches
Mail list logo
