On Sat, Jun 07, Wout Mertens wrote:
> Hi Olaf,
>
> Is the waiting absolutely necessary?
>
> Could it be shorter? Or could you make it only do that during coldplug
> phase?
>
> The reason I'm asking is because I use my USB memory key to log in, and
> that needs to wait 3 seconds (I patch it out
Alan, David, everyone else who might be able to help,
I've just caught an oops that seems to come from the EHCI code. This
happened while trying to communicate with my own USB 2.0 device (based
on the Cypress EZ-USB FX2), under vanilla 2.4.20. The device was
connected through a USB 2.0 hub (NEC c
Hi,
in kaweth I get from init_etherdev a device with the name 'ACTION=add'.
Is this a known brokenness?
Regards
Oliver
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the
On Sat, 7 Jun 2003, David Brownell wrote:
> Jeff Garzik wrote:
> >>
> >>strlcpy?
> >
> >
> > No need, when the length is obviously less.
>
> True, not "necessary" in this case ... but it's still
> IMO a much better practice. And if we're serious about
> rubbing out that family of bugs, we'll just
Hi Olaf,
Is the waiting absolutely necessary?
Could it be shorter? Or could you make it only do that during coldplug
phase?
The reason I'm asking is because I use my USB memory key to log in, and
that needs to wait 3 seconds (I patch it out of course) for no reason
whatsoever.
Thanks,
Wout.
O
On Sat, Jun 07, David Brownell wrote:
> Olaf Hering wrote:
>
> >>That "sleep" is a workaround for "uhci" and "usb-uhci" bugs:
> >>they don't queue control transfers. No complete user mode
> >>workaround is possible; it doesn't affect just hotplug, or
> >>even just usbfs-based applications.
> >
Olaf Hering wrote:
That "sleep" is a workaround for "uhci" and "usb-uhci" bugs:
they don't queue control transfers. No complete user mode
workaround is possible; it doesn't affect just hotplug, or
even just usbfs-based applications.
my patch fixes the timeouts. Have you even tried it?
Actually
Jeff Garzik wrote:
strlcpy?
No need, when the length is obviously less.
True, not "necessary" in this case ... but it's still
IMO a much better practice. And if we're serious about
rubbing out that family of bugs, we'll just deprecate
"strncpy" and eventually remove it from the kernel.
What's "o
On Sat, Jun 07, David Brownell wrote:
> Olaf Hering wrote:
> >Hi,
> >
> >there is a hardcoded sleep 3 in the usb.agent. But this is wrong,
> >because the kernel runs all hotplug events at once for a new hub. The
> >result is that every event still runs in parallel, just 3 seconds later.
>
> That
Olaf Hering wrote:
Hi,
there is a hardcoded sleep 3 in the usb.agent. But this is wrong,
because the kernel runs all hotplug events at once for a new hub. The
result is that every event still runs in parallel, just 3 seconds later.
That "sleep" is a workaround for "uhci" and "usb-uhci" bugs:
they
On Fri, Jun 06, 2003 at 04:52:38PM -0700, David Brownell wrote:
> Olaf Hering wrote:
> >-strncpy(info.driver, SHORT_DRIVER_DESC,
> >ETHTOOL_BUSINFO_LEN);
> >+strncpy(info.driver, driver_name, ETHTOOL_BUSINFO_LEN);
>
> strlcpy?
No need, when the length is obviously
I missed /etc/sysconfig/hotplug in usb.rc, fixed patch:
- do not use /etc/sysconfig/usb anymore, use /etc/sysconfig/hotplug
instead
- better check if usb was successfully activated
- wait up to 3 seconds for active usb events
- add two new /etc/sysconfig/hotplug variables:
* use HOTPLUG_USB_HOS
This is the Postfix program at host zam379.fz-juelich.de.
I'm sorry to have to inform you that the message returned
below could not be delivered to one or more destinations.
For further assistance, please send mail to
If you do so, please include this problem report. You can
delete your own tex
A few updates for usb.rc:
- do not use /etc/sysconfig/usb anymore, use /etc/sysconfig/hotplug
instead
- better check if usb was successfully activated
- wait up to 3 seconds for active usb events
- add two new /etc/sysconfig/hotplug variables:
* use HOTPLUG_USB_HOSTCONTROLLER_LIST to load a fix
please note to send ALL REPLY e-mail direct to
our Sales Representative at: [EMAIL PROTECTED]
Hi, Thank you for expressing
interest in ATGWS watches.
We would like to take this opportunity to offer
you our fine selection of Italian crafted Rolex Timepieces. You can
view our large
Oliver Neukum wrote:
Hi David,
you wrote:
- Devices on some EHCI controllers could handle DMA to/from high memory.
Driver probe() routines can notice this using a generic DMA call, then
tell higher level code (network, scsi, etc) about it like this:
if (dma_supported (&intf->dev, 0xfff
Alan Stern wrote:
David:
Did you ever come to any decision about whether to let the root hub
status URB timer continue to run during a PM suspend as opposed to
restarting it during a PM resume? Just curious...
Didn't really look at it. Whichever fix is simpler;
and letting it continue to run s
Hi,
this patch add LP_ABORTOPEN ioctl in usb lp device driver.
As you can see a member flags is nedeed in struct usblp, i think we could
move usblp->used in usblp->flags.
For example, in usblp_open rather that check usblp->used we can do something
like:
if (test_and_set_bit(LP_BUSY_BIT_POS), usblp
Hi,
there is a hardcoded sleep 3 in the usb.agent. But this is wrong,
because the kernel runs all hotplug events at once for a new hub. The
result is that every event still runs in parallel, just 3 seconds later.
This patch implements an userland fifo.
touch an unique file
wait one second to let
Hi David,
you wrote:
- Devices on some EHCI controllers could handle DMA to/from high memory.
Driver probe() routines can notice this using a generic DMA call, then
tell higher level code (network, scsi, etc) about it like this:
if (dma_supported (&intf->dev, 0xULL))
20 matches
Mail list logo
