On Fri, 29 Oct 2004, David Brownell wrote:
> On Thursday 28 October 2004 14:08, Alan Stern wrote:
> > On Thu, 28 Oct 2004, David Brownell wrote:
> >
> > I intend to split it up into multiple patches, but the split won't be on
> > functional grounds. It will just be based on the source arrangeme
您好！
现为您提供中方以场地、厂房等配套设施折价投入、产品外销的中外合资项目。
合资大蒜系列产品项目简介
总投资：85万美元; 注册资金：60万美元;
投资比例：外方60％；中方40％; 合作15年; 产品100%外销;
厂况需求：厂房700平方米，电力45KVA，员工63人；
高强度纳米塑料钉补偿贸易
纳米塑钉制品与铁钉相比强度相等，抗弯能力大大高于铁钉，重量仅为铁钉的1
/4，不生锈，耐腐蚀，可加工，可着各种颜色。
合作方式：补偿贸易。由外方提供先进的塑料钉设备及其相关的
On Fri, Oct 29, 2004, Duncan Sands <[EMAIL PROTECTED]> wrote:
> On Friday 29 October 2004 18:50, Johannes Erdfelt wrote:
> > On Fri, Oct 29, 2004, Duncan Sands <[EMAIL PROTECTED]> wrote:
> > > Hi Johannes, maybe it should allocate multiple pages and then use scatter-gather
> > > io out of them. Th
On Friday 29 October 2004 16:27, Adrian Bunk wrote:
> On Fri, Oct 29, 2004 at 04:17:30PM -0700, David Brownell wrote:
> > p.s. Last I looked, GCC ignored unused inlines; no code
> > generated, no warnings. Did that change?
> >...
>
> It didn't change.
>
> But there are three different poss
xspam wrote:
kernel: usb 1-2: new high speed USB device using address 3
kernel: Initializing USB Mass Storage driver...
kernel: usb-storage: This device (05ab,0060,1106 S 06 P 50) has
unneeded SubClass and Protocol entries in unusual_devs.h
This has been fixed in kernel version 2.6.9. Thanks
On Fri, Oct 29, 2004 at 04:17:30PM -0700, David Brownell wrote:
> On Thursday 28 October 2004 17:28, Adrian Bunk wrote:
> > [ this time without the problems due to a digital signature... ]
> >
> > The patch below removes an unused function from drivers/usb/net/usbnet.c
>
> Actually in this case I
On Thursday 28 October 2004 17:28, Adrian Bunk wrote:
> [ this time without the problems due to a digital signature... ]
>
> The patch below removes an unused function from drivers/usb/net/usbnet.c
Actually in this case I'd rather leave the function there;
the documentation on this chip is hard t
Hi,
The loop construct (and following debug message) in the write data function of
the jumpshot storage driver seems to suggest that it should bail out after 10
waiting periods if the device's status still doesn't show ready. However it
looks like someone forgot to increment the variable on eac
On Fri, 29 Oct 2004 09:59:22 +0200, Duncan Sands <[EMAIL PROTECTED]> wrote:
> > > Most interesting. How many URBs do you use?
> >
> > It's configurable. I think I'm using 100 16KB URBs right now. That's
> > probably overkill, but our hardware can only tolerate about 200 us
> > worth of jitter b
Hi all
I've attached my updated drivers. I've been using these updates for
about a month with no major issues. Ping times over RNDIS get larger
after it has been running for a while but throughput is fine.
It still doesn't handle or is untested with some of the hardware
features that other chip
On Friday 29 October 2004 13:35, Alan Stern wrote:
> @@ -192,7 +192,6 @@
>
> /* memory lifecycle */
> struct usb_hcd *(*hcd_alloc) (void);
> - void(*hcd_free) (struct usb_hcd *hcd);
>
> /* manage i/o requests, device state */
> int (*urb_enqueue) (s
On Thursday 28 October 2004 14:08, Alan Stern wrote:
> On Thu, 28 Oct 2004, David Brownell wrote:
>
> I intend to split it up into multiple patches, but the split won't be on
> functional grounds. It will just be based on the source arrangement
> (like: everything in usb/core, everything in usb/
On Fri, 29 Oct 2004, Dieter Weber wrote:
> Hi!
> I am experiencing failures (see kern.log) when writing to the 05e3:0702 rev.
> 0.02 Genesys Logic IDE to USB 2.0 bridge with USB 2.0 speed with linux kernel
> 2.6.9. The drive has to be reset by unplugging power. Again plugging in the
> device ca
sunil saggar wrote:
hi all
while i was trying to compile usb-skeleton.o i got the
following error messages
from
/lib/modules/2.6.5-1.358/build/include/asm/hardirq.h:6,
from
/lib/modules/2.6.5-1.358/build/include/linux/delay.h:13,
from
/lib/modules/
Greg:
This patch changes the non-PCI-based OHCI-related host controller drivers,
removing the code that frees the driver-specific hcd structures.
Unfortunately I am not able to test it, because I don't have the necessary
hardware.
Alan Stern
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
===
Greg:
This patch removes the hcd release code from the final host controller
driver, dummy-hcd. Please apply.
Alan Stern
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
= drivers/usb/gadget/dummy_hcd.c 1.15 vs edited =
--- 1.15/drivers/usb/gadget/dummy_hcd.c 2004-10-20 12:38:08 -04:00
Greg:
This patch removes the code for deallocating the usb_hcd structure from
the three PCI-based host controller drivers. It also moves the embedded
struct usb_hcd member to the front of the larger driver-specific
structures, as required for the core to do its work. Please apply.
Alan Stern
Greg:
This patch contains changes to usbcore making the core responsible for
deallocating memory for usb_hcd structures, rather than calling back into
the host controller drivers. This solves a long-standing oops, since the
drivers may have been unloaded from memory by the time the release routin
Greg:
This patch reorganizes the startup and shutdown code in the dummy-hcd
driver to make it consistent with all the other host controller drivers.
For example, the platform device representing the HC hardware is
allocated separately and given as an argument to the probe() and remove()
routines
Greg:
Although this is the first patch in a series of six, it's not closely
related to the others. This includes a whole bunch of simple cleanups
for the dummy-hcd driver, all of which fall into the following categories:
Convert explicit container_of() to type-safe inline functions,
On Fri, Oct 29, 2004 at 01:06:34PM +0200, Axel Waggershauser wrote:
> Hi Eric,
>
> another question: Have you tried accessing two devices at the same time?
> If so, what was your total throughput per sec?
>
I haven't, but I'll give it a try over the next couple of days and let
you know what happ
On Fri, Oct 29, 2004 at 09:59:22AM +0200, Duncan Sands wrote:
> > > Most interesting. How many URBs do you use?
> >
> > It's configurable. I think I'm using 100 16KB URBs right now. That's
> > probably overkill, but our hardware can only tolerate about 200 us
> > worth of jitter before it over/u
On Fri, Oct 29, 2004 at 10:07:33AM +0200, Axel Waggershauser wrote:
> Hi,
>
> 1. looks like every byte transfered with your "fast usb" lib is
> memcopied at least two times: in your fusb*.cc code and in the usbfs
> kernel code, right? Meaning worrying about sg-list "optimized" drivers
> is sort of
On Fri, Oct 29, 2004, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Freitag, 29. Oktober 2004 20:44 schrieb David Brownell:
> > On Friday 29 October 2004 11:13, Johannes Erdfelt wrote:
> > > > If usbfs instead grabbed a bunch of non-contiguous
> > > > pages, copied the data into them from
Am Freitag, 29. Oktober 2004 20:44 schrieb David Brownell:
> On Friday 29 October 2004 11:13, Johannes Erdfelt wrote:
> > >If usbfs instead grabbed a bunch of non-contiguous
> > > pages, copied the data into them from user-space, and then sent it (using
> > > scatter-gather io), then there is n
On Friday 29 October 2004 11:13, Johannes Erdfelt wrote:
> > If usbfs instead grabbed a bunch of non-contiguous
> > pages, copied the data into them from user-space, and then sent it (using
> > scatter-gather io), then there is no longer any memory pressure problem.
> > What's more, there woul
On Friday 29 October 2004 09:49, Alan Stern wrote:
> On Fri, 29 Oct 2004, Johannes Berg wrote:
>
> > > Anyway, I don't see what can be done about it. The "host system error"
> > > means that there was a PCI abort (or something similar) while the USB
> > > controller was using the bus. Undoubte
On Friday 29 October 2004 18:50, Johannes Erdfelt wrote:
> On Fri, Oct 29, 2004, Duncan Sands <[EMAIL PROTECTED]> wrote:
> > > It probably will be significantly less. We have buffer size issues with
> > > usbfs and libusb.
> > >
> > > Older versions of libusb used the synchronous bulk read/write c
On Fri, Oct 29, 2004, Duncan Sands <[EMAIL PROTECTED]> wrote:
> > It probably will be significantly less. We have buffer size issues with
> > usbfs and libusb.
> >
> > Older versions of libusb used the synchronous bulk read/write calls and
> > those were limited to a page size. We've since switche
On Fri, 29 Oct 2004, Johannes Berg wrote:
> > Anyway, I don't see what can be done about it. The "host system error"
> > means that there was a PCI abort (or something similar) while the USB
> > controller was using the bus. Undoubtedly a hardware problem. Probably
> > it's intermittent beca
On Sun, 2004-10-24 at 12:51 -0400, Alan Stern wrote:
> I'm rather surprised that it managed to work after you plugged the mouse
> back in.
:-)
It does without problems though, repeatably (whenever I get this, I
don't use my USB mouse much)
> Anyway, I don't see what can be done about it. The "
Hi Eric,
another question: Have you tried accessing two devices at the same time?
If so, what was your total throughput per sec?
On Thu, 2004-10-28 at 13:25 -0700, Eric Blossom wrote:
> We built an FX2 based software radio peripheral and we routinely
> sustain 32MB/sec in either direction. CPU c
> 1. looks like every byte transfered with your "fast usb" lib is
> memcopied at least two times: in your fusb*.cc code and in the usbfs
> kernel code, right? Meaning worrying about sg-list "optimized" drivers
> is sort of unnecessary...
Memory bandwidth is usually much higher than USB bandwidth.
Hi,
On Thu, 2004-10-28 at 13:25 -0700, Eric Blossom wrote:
> We built an FX2 based software radio peripheral and we routinely
> sustain 32MB/sec in either direction. CPU consumption is minimal --
> on the order of 5% of a 1.4 GHz Pentium M. We did it all in user
> space using libusb, with an add
> > Most interesting. How many URBs do you use?
>
> It's configurable. I think I'm using 100 16KB URBs right now. That's
> probably overkill, but our hardware can only tolerate about 200 us
> worth of jitter before it over/under runs.
Do you ever have problems finding 100 * (4 contiguous pages)
> It probably will be significantly less. We have buffer size issues with
> usbfs and libusb.
>
> Older versions of libusb used the synchronous bulk read/write calls and
> those were limited to a page size. We've since switched to using
> asynchronous, URB based calls, which allow us buffer sizes
36 matches
Mail list logo
