On Thursday 24 July 2003 22:20, Alan Stern wrote:
>On Thu, 24 Jul 2003, David Brownell wrote:
>> Alan Stern wrote:
>> > You can't set periodic_iso_limit to 1024 on UHCI, because the
>> > driver reserves a grace period of 10 frames. The largest legal
>> > value is therefore UHCI_NUMFRAMES - 11.
>
>
As an experiment, can you renice the usb-storage control thread to
something like -10 or so, and see if that improves things any?
Matt
On Thu, Jul 24, 2003 at 07:52:50PM +0200, kri wrote:
> > Many people, including myself, have observed system stalls when using
> > usb-storage. It happens when c
On Thu, 24 Jul 2003, David Brownell wrote:
> Alan Stern wrote:
>
> > But doesn't there have to be _something_ there so that URBs won't fail the
> > bogus-maxpacket check in usb_submit_urb()?
>
> Handled by usb_new_device(), which is the first thing to actually
> issue a request (SET_ADDRESS) to
On Thu, 24 Jul 2003, David Brownell wrote:
> Alan Stern wrote:
> >
> > You can't set periodic_iso_limit to 1024 on UHCI, because the driver
> > reserves a grace period of 10 frames. The largest legal value is
> > therefore UHCI_NUMFRAMES - 11.
Shortly after sending that off, I realized it was n
Pering, Trevor wrote:
Hello -- I'm trying to understand the OHCI spec in order to enable
remote wakeup. My understanding is that when the system is about to
enter the suspend state, that I need to instruct the individual devices
to activate remote wakeup by setting the Device_Remote_Wakeup feature
Alan Stern wrote:
On Thu, 24 Jul 2003, David Brownell wrote:
Alan Stern wrote:
If David agrees, this is ready to be applied.
Looks fine to me except that register_root_hub() shouldn't
set a potentially bogus (at high speed) bMaxPacketSize0:
+ usb_dev->descriptor.bMaxPacketSize0 = 8;
64 is legal
[RESEND - this time with patch!]
This patch:
- Makes the cdc code handle a Motorola cable modem that stores
CDC descriptors in the wrong place. The workaround might be
helpful for other hardware too. (This was a 2.4 regression.)
- Recognizes another Zaurus (PXA 255 based clamshell,
Hello -- I'm trying to understand the OHCI spec in order to enable
remote wakeup. My understanding is that when the system is about to
enter the suspend state, that I need to instruct the individual devices
to activate remote wakeup by setting the Device_Remote_Wakeup feature
bit. I'm unclear on ho
Hi!
> > In 2.6.0-test1, OHCI is non-functional after first suspend/resume, and
> > kills machine during secon suspend/resume cycle.
>
> I experience similar problems with UHCI:
>
> Before suspending to S3 I unload usb modules and afterwards I reload them, but it
> does not work again.
> (For te
Hi!
> >Can you try echo 4 > /proc/acpi/sleep? echo 3 breaks it, too, but that
> >is little harder to set up.
>
> I usually test with "apm -s" ... since I've yet to come up with
> an ACPI configuration that works properly. IRQ misconfiguration
> for USB is still a blocking issue for many people (
Hi!
> > In 2.6.0-test1, OHCI is non-functional after first suspend/resume, and
> > kills machine during secon suspend/resume cycle.
>
> I experience similar problems with UHCI:
Strange, UHCI worked for me last time I tried. I'll try again soon...
On Thu, 24 Jul 2003, David Brownell wrote:
> Alan Stern wrote:
> >
> > If David agrees, this is ready to be applied.
>
> Looks fine to me except that register_root_hub() shouldn't
> set a potentially bogus (at high speed) bMaxPacketSize0:
>
> > + usb_dev->descriptor.bMaxPacketSize0 = 8;
>
>
On Thu, 24 Jul 2003, David Brownell wrote:
> >>>It'd also be good to let USB device drivers know the biggest iso period
> >>>that can be scheduled. It's not necessarily the same as the biggest
> >>>interrupt period, and on EHCI it's also configurable. Otherwise drivers
> >>>will not be able to t
> Where did you see an option to 'enable extra checks in new queueing
> code'?
In the SCSI section ^^;;
Sorry I forgot to mention that. (and that after correctng my mail TWICE X(
)
--
Today is Setting Orange, the 59th day of Confusion in the YOLD 3169
pgp0.pgp
Description: PGP signature
Alan Stern wrote:
If David agrees, this is ready to be applied.
Looks fine to me except that register_root_hub() shouldn't
set a potentially bogus (at high speed) bMaxPacketSize0:
+ usb_dev->descriptor.bMaxPacketSize0 = 8;
64 is legal for both full and high speed root hubs. (There's
no such thing
This patch:
- Makes the cdc code handle a Motorola cable modem that stores
CDC descriptors in the wrong place. The workaround might be
helpful for other hardware too. (This was a 2.4 regression.)
- Recognizes another Zaurus (PXA 255 based clamshell, not yet
sold by Sharp in the US).
This patch renames usb_connect() to usb_choose_address(). It also adds
equivalent functionality for root hubs into usb_register_root_hub() so
that host controller drivers won't need to call it. That makes the
function internal to usbcore, so it's not exported any more.
Since the hc_simple dri
Vedran Rodic wrote:
indefinitely:
hub.c: new USB device 00:12.2-1, assigned address 2
usb.c: USB device not accepting new address=2 (error=-71)
hub.c: new USB device 00:12.2-1, assigned address 3
usb.c: USB device not accepting new address=3 (error=-71)
It turns out this is a hardware problem. W
I was looking at using the generic usb-serial driver as a debug console,
and so I tried a simple loopback test. I doubt I got all the config
registers set up correctly, but to double-check, I loaded Cypress's
bulktest firmware (which copies everything from EP2OUT to EP2IN) and
couldn't get that to
Ferenc-Jan wrote:
You're not making sense to me. If it fails in the same way,
it oopses; if it doesn't oops, you've got a different failure.
My apologies, I quoted too little of my previous posts.
The "Subject:" ought to suffice.
In setting up bluetooth networking something fails and connect
It'd also be good to let USB device drivers know the biggest iso period
that can be scheduled. It's not necessarily the same as the biggest
interrupt period, and on EHCI it's also configurable. Otherwise drivers
will not be able to tell in advance what requests are legal.
Is it always as large or
Where did you see an option to 'enable extra checks in new queueing code'?
Matt
On Thu, Jul 24, 2003 at 07:52:50PM +0200, kri wrote:
> > Many people, including myself, have observed system stalls when using
> > usb-storage. It happens when copying large amounts of data to a USB
> > device-- ever
On Wed, Jul 16, 2003 at 08:13:32PM +0200, Vedran Rodic wrote:
> Hi
>
> When connecting the usb storage device to USB 2 VIA host controller
> I get these messages repeated (with address incremented by one)
> indefinitely:
>
> hub.c: new USB device 00:12.2-1, assigned address 2
> usb.c: USB device
On Fri, 18 Jul 2003, Duncan Sands wrote:
> Hi Alan, Johannes, how about this? I tried to make as few changes to the
> existing code as possible. In my opinion it would make more sense to have
> the list of TDs belong to the QH and not the urb_priv, and free them when the
> QH is freed, but that
On Thu, 24 Jul 2003, Johannes Erdfelt wrote:
> On Thu, Jul 24, 2003, David Brownell <[EMAIL PROTECTED]> wrote:
> > Johannes Erdfelt wrote:
> > > This should probably go into the core since every HCD needs it to be set
> > > to 0.
> >
> > If we keep it, yes. But the only use of error_count seems
> Many people, including myself, have observed system stalls when using
> usb-storage. It happens when copying large amounts of data to a USB
> device-- everything (except the USB access) just stops for a little
> while. My best guess is that the block cache is filling up (easy since
Confirmed.
Johannes Erdfelt wrote:
On Thu, Jul 24, 2003, David Brownell <[EMAIL PROTECTED]> wrote:
Johannes Erdfelt wrote:
This should probably go into the core since every HCD needs it to be set
to 0.
If we keep it, yes. But the only use of error_count seems to be
in debug printk() calls ... is there a re
On Thu, Jul 24, 2003, David Brownell <[EMAIL PROTECTED]> wrote:
> Johannes Erdfelt wrote:
> > This should probably go into the core since every HCD needs it to be set
> > to 0.
>
> If we keep it, yes. But the only use of error_count seems to be
> in debug printk() calls ... is there a real reason
Johannes Erdfelt wrote:
My brain wasn't functioning well. error_count has been in since 2.4.
It's just as broken in uhci.o.
In fact it seems like only ehci and the sl811hs code initialize it...
two drivers, curiously enough, where the ISO code doesn't work so well.
This should probably go into th
Pavel Machek wrote:
Hi!
Good morning to you too!
In 2.6.0-test1, OHCI is non-functional after first suspend/resume, and
kills machine during secon suspend/resume cycle.
Hmm, last time I tested suspend/resume it worked fine.
That was 2.5.67, but the OHCI code hasn't had any
relevant changes since
On Thu, Jul 24, 2003, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Wed, 23 Jul 2003, Johannes Erdfelt wrote:
>
> > > UHCI does not initialize urb->error_count to 0 anywhere. Again,
> > > that probably ought to be done in usb_submit_urb(), anyway.
> >
> > I must have missed when urb->error_count
On Wed, 23 Jul 2003, Johannes Erdfelt wrote:
> > UHCI does not initialize urb->error_count to 0 anywhere. Again,
> > that probably ought to be done in usb_submit_urb(), anyway.
>
> I must have missed when urb->error_count was added. What is it for? Why
> didn't the patch that added it implem
Hello again,
I have a few things to add:
1) If uhci_hcd was never loaded before suspend, one has to press a key on the keyboard
after `echo 3 > /proc/acpi/sleep` in order to get the machine suspended. Wakeup does
not work in that case, reboot required.
2) It makes no difference whether the Log
> In 2.6.0-test1, OHCI is non-functional after first suspend/resume, and
> kills machine during secon suspend/resume cycle.
I experience similar problems with UHCI:
Before suspending to S3 I unload usb modules and afterwards I reload them, but it does
not work again.
(For testing I also plugged
Hi!
> >In 2.6.0-test1, OHCI is non-functional after first suspend/resume, and
> >kills machine during secon suspend/resume cycle.
>
> Hmm, last time I tested suspend/resume it worked fine.
> That was 2.5.67, but the OHCI code hasn't had any
> relevant changes since then.
> Evidently your system
Hello
after a couple of days, I am quite sure, that the problem is fixed (or at
least makes
it less critical) by the
patch you send me. I have still problems in case of bad USB connection,
as far as I understand it (on my PCB there is not the very best wirering of
the USB
connection). This seems t
36 matches
Mail list logo
