Hello,
This set of patches implements abstracted budgeting logic for the ehci
scheduler that both takes advantage of hardware features not currently
exploited by the current schedulers (FSTNs and sITD backpointers) and
makes a greater effort to get the niggling corner cases of scheduling
restricti
On 9/23/06, Greg KH <[EMAIL PROTECTED]> wrote:
> Read Documenation/SubmittingPatches for the proper format.
Thank you.
There's at least one bug that turned up just before the weekend that I
want to quash first, then I will update the patchset and post.
Monty
On 9/25/06, Gerhard Pircher <[EMAIL PROTECTED]> wrote:
> 1) The EHCI driver uses a structure called "echi_qh", which contains
>both data to be accessed by the USB hardware through DMA, and
>private housekeeping data.
Yes. I am currently tromping through all of this code with steel-toed
b
On 9/22/06, Greg KH <[EMAIL PROTECTED]> wrote:
> > Should I post them to the list or this sufficient?
>
> Please post them.
OK. Any specific subject line format? The pattern I've seen for
other patches has been for patches already signed off on.
Monty
--
I forgot to mention: the patchset is against 2.6.18-rc7-git4
Monty
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business t
Hello David and Greg,
I've completed an incremental version of my patchset for the new EHCI
scheduler. It is broken up into 14 seperate patches and each
incremental yields a valid/working ehci scheduler. Naturally,
they're all meant to all be applied at once but they can be evaluated
individuall
I've been able to complete an updated [bugfix] version of the new
ehci-scheduler patch that should address the bug reports that have
come in.
The download page for the new version (available for 2.6.17 through
2.6.18-rc7-git4) is at:
http://web.mit.edu/xiphmont/Public/kernel/
The direct links to
On 8/31/06, David Brownell <[EMAIL PROTECTED]> wrote:
> > I'm committed to seeing this patch to either oblivion or production,
> > and globally altering whitespace is going to blow my time for *no net
> > benefit to anyone*.
>
> Cleanups like these _do_ have benefit.
Never said otherwise. I'd obj
On 8/31/06, Greg KH <[EMAIL PROTECTED]> wrote:
>
> Does this patch conflict with yours?
I read the first few pages, it does. However, something massively
messed the size of the thing when I saved it out to read in emacs. I
thought this was a 10,000 line or so patch. it isn't; it's relativ
On 8/30/06, David Brownell <[EMAIL PROTECTED]> wrote:
> On Wednesday 30 August 2006 4:36 pm, Christopher Montgomery wrote:
> > I'd not normally complain, but
> >
> > I'll need to do addiitonal work and release an all new patchset of the
> > e
I'd not normally complain, but
I'll need to do addiitonal work and release an all new patchset of the
ehci-scheduler... just to deal with cosmetic whitespace changes?
Monty
-
Using Tomcat but need to do more? Need to sup
[resending again; sourceforge's SMTP servers appear to be unhappy.
The original mails bounced back to me after timing out]
While I continue working to split my scheduler patch up into smaller
bits that are easier to review, I've tossed the monolithic version up
on the web for testing.
http://web.
While I continue working to split my scheduler patch up into smaller
bits that are easier to review, I've tossed the monolithic version up
on the web for testing.
http://web.mit.edu/xiphmont/Public/kernel/
Short summary: It's an attempt to write the first fully complete
bandwidth budgeter/schedul
David,
Sorry my patches are taking so long to assemble. What is the current
correct kernel version against which to be patching?
Thanks, Monty
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Te
On 8/4/06, David Brownell <[EMAIL PROTECTED]> wrote:
> Did you try with 2.6.18-rc3? There's a Kconfig option for an
> improved interrupt scheduler, which might help especially with
> all those low speed devices.
Actually, assuming I'm reading the spec right, I've come to realize
Dan's improved sc
On 7/22/06, Ian Stirling <[EMAIL PROTECTED]> wrote:
> Config/... as my earlier message on USB - though with the bandwidth
> enforcement
> turned off so it actually plays sound, when plugged into the USB1 port.
>
> 2.6.17.
>
> Basically - playing sound with
> mplayer -ao alsa:device=hw=1 or whatever
> > I see that's exactly what's happening. It merely seems unfortunate.
>
> That sort of behavior is inevitable in hardware-parallel systems.
>
> But it's also a rather minor failure mode, and the only folk who
> seem to run into it are people tweaking host controller drivers
> and adding lots
On 7/5/06, David Brownell <[EMAIL PROTECTED]> wrote:
> On Wednesday 05 July 2006 1:52 pm, Christopher Montgomery wrote:
> > On 7/5/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> >
> > > I'm hampered by lack of detailed knowledge of the driver. However it
>
On 7/5/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> I'm hampered by lack of detailed knowledge of the driver. However it
> seems to me that those two calls should affect the schedule (cheap) and
> not the budget (expensive).
Oh, hmm. That's actually not a bad idea. Some part of me is saying 'du
On 7/5/06, David Brownell <[EMAIL PROTECTED]> wrote:
> On Wednesday 05 July 2006 8:42 am, Christopher Montgomery wrote:
>
> > The hub is plugged in doing nothing.
>
> Except being regularly polled "did anything happen" about 4x/second.
> It's certainly act
On 7/5/06, David Brownell <[EMAIL PROTECTED]> wrote:
> To repeat myself: the instant the physical disconnect happens,
> then pending transfers to that device's endpoints may trigger
> USB transfer errors. And that can happen a LONG time before any
> component of the USB stack (e.g. qh_completion
On 7/5/06, David Brownell <[EMAIL PROTECTED]> wrote:
> On Wednesday 05 July 2006 8:30 am, Christopher Montgomery wrote:
>
> > / the two lines below
> > */
> >
> >
On 7/5/06, David Brownell <[EMAIL PROTECTED]> wrote:
> On Wednesday 05 July 2006 7:16 am, Christopher Montgomery wrote:
> Odd ... "interwoven" certainly allows gaps, and all of your
> additional details agree completely with the facts as I had
> pointed out.
I think w
On 7/5/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> ehci-hcd doesn't schedule endpoints; it schedules QHs.
Effectively the same thing. An INTR endpoint maps to one and only one
QH in the schedule.
As for ISO endpoints, it schedules the stream. Each ISO endpoint has
one and exactly one stream.
S
On 7/5/06, Christopher Montgomery <[EMAIL PROTECTED]> wrote:
> / the two lines below
> */
>
> intr_deschedule (ehci, qh);
> (void) periodic_qh_sched
On 7/5/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> > ) before
> > deciding the endpoint EPROTO fault calls for tearing it down and
> > setting it back up. Active/submitted URBs potentially have nothing to
> > do with it; it is happening even when my devices are idle.
>
> I'm not terribly familiar
On 7/5/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> The only catch is that you have to make sure usbcore isn't in use, because
> the kernel won't let you unload modules that are being used. For usbcore,
> this means you first have to unload all the other USB driver modules and
> you have to unmoun
On 7/5/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> Actually it is. Look in drivers/usb/core/hub.c at the
> usb_set_device_state() routine.
will do.
> Potentially tight doesn't have to mean tight. Higher-level drivers should
> strive to avoid immediate resubmissions of URBs that fail because of
On 7/5/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> Ummm... I've lost track of the original question. What is suboptimal and
> would be painful to fix?
The fact that when I unplug a hub/device the ehci work handler is
descheduling/rescheduling the endpoints repeatedly [because each hit
in the har
On 7/3/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> > The part I forgot to mention is that usb-hub.c implements a magic
> > number of ten consecutive interrupt errors on a given hcd before it
> > starts aggressively resetting/downing hardware.
>
> Ah, okay. That's different from what I thought you
On 7/2/06, David Brownell <[EMAIL PROTECTED]> wrote:
> On Sunday 02 July 2006 6:29 am, Christopher Montgomery wrote:
>
> > Disconnecting a hub/device causes two things to happen at the same time:
> >
> > 1) usb_disconnect is called on the root device.
> > 2) ea
On 7/2/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> I don't understand the problem you are describing. The kernel doesn't
> kill off an IRQ unless it gets a lot of unhandled interrupts (99900 out of
> the last 10). But none of the interrupts you mention will be
> unhandled -- ehci-hcd will han
I didn't reply to all. oops.
-- Forwarded message --
From: Christopher Montgomery <[EMAIL PROTECTED]>
Date: Jul 2, 2006 12:17 PM
Subject: Re: [linux-usb-devel] new EHCI scheduler and shudtown
question / interrupt race
To: Alan Stern <[EMAIL PROTECTED]>
On 7
I'm putting the finishing touches on the new EHCI scheduler and
noticed an interesting 'problem' in shutdown. In practice it usually
doesn't work out to being a bug, but it appears to be unintentional
and potentially problematic on slow CPUs when a hub with lots of
devices is detached.
In summary
There is currently no FSTN support, just placeholder code in ehci-sched.c.
I have implemented FSTN support (along with sITD backpointer support)
and am in the process of implementing a new TT scheduler as well. My
work is currently against 2.6.17-rc3. Enough has happened in the USB
code that my
Oh, a quick question that's been bugging me...
I assume that intr_submit() in ehci-sched.c also handles high-speed
endpoints (not just fs/ls endpoints). If so, why does
check_intr_schedule() not only blindly always assign a cmask, but also
blindly check that cmask against TT scheduling slots? T
I've independently found Dan Streetman's ehci TT scheduler patches
looking for some other ssplit scheduling rule clarifications. He
implements the part I was going to do last [schedule counting]. At
this point, I've implemented the parts he didn't (FSTN and sITD
backpointer support for frame spa
On 5/12/06, David Brownell <[EMAIL PROTECTED]> wrote:
That is, your beef is with the weak TT scheduling, which isn't something
that OHCI (or UHCI) does, and which accordingly can't be borrowed from
either of those drivers.
Vehement agreement. I'm looking to the other approaches and other
sche
On 5/11/06, David Brownell <[EMAIL PROTECTED]> wrote:
On Thursday 11 May 2006 8:49 am, Christopher Montgomery wrote:
> (If so, the isos are occurring in totally random places in a given frame).
Nope. Periodic transfers take up the second 90% of the frame (at most).
And this doesn&#
On 5/12/06, David Brownell <[EMAIL PROTECTED]> wrote:
Let me repeat that: TT scheduling and highspeed scheduling interfere
with each other. You can't perform one in ignorance of the other.
I believe we are vehemently agreeing with one another :-)
> Correct, but the reason we need to shift
On 5/13/06, David Brownell <[EMAIL PROTECTED]> wrote:
On Thursday 11 May 2006 8:49 am, Christopher Montgomery wrote:
> I also forgot the example of OHCI, which appears to do some/all of the
> actual intraframe scheduling in hardware. Is it just sending out
> transaction packe
On 5/11/06, David Brownell <[EMAIL PROTECTED]> wrote:
On Wednesday 10 May 2006 9:38 pm, Christopher Montgomery wrote:
> On 5/10/06, David Brownell <[EMAIL PROTECTED]> wrote:
> > On Wednesday 10 May 2006 10:35 am, Christopher Montgomery wrote:
> > > In some
> &
On 5/11/06, Christopher Montgomery <[EMAIL PROTECTED]> wrote:
On 5/10/06, David Brownell <[EMAIL PROTECTED]> wrote:
> On Wednesday 10 May 2006 10:35 am, Christopher Montgomery wrote:
> > In some
> > ways it's easier to just stack requests into the full-speed fr
On 5/10/06, David Brownell <[EMAIL PROTECTED]> wrote:
On Wednesday 10 May 2006 10:35 am, Christopher Montgomery wrote:
> In some
> ways it's easier to just stack requests into the full-speed frame and
> then plop the splits into whatever uFrame that happens to work out to,
One new question, hopefully this one is just rote arcana to one of you
The current scheduler strategy always tries to place a given periodic
request (be it iso or intr) into the same uFrame slot in all scheduled
HFrames. Is this a requirement of the spec (I don't recall seeing
such a restric
Hi David,
I thought my post got lost; I never saw it appear and hadn't seen
replies. Scratch that, I was *hoping* it got lost, as more code
research later showed each question was at least partially
nonsensical.
At this point, the actual ISO transfer machinery all looks perfectly
solid. The pr
I've done some of the requisite homework myself for getting full speed
audio devices to work properly through ehci and TTs on a 2.0 hub
(playback *and* capture). At this point it all works although my
changes are not production-ready.
I have three specific questions for now.
The primary reason
47 matches
Mail list logo
