On Sat, May 15, 2004 at 10:37:10AM -0700, Linus Torvalds wrote:
> Replace all "led" with "cytherm". The code was crap, and would never have
> compiled with debugging on anyway.
I fixed my crappy code. :)
diff -urN linux-2.6.6/drivers/usb/misc/cytherm.c
linux-2.6.6-cytherm/drivers/usb/misc/cyther
No message body: [EMAIL PROTECTED]
Original message follows.
---
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 mont
On Wed, May 19, 2004 at 10:33:21PM +0200, Erik Rigtorp wrote:
> On Sat, May 15, 2004 at 10:37:10AM -0700, Linus Torvalds wrote:
> > Replace all "led" with "cytherm". The code was crap, and would never have
> > compiled with debugging on anyway.
>
> I fixed my crappy code. :)
Linus already did it
On Wed, 19 May 2004, David Brownell wrote:
> Point being that there's some time, not much more than 1/4 sec
> after the "failing" operation starts, where we should know
> that either (a) some subtree was disconnected and that's why
> we're failing, or else (b) there wasn't a disconnect, so we're
>
Alan Stern wrote:
On Wed, 19 May 2004, David Brownell wrote:
That's the scenario I mentioned: state represented by
stack context in khubd. In this case, context that knows
it's going to be first debouncing etc.
There are other cases where khubd's stack context isn't involved.
Disconnecting a h
Hi,
the previous patch was buggy. The state must be set _before_ the
condition is checked, or there's a window missing a wakeup.
This incremental change set fixes that.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [pa
On Wed, 19 May 2004, David Brownell wrote:
> Alan Stern wrote:
> >
> > I don't understand your point here. Imagine this: hub A reports a new
> > connection on one of its ports. Khubd sees this and goes through
> > debouncing etc. While this is happening hub A is unplugged. Since
> > debouncin
Hi,
this was buggy for the same reason that the old msleep was buggy.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
==
Hi,
this is in kobil_sct.
It uses msleep() and replaces needless GFP_ATOMICs with GFP_NOIO
as this function can sleep.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
=
Alan Stern wrote:
On Tue, 18 May 2004, David Brownell wrote:
Alan Stern wrote:
I'm all in favor of something like this. Do you have any ideas on how we
should handle the case where the hub itself was disconnected but we don't
yet know that it's gone? We wouldn't want to log a KERN_ALERT messag
> Please don't apply this change. It conflicts with a patch I sent to Matt
> Dharm yesterday.
OK, I see. Am I under some curse making only conflicting changes ;-)?
Regards
Oliver
---
This SF.Net email is sponsored by
On Wed, 19 May 2004, Oliver Neukum wrote:
> Here's one you overlooked.
>
> Regards
> Oliver
>
> You can import this changeset into BK by piping this whole message to:
> '| bk receive [path to repository]' or apply the patch as usual.
>
> =
On Wed, 19 May 2004, Herbert Xu wrote:
> > OK, how about this patch?
>
> Let's fix QHs/TDs too. Plus I forgot to set the age when the current
> pending list is removed...
This looks very good. Give me some time to study and test it, and I'll
get back to you.
Alan Stern
---
Am Mittwoch, 19. Mai 2004 02:29 schrieb Greg KH:
> On Tue, May 18, 2004 at 09:20:40AM +0200, Oliver Neukum wrote:
> > Am Dienstag, 18. Mai 2004 02:37 schrieb David Brownell:
> > > >>this purges wait_ms() from ehci.
> > > >
> > > > David, look sane?
> > >
> > > I'd rather have a patch that covered
On Wed, May 19, 2004 at 11:02:52PM +1000, herbert wrote:
> On Thu, May 13, 2004 at 10:26:25PM -0400, Alan Stern wrote:
> >
> > Nothing guarantees it! That's one of the other things that needs to be
> > fixed. The way I eventually want it to work is that there will be a list
> > of urbp's that ha
On Thu, May 13, 2004 at 10:26:25PM -0400, Alan Stern wrote:
>
> Nothing guarantees it! That's one of the other things that needs to be
> fixed. The way I eventually want it to work is that there will be a list
> of urbp's that have been removed from the schedule and are waiting for the
> hardwar
BANNED FILENAME ALERT
Our virus checker found
banned filename: .exe
in your email to the following recipient:
-> [EMAIL PROTECTED]
Delivery of the email was stopped!
Please check your system for viruses,
or ask your system administrator to do so.
For your reference, here are headers from yo
The original message was received at Wed, 19 May 2004 14:17:13 +0200 (CEST)
from mrelay2.uni-hannover.de [130.75.2.5]
- The following addresses had permanent fatal errors -
<[EMAIL PROTECTED]>
(reason: 550 5.1.1 <[EMAIL PROTECTED]>... User unknown)
(expanded from: <[EMAIL PROTEC
Your message
To: [EMAIL PROTECTED]
Subject: Failure ([EMAIL PROTECTED])
Sent:Wed, 19 May 2004 04:57:00 -0700
did not reach the following recipient(s):
[EMAIL PROTECTED] on Wed, 19 May 2004 05:06:59 -0700
The recipient name is not recognized
The MTS-ID of the original m
Greg,
There is a problem in the usblp GET_DEVICE_ID ioctl() implementation. The patch
below (against 2.6 current) fixes the code to be according to the official usb
printer spec.
Most printers are not affected by this fix, as they use interface 0 and
alternate 0. For those, nothing changes. But m
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
[EMAIL PROTECTED]
This message has been rejected because it has
a potentially e
21 matches
Mail list logo
