First off, Kevin, very sorry for the delay in getting this patch in, you
have been very patient.
In looking over this patch (the usbfs disconnect stuff, backported to
2.4), I'm not quite sure it is totally correct. So I wanted to send it
to the linux-usb-devel mailing list for others to look ove
On Thu, Sep 26, 2002 at 10:00:01AM -0700, Matthew Dharm wrote:
> Greg, this is an obivously correct patch for usb-storage. Please apply.
Applied, thanks.
greg k-h
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http:/
On Wed, Sep 25, 2002 at 09:17:06AM +0200, Roger Crettol wrote:
> Hello there !
>
> Below ist the story - in the attachment is a diff that's more like a
> real patch. Thanks for making it so easy to fix.
Applied, thanks.
greg k-h
---
This sf.
On Sun, Sep 22, 2002 at 01:45:52PM +0200, Tim Schmielau wrote:
> Dear Linux kernel code maintainer,
>
> on rechecking the current stable kernel code, I found some places where jiffies
> were compared in a way that seems to break when they wrap. For these,
> I made up patches to use the macros "ti
On Fri, Sep 20, 2002 at 08:27:48PM -0400, Andrew Pargeter wrote:
>
> 1- How do I build the code as a module? It looks like the Makefile in
> /driver/usb is pretty straightforward. I suppose I have run "make modules"
> from TOPDIR - is this what you have to run every time you make a change to
>
On Thu, Sep 26, 2002 at 10:01:59AM -0700, Matthew Dharm wrote:
> Greg --
>
> Thisis another patch for usb-storage. Apparently, ide_fix_driveid() isn't
> always available. We either need this patch or need to convince folks to
> make ide_fix_driveid() available on all arches.
Not applied, until
On Mon, Sep 23, 2002 at 08:29:13PM -0700, David Brownell wrote:
> The earlier patch synced to 2.5.34bk4, this one has one
> further update from today (already merged to Linus' tree).
>
> Please merge to Marcelo's latest, with the preceding
> patch. Thanks in advance!
Applied, thanks.
greg k-h
On Thu, Sep 26, 2002 at 12:04:02PM +0200, Oliver Neukum wrote:
> Hi,
>
> this fixes an unplugging problem and an SMP deadlock.
> It's for 2.4. Please apply.
Applied, but by using the patch, I could not do a 'bk receive' on the
changeset, as it said I was missing one :)
thanks,
greg k-h
-
On Thu, Sep 26, 2002 at 12:05:13PM +0200, Oliver Neukum wrote:
> Hi,
>
> this fixes a few SMP locking issues for kaweth.
> It's for 2.4. Please apply.
Applied, again from the text patch.
thanks,
greg k-h
---
This sf.net email is sponsored b
On Mon, Sep 23, 2002 at 08:22:30PM -0700, David Brownell wrote:
> This is a slightly updated version of the patch I sent before.
> Please merge to Marcelo's latest.
Applied, thanks.
greg k-h
---
This sf.net email is sponsored by:ThinkGeek
Wel
> This raises a generally interesting question: When should a driver
> module be loaded?
It is an interesting question, but it is not a kernel problem :-)
[..]
> I think it's clear that the answer must depend on the particular driver,
> and that no single scheme involving usage counts (or the
On Thu, 26 Sep 2002, Greg KH wrote:
> On Thu, Sep 26, 2002 at 09:14:48AM -0700, David Brownell wrote:
> > I think it _could_ be fine to do such rmmods, if all the module
> > remove races were removed ... and (for this issue) if the primitve
> > were actually "remove if the driver is not (a) in ac
>>>Well, that's a driver unload issue, which I think everyone agrees on the
>>>fact that it's not ok to do automatic driver unload when a device is
>>>removed, because of this very problem.
>>
>>I think it _could_ be fine to do such rmmods, if all the module
>>remove races were removed ... and (f
On Thu, Sep 26, 2002 at 09:14:48AM -0700, David Brownell wrote:
>
> >Yes, Pat and I have talked a lot about the need for a driver "state". I
> >think the current goal was to see how far we can get without needing it.
> >I was certainly cursing the lack of it today when trying to debug this
> >pr
Ok, here's an updated version of the previous patch I sent out, that
address all of the different comments that I received. It also has the
previously mentioned bug fixed. It is against a clean 2.5.38 kernel.
I changed the sprintf() calls to snprintf() and if people would check my
math, I would
On Thu, Sep 26, 2002 at 10:01:59AM -0700, Matthew Dharm wrote:
> Greg --
>
> Thisis another patch for usb-storage. Apparently, ide_fix_driveid() isn't
> always available. We either need this patch or need to convince folks to
> make ide_fix_driveid() available on all arches.
With some quick g
On Thu, Sep 26, 2002 at 11:51:34AM -0400, Alan Stern wrote:
> The pattern of errors you are getting is similar to one I've seen before.
> Some devices do not properly adhere to the standards, because the
> designers only bother to test them under Windows. In particular, the
> firmware in some dev
Greg --
Thisis another patch for usb-storage. Apparently, ide_fix_driveid() isn't
always available. We either need this patch or need to convince folks to
make ide_fix_driveid() available on all arches.
Matt
- Forwarded message from Björn Stenberg <[EMAIL PROTECTED]> -
Date: Thu, 26
Greg, this is an obivously correct patch for usb-storage. Please apply.
Matt
- Forwarded message from Alan Stern <[EMAIL PROTECTED]> -
Date: Thu, 26 Sep 2002 11:25:36 -0400 (EDT)
From: Alan Stern <[EMAIL PROTECTED]>
Subject: Another (!) patch for the abort handler
To: Matthew Dharm <[
>>> 1) If command_abort() is called by scsi subsytem, process deadlocks
>>> on wait_for_completion(&(us->notify))
>>
>> For this one, it'd be good to know if 2.5.latest does the same thing.
>
> 2.5.38 oopses on the last line if usb_stor_abort_transport (us->srb ==
> NULL). I attepted to fix it:
> Yes, Pat and I have talked a lot about the need for a driver "state". I
> think the current goal was to see how far we can get without needing it.
> I was certainly cursing the lack of it today when trying to debug this
> problem, but in the end, having it would have only masked over the
> rea
On Thu, 26 Sep 2002, Yuri Per wrote:
> 2.5.38 oopses on the last line if usb_stor_abort_transport (us->srb ==
> NULL). I attepted to fix it:
>
> --- linux-2.5.38-orig/drivers/usb/storage/transport.cSun Sep 22
> 08:25:06 2002
> +++ linux-2.5.38/drivers/usb/storage/transport.cThu Sep 26 17:
David Brownell wrote:
> Out of curiousity, which kind of support does your motherboard provide?
> There's the south bridge (VT8235), or the standalone chip (VT6202).
>
> It might matter; the VT602 hasn't always worked for me in PCI cards
> (due to what seem like PCI problems). The patches I sent
Hi,
this fixes a few SMP locking issues for kaweth.
It's for 2.4. Please apply.
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 fixes an unplugging problem and an SMP deadlock.
It's for 2.4. Please apply.
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.
=
When your fiddling with the sync codes it changes where the decoder thinks the
image starts. This happens to be inbetween YUV sequences. So if your
changing the sync codes you also need to chagne the YUV order.
In usbvision.c, usbvision_set_input() you'll see that we set the YUV order
with:
26 matches
Mail list logo
