[SIGH] That wasn't supposed to go out with the data inline, once I
realized how large it was. Hit ^C^C rather than ^X^X, though.
Anyway, most of the trace was after removing the modem from the hub to
get it working again. But the death of pppd was where the problem
started.
2.5.64 and
Write multiple cells in one function call, rather than one cell per
function call. Under maximum send load, this reduces cell writing
CPU usage from 0.0095% to 0.0085% on my machine. A 10% improvement! :)
speedtouch.c | 68
+++ 1 files
Hi all, must the transfer_buffer I provide with an urb be
aligned on, say, a double-word boundary or something like
that?
Thanks,
Duncan.
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Greg:
Further testing uncovered a _very_ minor error in usb-skeleton: there
should not be a debugging log message for a successful write.
This goes on top of the previous patch.
Alan Stern
= drivers/usb/usb-skeleton.c 1.37 vs edited =
--- 1.37/drivers/usb/usb-skeleton.c Wed Mar 5
Hi Joshua,
Try reading the subject you supplied... ;-) BTW, Dave wasn't
trying to move the blame elsewhere, just trying to tell you that when he
gets the traceback he may tell you to seek help elsewhere.
regards,
Am Montag, 10. März 2003 13:59 schrieb Duncan Sands:
Hi all, must the transfer_buffer I provide with an urb be
aligned on, say, a double-word boundary or something like
that?
The alignment requirements are specific to the hardware that happens
to be used. kmalloc() will return properly aligned
On Mon, 10 Mar 2003 19:36:04 +0100 Oliver Neukum [EMAIL PROTECTED] wrote:
| Am Montag, 10. März 2003 13:59 schrieb Duncan Sands:
| Hi all, must the transfer_buffer I provide with an urb be
| aligned on, say, a double-word boundary or something like
| that?
|
| The alignment requirements are
On Mon, Mar 10, 2003 at 10:52:17AM -0800, Randy.Dunlap wrote:
On Mon, 10 Mar 2003 19:36:04 +0100 Oliver Neukum [EMAIL PROTECTED] wrote:
| Am Montag, 10. März 2003 13:59 schrieb Duncan Sands:
| Hi all, must the transfer_buffer I provide with an urb be
| aligned on, say, a double-word
On Mon, Mar 10, 2003 at 11:46:51PM +1300, Bill Ryder wrote:
Greg KH wrote:
On Wed, Mar 05, 2003 at 11:50:52PM +1300, Bill Ryder wrote:
Greg KH requested more frequent and smaller patches so here is the
current working driver.
(I've been holding back to give a big update and
I still do not want/understand the need to create new ioctls for this
driver. If you rip that part out of the patch, I'd be glad to take the
rest of it, and then we can work on the ioctl issue together.
Why don't you want the ioctls? Is there another way to communicate
with the driver for
Right now, scheduling of periodic USB transactions (isochronous
interrupt) is maximally pessimistic: bandwidth is allocated on the
assumption that all the transactions will sometimes occur in the same
frame. (For low- and full-speed, that is; I don't know about high-speed.)
Is there any
On Mon, Mar 10, 2003 at 08:58:26PM +0100, Thomas Jarosch wrote:
I still do not want/understand the need to create new ioctls for this
driver. If you rip that part out of the patch, I'd be glad to take the
rest of it, and then we can work on the ioctl issue together.
Why don't you want
I still do not want/understand the need to create new ioctls for this
driver. If you rip that part out of the patch, I'd be glad to take the
rest of it, and then we can work on the ioctl issue together.
Why don't you want the ioctls? Is there another way to communicate
with the
Could this happen with the usb-uhci code as well? I didn't see a
similar completion list.
Is there a good way to track down how long and where interrupts are
being disabled?
Thanks.
--Brian
-Original Message-
From: Johannes Erdfelt [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 09,
usb-uhci works differently, so I don't think it could happen the same
way.
As for interrupts being disabled, that's a good question. I think there are
some tools to measure that somewhere.
IIRC two sources that are significant are IDE and APM.
JE
On Mon, Mar 10, 2003, Brian Williams [EMAIL
Could this be part of the reason for the problem?
From uhci.c, isochronous_find_limits():
if (last_urb) {
*end = (last_urb-start_frame + last_urb-number_of_packets) 1023;
ret = 0;
} else
ret = -1; /* no previous urb found */
On Mon, Mar 10, 2003 at 09:57:41PM +0100, Thomas Jarosch wrote:
I still do not want/understand the need to create new ioctls for this
driver. If you rip that part out of the patch, I'd be glad to take the
rest of it, and then we can work on the ioctl issue together.
Why don't
Looks like you already have a working patch that you could put on
those 100+ machines today :)
As many other people wanted this feature (I can forward you the
mails), it would be far better, if it becomes part of the stock
kernel. I could even do the 64 bit thunking layer if you want...
(but
On Tue, Mar 11, 2003 at 12:20:25AM +0100, Thomas Jarosch wrote:
(but if you do, watch out for the security problems in your ioctl
implementation, it didn't look secure at first glance...)
Ooops :-) What's wrong with it?
You're letting any user do this ioctl. If that's ok, fine.
You are
Dear, [EMAIL PROTECTED]
We hope your business is doing well on the Internet. We would like
to indroduce you to a guaranteed way to get thousands of new
responses possibly hundreds of new sales daily using the same
software we use and own!
WOULD YOU LIKE TO SEND A MESSAGE JUST LIKE THIS
Alan Stern wrote:
They could be distributed this way:
frame: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
period 1: * * * * * * * * * * * * * * * *
period 2: * * * * * * * *
period 4: *
21 matches
Mail list logo
