Re: USB transfer_buffer allocations on 64bit systems

[Pedro Ribeiro]

On 14 April 2010 17:36, Daniel Mack <daniel@xxxxxxxx> wrote:
> On Wed, Apr 14, 2010 at 10:08:47AM -0400, Alan Stern wrote:
>> On Wed, 14 Apr 2010, Pedro Ribeiro wrote:
>> > On 14 April 2010 11:09, Daniel Mack <daniel@xxxxxxxx> wrote:
>> > > Thanks! So the only thing I can do for now is submit exactly this patch.
>> > > At least, it helps you and it shouldn't break anything. The question
>> > > remains whether this type of memory should be used for all
>> > > transfer_buffers.
>> > >
>> >
>> > Is there any chance you could push this to -stable? I don't care
>> > because I always use the latest kernel, but the next Debian stable and
>> > Ubuntu LTS are going to use 2.6.32.
>>
>> No!  Please don't do it: Don't submit the patch and _certainly_ don't
>> submit it to -stable.  It doesn't fix anything; it only works around a
>> bug, and at the moment we don't even know if the bug is in the kernel
>> or in Pedro's hardware (and even though it affects two different
>> systems of his, nobody else has reported a similar problem).  Papering
>> over it will only remove the incentive to fix it properly.
>
> No worries - I agree. But unfortunately, I'm out of ideas now, and my
> initial thoughts about what might cause the trouble were abviously not
> able to explain the issue. Does anyone see further steps of tracking
> this issue down?
>
> Thanks,
> Daniel
>

Well if this is a dirty / dangerous hack, what about your first patch?
I've been testing it for days and has given me no problems.

The best way to trigger the issue is to connect a dib0700 based DVB
adapter. All you need is to connect it. Since it polls for the remote
control every 50 msec, it causes a constant interference. Beware that
on 2.6.34 this behaviour has been corrected. Other DVB adapters may
trigger the same issue if they also poll constatly for the rc.

Regards,
Pedro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/