On Fri, Apr 19, 2002 at 07:52:54AM +0200, Oliver Neukum wrote:
>
> I can't help it, it looks like a work around.
> In principle there are entirely legal uses of USB which we can't handle
> already today. You can connect 30 printers to USB. Or 20 modems.
> We are screwed if you do.
> I agree that
On Thu, 2002-04-18 at 22:46, Oliver Neukum wrote:
> Too short a difference. You easily skip it reading and there's a chance of typos.
> Furthermore the first latter should differ for tab completion.
> Target is actually quite good a name. It makes clear that there's only
> one initiator of transac
On Friday 19 April 2002 06:40, Greg KH wrote:
> On Fri, Apr 19, 2002 at 07:21:07AM +0200, Oliver Neukum wrote:
> > On Friday 19 April 2002 05:56, Greg KH wrote:
> > > Hi all,
> > >
> > > Here's a patch against 2.5.8 that adds fine grain minor allocation to
> > > the usb core code. Now we can ask
On Friday 19 April 2002 07:37, George J Karabin wrote:
> Confusing as it may be to non-USB developers, how about using the USB
> spec terms "host" (for the PC) and "local host" (for the USB
> gadget/client/device/etc...)? I haven't seen those specific terms
> suggested yet after quickly searching
On Fri, Apr 19, 2002 at 07:21:07AM +0200, Oliver Neukum wrote:
> On Friday 19 April 2002 05:56, Greg KH wrote:
> > Hi all,
> >
> > Here's a patch against 2.5.8 that adds fine grain minor allocation to
> > the usb core code. Now we can ask for only 1 minor number from the USB
> > core if we want.
Confusing as it may be to non-USB developers, how about using the USB
spec terms "host" (for the PC) and "local host" (for the USB
gadget/client/device/etc...)? I haven't seen those specific terms
suggested yet after quickly searching through the archive.
For shorthand, you might use "h" and "lh"
On Friday 19 April 2002 05:56, Greg KH wrote:
> Hi all,
>
> Here's a patch against 2.5.8 that adds fine grain minor allocation to
> the usb core code. Now we can ask for only 1 minor number from the USB
> core if we want. I also converted all of the current drivers to work
> properly. With this
On Thu, 18 Apr 2002 [EMAIL PROTECTED] wrote:
| On Thu, 18 Apr 2002, Tianjiao Zhang wrote:
|
| | I tested several versions of kernel 2.4-7 up and 2.5.1. The usb system
| | has difficulty giving the right interface class for my Lexmark X83
| | (scanner/copier/printer)
| | The result " cat /proc/b
On Thu, 18 Apr 2002, Tianjiao Zhang wrote:
| I tested several versions of kernel 2.4-7 up and 2.5.1. The usb system
| has difficulty giving the right interface class for my Lexmark X83
| (scanner/copier/printer)
| The result " cat /proc/bus/usb/devices " is :
| T: Bus=01 Lev=01 Prnt=01 Port=00
Hi all,
Here's a patch against 2.5.8 that adds fine grain minor allocation to
the usb core code. Now we can ask for only 1 minor number from the USB
core if we want. I also converted all of the current drivers to work
properly. With this patch, my /proc/usb/drivers looks like the
following wit
On Thu, Apr 18, 2002 at 07:35:41PM -0400, Tianjiao Zhang wrote:
> However, in the source code of lsusb, it has the same definition as
> linux_source_root/include/linux/usb.h
>
> #define USB_CLASS_DATA10
This should have been fixed in 2.4.17-pre3 and 2.5.1-pre8. Have you
tried any k
I tested several versions of kernel 2.4-7 up and 2.5.1. The usb system
has difficulty giving the right interface class for my Lexmark X83
(scanner/copier/printer)
The result " cat /proc/bus/usb/devices " is :
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 1.10 Cls
The usb/error-codes.txt document says -ECONNRESET is
for async unlink, which is what I saw happening. What HCD
is passing -ENOENT (synchronous unlink) there?
Actually, that distinction is something I'd like to rip out in 2.5
on the grounds that the completion function really has no
reason to car
On Thu, Apr 18, 2002, shiju mathew <[EMAIL PROTECTED]> wrote:
> When the sa1110 system goes to sleep I get a message "
> usb-uhci.c: interrupt, status 2, frame# 1790 " on the
> host side . This messages keep on comming on the host
> side even after the sa1110 system wakes up from sleep.
> But each
On Fri, Apr 19, 2002 at 01:17:20AM +0200, [EMAIL PROTECTED] wrote:
>
> Anyway, let me start with the smallest flaw.
> CONFIG_USB_INPUT is mentioned twice.
> Reading drivers/usb/input/Config.in we find
>
> if [ "$CONFIG_USB_HID" = "y" -o "$CONFIG_USB_KBD" = "y" -o "$CONFIG_USB_MOUSE" \
> = "y" ];
From: David Brownell <[EMAIL PROTECTED]>
So you're reporting at least one reproducible bug (3a sticks),
maybe a second (hub shows up twice, see below) and even
a third (CONFIG problem) ... and that eventually you see one
hard-to-reproduce BUG()?
I report a
It's expecting -ENOENT
This is a long-standing problem with various HCDs not all doing the same
thing.
Matt
On Thu, Apr 18, 2002 at 03:59:38PM -0700, David Brownell wrote:
> > The basic problem here is that the abort isn't recognized as an abort
> > because of the URB status code.
>
> The last
> The basic problem here is that the abort isn't recognized as an abort
> because of the URB status code.
The last I remember was a question about -ECONNRESET, and
so far as I can tell the EHCI driver obeys usb/error-codes.txt in
that area ... what status was usb-storage expecting instead?
- Dav
The basic problem here is that the abort isn't recognized as an abort
because of the URB status code.
In other words, it's a bug which is attributable to the error-recovery
code in usb-storage. I'm working on a much bigger fix which overhauls the
entire architecture, but Greg KH has indicated th
On Thu, Apr 18, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > > No, a code inspection shook out the fact that it didn't even
> > > play by the 2.4 rules, which require HCDs to clean up their
> > > device state when bus->op->deallocate() is called.
> >
> > That was never a rule for 2.4. Refe
> > No, a code inspection shook out the fact that it didn't even
> > play by the 2.4 rules, which require HCDs to clean up their
> > device state when bus->op->deallocate() is called.
>
> That was never a rule for 2.4. Reference counting takes care of making
> sure things work correctly after dea
I forget, didn't you verify that this problem repeated just
as cleanly using this device in USB 1.1 mode?
I'm recalling this as an issue where the usb-storage
driver needed to update its error handling, and there
was no particular "USB 2.0" issue. And at any rate
the patch is to usb-storage ...
On Thu, Apr 18, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > It also doesn't help in cases like usbdevfs. What if it wants to use the
> > device structure for some reason, like say a user reading
> > /proc/bus/usb/devices. It should increment the reference count, do it's
> > stuff and then
> It also doesn't help in cases like usbdevfs. What if it wants to use the
> device structure for some reason, like say a user reading
> /proc/bus/usb/devices. It should increment the reference count, do it's
> stuff and then decrement it. But it doesn't have a deallocate like call.
> As a result,
On Thu, Apr 18, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > > It "should" only shake out code that doesn't play by today's rules,
> > > right? Or am I missing something?
> >
> > Yes. It shook out the fact that uhci.c wasn't updated to play by the new
> > rules.
>
> No, a code inspection
> > It "should" only shake out code that doesn't play by today's rules,
> > right? Or am I missing something?
>
> Yes. It shook out the fact that uhci.c wasn't updated to play by the new
> rules.
No, a code inspection shook out the fact that it didn't even
play by the 2.4 rules, which require H
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.431 -> 1.432
# drivers/usb/hcd/ehc
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.433 -> 1.434
#MAINTAINER
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.425 -> 1.426
#drivers/usb/wacom.
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.432 -> 1.433
# drivers/usb/hpusbsc
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.429 -> 1.430
#MAINTAINER
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.428 -> 1.429
# drivers/usb/usbnet.
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.430 -> 1.431
# drivers/usb/storage
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.426 -> 1.427
# drivers/usb/hub.
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.422 -> 1.423
# drivers/usb/stv680
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.424 -> 1.425
# drivers/usb/serial/
Pull from: bk://linuxusb.bkbits.net/marcelo-2.4
The individual patches will be sent in follow up messages to this email.
thanks,
greg k-h
MAINTAINERS | 14
drivers/usb/devio.c | 17
drivers/usb/hcd/ehci-hcd.c| 62 -
drivers/usb/hcd/ehci-me
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.427 -> 1.428
#drivers/usb/devio.
On Wed, Apr 17, 2002 at 11:55:45AM -0700, David Brownell wrote:
> This patch is a partial sync of the 2.4 EHCI with the 2.5 code,
> primarily to make sure that several non-NEC implementations
> will work without additional patches. It also includes a faster
> IRQ codepath, and various minor clean
> > Hmm, so you actually think it's a feature that driver refcounting
> > bugs can cause random flakiness for a couple years before
> > they're finally tracked down?
>
> This is the wrong way of doing that. Poisoning is the best of catching
> reference counting problems.
Not "best" ... as you co
On Thu, Apr 18, 2002, Greg KH <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 18, 2002 at 03:24:33PM -0400, Johannes Erdfelt wrote:
> >
> > This totally defeats the purpose of what reference counting is used for,
> > which is so we don't have to synchronize across different parts of the
> > code. Refere
On Thu, Apr 18, 2002 at 04:06:32PM -0400, Johannes Erdfelt wrote:
> On Thu, Apr 18, 2002, Greg KH <[EMAIL PROTECTED]> wrote:
> > On Thu, Apr 18, 2002 at 03:24:33PM -0400, Johannes Erdfelt wrote:
> > >
> > > This totally defeats the purpose of what reference counting is used for,
> > > which is so
> I'm all for correctness, but you've made everything complicated along
> the way.
So what's complicated? Seems simple to me.
Device refcount is N
driver probe()
... use the device a lot
driver disconnect ()
Device refcount is back to N
If the count isn't N then
On Thu, Apr 18, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > I'm all for correctness, but you've made everything complicated along
> > the way.
>
> So what's complicated? Seems simple to me.
>
> Device refcount is N
> driver probe()
> ... use the device a lot
>
On Thu, Apr 18, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > It's because of this ill conceived code:
>
> You want to shoot the messenger, rather than
> paying attention to the message ...
>
> It seems clear to me that there were at least
> a few other things going wrong. Fixing them
> w
On Thu, Apr 18, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > > The simple fix is to invalidate those qh->dev pointers earlier.
> > >
> > > ...
> >
> > The real fix is to put the reference counting back to the way it was and
> > is supposed to be.
>
> Hmm, so you actually think it's a fea
> It's because of this ill conceived code:
You want to shoot the messenger, rather than
paying attention to the message ...
It seems clear to me that there were at least
a few other things going wrong. Fixing them
would prevent the BUG(). Correctly written
drivers won't ever see that failure m
On Thu, Apr 18, 2002 at 03:24:33PM -0400, Johannes Erdfelt wrote:
>
> This totally defeats the purpose of what reference counting is used for,
> which is so we don't have to synchronize across different parts of the
> code. Reference counting makes it easier and now it looks like in 2.5
> that we
> > The simple fix is to invalidate those qh->dev pointers earlier.
> >
> > ...
>
> The real fix is to put the reference counting back to the way it was and
> is supposed to be.
Hmm, so you actually think it's a feature that driver refcounting
bugs can cause random flakiness for a couple years
On Thu, Apr 18, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > It doesn't have to be, we can decrement the reference earlier, but it won't
> > change how correct the code is, it'll just result in the memory being freed
> > 1ms earlier.
>
> Well, next frame plus random interrupt latency later
On Thu, Apr 18, 2002, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I have now seen for the second time a BUG() at usb.h:1074
> usb_dec_dev_use() called by
> uhci_free_qh() called by
> uhci_free_pending_qhs() called by
> uhci_interrupt() called by handle_IRQ_event().
>
>
Dear Matt, dear David , dear all
you may remember the trouble I discussed already a few days ago when
connecting an "ARCHOS Jukebox Recorder 20" to a
PCI-usb card with nec chip onboard.
Meanwhile I have upgraded 2.4.19-pre7 and added the patch
ehci24-0417.patch on top.
everything compiles fine.
> > (Does qh->dev really need to be valid for each qh on the
> > qh_remove_list, though? Could that be invalidated when
> > each qh was put on that list -- usb_dec_dev_use and null the
> > pointer?)
>
> It doesn't have to be, we can decrement the reference earlier, but it won't
> change how corr
On Thu, Apr 18, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > It may be non-null, but qh is not on any list. There is no way that it
> > can be referenced after uhci_free_qh is called.
>
> It's not uhci_free_qh() that's in question, but uhci_free_dev().
> There'd be trouble if you were wron
Note, retitled this thread -- I think the problem Andries reported is
most likely tied to the seemingly flakey enumerations he saw (that
can continue with the original subject line), but I'd like to find out
if this is a real issue in uhci.
> > > > ... though I wonder if the way uhci.c works, it
On Thu, Apr 18, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > > ... though I wonder if the way uhci.c works, it might not leave the
> > > qh->dev field valid rather "late" after unlinking associated URBs.
> >
> > qh->dev is always valid.
> >
> > > That'd be fine, except uhci_free_dev() doe
> > Is there some webpage I read it to find out the status of USB 2.0 support
> > in Linux ? (In particular the "highspeed mode" or whatever 480mbit/sec is
> > called).
> >
> > If not, could some enlighten me ?
>
> No webpage so far ... just try it out! ...
Since I'm getting a bunch of questi
> > ... though I wonder if the way uhci.c works, it might not leave the
> > qh->dev field valid rather "late" after unlinking associated URBs.
>
> qh->dev is always valid.
>
> > That'd be fine, except uhci_free_dev() doesn't ensure that such
> > device state is all gone. (No such logic in usb-u
> It was at boot time, the usb-storage module was not loaded.
> Devices (now, after a reboot):
>
> 1. USB UHCI-alt Root Hub
> 2. hub 0451:1446
> 3. hub 0451:1446
> 4. keyboard / hidmouse 05e3:000a
> 3a. eUSB SmartMedia / CompactFlash Adapter 04e6:0005
>
> with numbering and inden
On Thu, 18 Apr 2002 [EMAIL PROTECTED] wrote:
| > I have now seen for the second time a BUG() at usb.h:1074
| > usb_dec_dev_use() called by
| > uhci_free_qh() called by
| > uhci_free_pending_qhs() called by
| > uhci_interrupt() called by handle_IRQ_event
--- Johannes Erdfelt <[EMAIL PROTECTED]> wrote: >
On Mon, Apr 15, 2002, shiju mathew
> <[EMAIL PROTECTED]> wrote:
> > I am new to usb. I have a basic question. I
> am
> > doing some work on sa1110 board where we have a
> > usb-client device. It is connected via a usb cable
> to
> > the usb
> I have now seen for the second time a BUG() at usb.h:1074
> usb_dec_dev_use() called by
> uhci_free_qh() called by
> uhci_free_pending_qhs() called by
> uhci_interrupt() called by handle_IRQ_event().
>
> Since it is not easily reproducible, I
On Thu, 18 Apr 2002 16:48, joyce tan wrote:
> Does the current kernel have support for usb composite
> device?
Yep. Most drivers work on a "per-interface" basis.
Brad
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourc
63 matches
Mail list logo
