Re: USB driver issue

Re: USB driver issue

[Felipe Balbi]

Hi,

On Wed, Jul 30, 2008 at 2:59 PM, SUBHRANIL CHOUDHURY <subhra85-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi all,
> I am trying to validate the USB driver on OMAP3430 with the
> 2.6.22.18kernel. I am facing problems in the process while trying to
> do a USB
> transfer with DMA enabled.
> The apllication is breaking in a function called consistent_sync. The error
> message is like "Unable to handle kernel Null pointer".
>
> The issue is same with both OHCI and EHCI controller. And the issue is not
> coming if i disable DMA.
>
> Has anyone tried USB packet transfer with DMA enabled? Please let me know.

Why are you using such an old, support-less kernel ?

Try with current 2.6.26 out of git repository. I've been using musb
driver on omap3
for months now and it's working quite ok besides a few bugs hidden
here and there
(which I'm looking at).

ps: this list has moved to linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org and musb driver
is now being
discussed in linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org mailing list, so please, care
to Cc both lists
mentioned here.

-- 
Best Regards,

Felipe Balbi
felipebalbi-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB driver issue

[Emanoil Kotsev]

Dear Felipe, I just want to tell, that while still developing kernels in the 2.6.2X series a kernel 2.6.22 can not be labeled as old. Besides it comes along with few distros as default kernel.

A lot of people like me need some kind of a stable version that we can relay on for more than playing at home, which is the case with 2.4.X tree. 

Personally, experiments with 2.6.24 brought me into a big trouble and it took many hours to migrate back to 2.6.20, so please keep in mind that if we say something like this, there is a good reason to do so.

Appreciate your understanding.


--- On Wed, 7/30/08, Felipe Balbi <felipebalbi-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> wrote:

> From: Felipe Balbi <felipebalbi-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
> Subject: Re: USB driver issue
> To: "SUBHRANIL CHOUDHURY" <subhra85-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: linux-omap-open-source-P3Mejjx7fphMeHKdZgrLhA@public.gmane.org, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Date: Wednesday, July 30, 2008, 2:05 PM
> Hi,
> 
> On Wed, Jul 30, 2008 at 2:59 PM, SUBHRANIL CHOUDHURY
> <subhra85-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > Hi all,
> > I am trying to validate the USB driver on OMAP3430
> with the
> > 2.6.22.18kernel. I am facing problems in the process
> while trying to
> > do a USB
> > transfer with DMA enabled.
> > The apllication is breaking in a function called
> consistent_sync. The error
> > message is like "Unable to handle kernel Null
> pointer".
> >
> > The issue is same with both OHCI and EHCI controller.
> And the issue is not
> > coming if i disable DMA.
> >
> > Has anyone tried USB packet transfer with DMA enabled?
> Please let me know.
> 
> Why are you using such an old, support-less kernel ?
> 
> Try with current 2.6.26 out of git repository. I've
> been using musb
> driver on omap3
> for months now and it's working quite ok besides a few
> bugs hidden
> here and there
> (which I'm looking at).
> 
> ps: this list has moved to linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org and
> musb driver
> is now being
> discussed in linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org mailing list, so
> please, care
> to Cc both lists
> mentioned here.
> 
> -- 
> Best Regards,
> 
> Felipe Balbi
> felipebalbi-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> --
> To unsubscribe from this list: send the line
> "unsubscribe linux-usb" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html


      
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB driver issue

[Daniel Stone]

[-- Attachment #1: Type: text/plain, Size: 810 bytes --]

On Wed, Jul 30, 2008 at 07:21:53AM -0700, ext Emanoil Kotsev wrote:
> Dear Felipe, I just want to tell, that while still developing kernels in the 2.6.2X series a kernel 2.6.22 can not be labeled as old.

Actually, it can, as it was released quite a long time ago.

> Besides it comes along with few distros as default kernel.

Yes, and these distros have to heavily patch it.

> A lot of people like me need some kind of a stable version that we can relay on for more than playing at home, which is the case with 2.4.X tree. 
> 
> Personally, experiments with 2.6.24 brought me into a big trouble and it took many hours to migrate back to 2.6.20, so please keep in mind that if we say something like this, there is a good reason to do so.

I'd strongly suggest trying 2.6.26.

Cheers,
Daniel

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: USB driver issue

[Felipe Balbi]

On Wed, Jul 30, 2008 at 07:21:53AM -0700, ext Emanoil Kotsev wrote:
> 
> Dear Felipe, I just want to tell, that while still developing kernels in the 2.6.2X series a kernel 2.6.22 can not be labeled as old. Besides it comes along with few distros as default kernel.
> 
> A lot of people like me need some kind of a stable version that we can relay on for more than playing at home, which is the case with 2.4.X tree. 
> 
> Personally, experiments with 2.6.24 brought me into a big trouble and it took many hours to migrate back to 2.6.20, so please keep in mind that if we say something like this, there is a good reason to do so.

You can always choose any kernel version you want but if you choose such
an old version (2.6.22 was released in Jul 8th, 2007), please don't rely
in community support and instead, backport all changes in the particular
driver you're working with to 2.6.22.

It's always your choice.

-- 
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: USB driver issue

[Gadiyar, Anand]

> On Wed, Jul 30, 2008 at 07:21:53AM -0700, ext Emanoil Kotsev wrote:
> >
> > Dear Felipe, I just want to tell, that while still developing kernels in the 2.6.2X
> series a kernel 2.6.22 can not be labeled as old. Besides it comes along with few
> distros as default kernel.
> >
> > A lot of people like me need some kind of a stable version that we can relay on
> > for more than playing at home, which is the case with 2.4.X tree.
> >
> > Personally, experiments with 2.6.24 brought me into a big trouble and it took
> > many hours to migrate back to 2.6.20, so please keep in mind that if we say
> > something like this, there is a good reason to do so.
>
> You can always choose any kernel version you want but if you choose such
> an old version (2.6.22 was released in Jul 8th, 2007), please don't rely
> in community support and instead, backport all changes in the particular
> driver you're working with to 2.6.22.
>
> It's always your choice.

That's plain wrong. 2.6.22 was released in July 2007. But 2.6.22.18 was not.
That came much later - in February this year. And people still do use 2.6.22
kernels. Besides, the MUSB code hasn't really changed that much in this time.

Do you really think the problem will go away in 2.6.26? People can't always use the
latest kernel, you know. Embedded kernels don't get enough testing. There's always
a chance this is a new driver. And even if it weren't, the very act of debugging
a problem like this is a good learning experience.

Grr. Saying one needs to upgrade to the latest kernel before one can expect
support is a bit like certain proprietary OS vendors - and even they do a better
job than this.

Regards,
Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: USB driver issue

[Gadiyar, Anand]

>> On Wed, Jul 30, 2008 at 07:21:53AM -0700, ext Emanoil Kotsev wrote:
>> >
>> > Dear Felipe, I just want to tell, that while still developing kernels in the 2.6.2X
>> series a kernel 2.6.22 can not be labeled as old. Besides it comes along with few
>> distros as default kernel.
>> >
>> > A lot of people like me need some kind of a stable version that we can relay on
>>> > for more than playing at home, which is the case with 2.4.X tree.
>> >
>> > Personally, experiments with 2.6.24 brought me into a big trouble and it took
>> > many hours to migrate back to 2.6.20, so please keep in mind that if we say
>> > something like this, there is a good reason to do so.
>>
>> You can always choose any kernel version you want but if you choose such
>> an old version (2.6.22 was released in Jul 8th, 2007), please don't rely
>> in community support and instead, backport all changes in the particular
>> driver you're working with to 2.6.22.
>>
>> It's always your choice.
>
> That's plain wrong. 2.6.22 was released in July 2007. But 2.6.22.18 was not.
> That came much later - in February this year. And people still do use 2.6.22
> kernels. Besides, the MUSB code hasn't really changed that much in this time.
>
> Do you really think the problem will go away in 2.6.26? People can't always use the
> latest kernel, you know. Embedded kernels don't get enough testing. There's always
> a chance this is a new driver. And even if it weren't, the very act of debugging
> a problem like this is a good learning experience.

I meant new bug.

>
> Grr. Saying one needs to upgrade to the latest kernel before one can expect
> support is a bit like certain proprietary OS vendors - and even they do a better
> job than this.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: USB driver issue

[Igor Stoppa]

On Wed, 2008-07-30 at 21:56 +0530, ext Gadiyar, Anand wrote:

> > Grr. Saying one needs to upgrade to the latest kernel before one can expect
> > support is a bit like certain proprietary OS vendors - and even they do a better
> > job than this.

The difference is that an OS vendor usually sells also support.

Even if it was confirmed that the bug exists in a "stable" version, the
reporter would be asked anyway to verify that it is present in the
latest code.

Of course for TI the business is different, since TI does provide also
support to customers, but that doesn't imply that others have to follow
that model.

-- 

Cheers, Igor

---

Igor Stoppa
Maemo Software - Nokia Devices R&D - Helsinki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: USB driver issue

[Gadiyar, Anand]

> On Wed, 2008-07-30 at 21:56 +0530, ext Gadiyar, Anand wrote:
>
> > > Grr. Saying one needs to upgrade to the latest kernel before one can expect
> > > support is a bit like certain proprietary OS vendors - and even they do a better
> > > job than this.
>
> The difference is that an OS vendor usually sells also support.
>
> Even if it was confirmed that the bug exists in a "stable" version, the
> reporter would be asked anyway to verify that it is present in the
> latest code.

Yes. Except that the poor old OP would have a hard time getting the latest
kernel to run on his hardware... :) (Actually, he shouldn't have much of a problem.
So your point is taken).

It would be nice if everyone were to migrate to the latest code, but does that
really take away the fun of solving a problem? I agree we shouldn't try to fix something
that, in all likelyhood, has already been fixed. But is it really so much of an effort for us
to trace a problem without making the OP figure out how to get a totally new kernel
running? Are we really this lazy?


> Of course for TI the business is different, since TI does provide also
> support to customers, but that doesn't imply that others have to follow
> that model.

Oh well! Just because one has a corporate email account... :)

I guess it's time I started using a non-corporate account for work done in my spare time.

Re: USB driver issue

[Felipe Balbi]

On Wed, Jul 30, 2008 at 11:02:27PM +0530, Gadiyar, Anand wrote:
> It would be nice if everyone were to migrate to the latest code, but does that
> really take away the fun of solving a problem? I agree we shouldn't try to fix something
> that, in all likelyhood, has already been fixed. But is it really so much of an effort for us
> to trace a problem without making the OP figure out how to get a totally new kernel
> running? Are we really this lazy?

I wouldn't say lazy. At least I have several other stuff internally to
deal with and if this is an already fixed bug, I really wouldn't like to
spend time fixing it again.

Maybe this discussion is already too big and we're not trying to solve
the problem anyways.

So here are a few questions:

1. Can linux-omap boot up omap3 osk ?
2. Can omapzoom kernel boot up omap3 osk ?
3. Can you try to see if the bug appears in both of those kernels ?
4. Can you send more detailed debugging messages ?
5. Can you describe a way to reproduce the bug ?

Please, keep my nokia mail in the loop so I can take a look at it after
we get more information :-)

-- 
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB driver issue

[Felipe Balbi]

On Wed, Jul 30, 2008 at 09:56:48PM +0530, Gadiyar, Anand wrote:
> > That's plain wrong. 2.6.22 was released in July 2007. But 2.6.22.18 was not.
> > That came much later - in February this year. And people still do use 2.6.22
> > kernels. Besides, the MUSB code hasn't really changed that much in this time.
> >
> > Do you really think the problem will go away in 2.6.26? People can't always use the
> > latest kernel, you know. Embedded kernels don't get enough testing. There's always
> > a chance this is a new driver. And even if it weren't, the very act of debugging
> > a problem like this is a good learning experience.
> 
> I meant new bug.
> 
> >
> > Grr. Saying one needs to upgrade to the latest kernel before one can expect
> > support is a bit like certain proprietary OS vendors - and even they do a better
> > job than this.

It can also be a fixed bug and there's no reason to try to fix it
"again". The time frame from 2.6.22-omap1 (linux-omap tag) until now
contains the most active development on musb driver. Several hw
workarounds were found, omap3 support was added, several cleanups were
done and a lot more.

It's a +16k lines diff. I'd rather try it in a recent kernel just to be
sure the bug still in, if it's not we try to find where is the fix and
backport it to 2.6.22 kernel.

For me it sounds mych saner going this way.

I really don't see how this relates to proprietary OS vendors support.
I'm pretty sure kernel from omapzoom would have support for his 3430 osk
board, wouldn't it?

Besides, wouldn't that board work with board-omap3evm.c code just by
tweaking the machine type ?

I really believe it'd be something good to try, either recent linux-omap
or omapzoom git tree. I believe still 2.6.24 right ?

-- 
balbi

Re: USB driver issue

[Daniel Stone]

[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]

On Wed, Jul 30, 2008 at 09:53:43PM +0530, ext Gadiyar, Anand wrote:
> Grr. Saying one needs to upgrade to the latest kernel before one can expect
> support is a bit like certain proprietary OS vendors - and even they do a better
> job than this.

If you want to support people running 2.6.22, good for you.  You seem to
be happy with a codebase that doesn't change as much, so I'm sure you'll
have fun supporting it.

I'm getting the feeling that we need a new Godwin's law: as a thread
involving a complaint about open source grows longer, the probability of
a comparison involving Microsoft approaches one.

So yes, some people don't want to support old code on their own time.
So what? Who are you to tell them that they can't do this? What was the
point of the Microsoft comparison, except to reinforce stereotypes that
free software developers are a bunch of freaks with unhealthy obsessions
on Microsoft and LOL BILL GATES IS THE SUCK?

(Bearing in mind that one of the main tenets of open source development
 is 'release early and release often', you could say that having
 everyone use very old code until you one day drop a huge chunk of
 rewritten new code on them is also OMG MICROSOFT.  But that'd be
 equally stupid.)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

RE: USB driver issue

[Gadiyar, Anand]

> On Wed, Jul 30, 2008 at 09:53:43PM +0530, ext Gadiyar, Anand wrote:
> > Grr. Saying one needs to upgrade to the latest kernel before one can expect
> > support is a bit like certain proprietary OS vendors - and even they do a better
> > job than this.
>
> If you want to support people running 2.6.22, good for you.  You seem to
> be happy with a codebase that doesn't change as much, so I'm sure you'll
> have fun supporting it.

Second sentence isn't true. The third probably is. I do enjoy finding why something
doesn't work. Maybe you should give it a shot sometime.


> I'm getting the feeling that we need a new Godwin's law: as a thread
> involving a complaint about open source grows longer, the probability of
> a comparison involving Microsoft approaches one.

Okay. That comparison wasn't warranted, I guess. But here's what went through
my mind when I read Felipe's post. "If you want this to work, then upgrade". And
that looked exactly like MS telling me "I can't help you with XP anymore, move on
to Vista mate".

Why on earth do we have the stable trees then? Why do people put in their time
porting fixes back to the 2.6.22.* 'stable' trees? There are still people out there
that use them, for whatever reason. And they do run into bugs that still haven't been
caught.


> So yes, some people don't want to support old code on their own time.
> So what? Who are you to tell them that they can't do this? What was the

I don't particularly care if people don't want to support old code. What I do
care about is the attitude that's out here - "Hey! Move up in life man! Get the
latest, greatest, RC kernel! 2.6.24 is ancient, 2.6.26 is ancient!". Yes, I do use
2.6.27-rc1 prepatch. But I do recognize that there are people out there who don't.

Yes people should ideally work off the latest. But that shouldn't mean one won't
get help if one is not using the latest. Or am I totally wrong here?


> point of the Microsoft comparison, except to reinforce stereotypes that
> free software developers are a bunch of freaks with unhealthy obsessions
> on Microsoft and LOL BILL GATES IS THE SUCK?

The Microsoft comparison was totally out of place. Please accept my apologies
for bringing it up.

>
> (Bearing in mind that one of the main tenets of open source development
 > is 'release early and release often', you could say that having
 > everyone use very old code until you one day drop a huge chunk of
 > rewritten new code on them is also OMG MICROSOFT.  But that'd be
>  equally stupid.)

Re: USB driver issue

[Felipe Balbi]

On Wed, Jul 30, 2008 at 10:55:03PM +0530, Gadiyar, Anand wrote:
> Okay. That comparison wasn't warranted, I guess. But here's what went through
> my mind when I read Felipe's post. "If you want this to work, then upgrade". And
> that looked exactly like MS telling me "I can't help you with XP anymore, move on
> to Vista mate".

eheh, did I really say that ? I hope not. :-p

What I meant is that it's possible that recent code has that particular
bug fixed.

> Why on earth do we have the stable trees then? Why do people put in their time
> porting fixes back to the 2.6.22.* 'stable' trees? There are still people out there
> that use them, for whatever reason. And they do run into bugs that still haven't been
> caught.

But then again, if the problem _is_ solved in current tree then it's
easier to just backport then trying to solve it again.

If it _does_ exist in current code, then we fix both in a shot.

> I don't particularly care if people don't want to support old code. What I do
> care about is the attitude that's out here - "Hey! Move up in life man! Get the
> latest, greatest, RC kernel! 2.6.24 is ancient, 2.6.26 is ancient!". Yes, I do use
> 2.6.27-rc1 prepatch. But I do recognize that there are people out there who don't.

We do recognize as well. We're still releasing maemo sw with 2.6.21
kernel.

> Yes people should ideally work off the latest. But that shouldn't mean one won't
> get help if one is not using the latest. Or am I totally wrong here?

Again, if there is more recent code to try out, I really don't see why
not trying out that more recent code to see if the same bug shows up.

It'll make things easier to track down. We should know if we were able
to fix it since 2.6.22 until today, then we just track the changes in
that particular function and it's a lot easier to backport the fix,
don't you think ?

-- 
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB driver issue

[Emanoil Kotsev]

hello, again

I think what we are trying to say is that some of us are working on debugging kernels that are meant to run "forever"  and therefor it is a good thing to spent some time thinking about a kind of kernel release in the 2.6 series that can be considered as stable.

Besides what you say is correct but you can not provide argument for a stable software in the terms of what you are writing. because if you have a look at the changes done to the kernel code you'll admit that these are not a bug fixes but real changes that should lead the kernel to a new version (may be even not minor)

I don't argue I just agree with Anand that this is even worse than commercial software company practice.

I would agree with you if new minor versions does not impact working stuff, but this is NOT the case, ,so you are somehow WRONG!

sorry for that

regards


--- On Wed, 7/30/08, Daniel Stone <daniel.stone@nokia.com> wrote:

> From: Daniel Stone <daniel.stone@nokia.com>
> Subject: Re: USB driver issue
> To: "ext Gadiyar, Anand" <gadiyar@ti.com>
> Cc: "felipe.balbi@nokia.com" <felipe.balbi@nokia.com>, "ext Emanoil Kotsev" <deloptes@yahoo.com>, "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>, "linux-omap-open-source@linux.omap.com" <linux-omap-open-source@linux.omap.com>, "SUBHRANIL CHOUDHURY" <subhra85@gmail.com>, "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
> Date: Wednesday, July 30, 2008, 6:44 PM
> On Wed, Jul 30, 2008 at 09:53:43PM +0530, ext Gadiyar, Anand
> wrote:
> > Grr. Saying one needs to upgrade to the latest kernel
> before one can expect
> > support is a bit like certain proprietary OS vendors -
> and even they do a better
> > job than this.
> 
> If you want to support people running 2.6.22, good for you.
>  You seem to
> be happy with a codebase that doesn't change as much,
> so I'm sure you'll
> have fun supporting it.
> 
> I'm getting the feeling that we need a new Godwin's
> law: as a thread
> involving a complaint about open source grows longer, the
> probability of
> a comparison involving Microsoft approaches one.
> 
> So yes, some people don't want to support old code on
> their own time.
> So what? Who are you to tell them that they can't do
> this? What was the
> point of the Microsoft comparison, except to reinforce
> stereotypes that
> free software developers are a bunch of freaks with
> unhealthy obsessions
> on Microsoft and LOL BILL GATES IS THE SUCK?
> 
> (Bearing in mind that one of the main tenets of open source
> development
>  is 'release early and release often', you could
> say that having
>  everyone use very old code until you one day drop a huge
> chunk of
>  rewritten new code on them is also OMG MICROSOFT.  But
> that'd be
>  equally stupid.)


      

Re: USB driver issue

[Greg KH]

On Thu, Jul 31, 2008 at 08:43:40AM -0700, Emanoil Kotsev wrote:
> 
> hello, again
> 
> I think what we are trying to say is that some of us are working on
> debugging kernels that are meant to run "forever"  and therefor it is
> a good thing to spent some time thinking about a kind of kernel
> release in the 2.6 series that can be considered as stable.

I don't think you really understand exactly how fast, and how rapid
Linux kernel development is.  Here's a short video that tries to explain
a bit of this:
	http://www.youtube.com/watch?v=L2SED6sewRw

At this rapid rate of development, for anyone to call anything "stable"
is laughable, just look at the raw numbers :)

And if you wish to stop and slow down the kernel developers from doing
this, well, are you able to tell someone else to stop doing something?
I'm sure not, and no one else is either.

Look at the numbers posted in that talk and then think about how to
manage such a MAJOR development stream that we are producing here.

It's different than _anything_ you have ever encountered before, and
because of that, needs to be treated differently.

> Besides what you say is correct but you can not provide argument for a
> stable software in the terms of what you are writing. because if you
> have a look at the changes done to the kernel code you'll admit that
> these are not a bug fixes but real changes that should lead the kernel
> to a new version (may be even not minor)

Numbers are just a marketing thing.  We produce 10,000 changes to the
kernel every 3 months.  Is that not somthing "major"?  If not, what is?

thanks,

greg k-h

Re: USB driver issue

[Riku Voipio]

On Wed, Jul 30, 2008 at 09:53:43PM +0530, Gadiyar, Anand wrote:
> Besides, the MUSB code hasn't really changed that much in this time.

Even if that was true (which, according to Felippe's answer isn't),
the USB subsystem itself has changed quite a bit since.

> Do you really think the problem will go away in 2.6.26? People can't always use the
> latest kernel, you know. Embedded kernels don't get enough testing.

Certainly the best way to fix that is to ask embedded people to test
newer kernels then?

If for no other reason, to find out _why_ people can't use newer
kernels - If it's some valid brokenness is mainline kernels, those
bugs need to be found and fixed, rather than having developers sulking
with their old kernels...

> Grr. Saying one needs to upgrade to the latest kernel before one can expect
> support is a bit like certain proprietary OS vendors - and even they do a better
> job than this.

There is fine line between "you must use latest kernel" and "please do
me a favour and test with this latest version that already might have
the fix".

Vendors and Distributions provide stable baseline Linux kernels - but
then you should get support from the vendor rather than from community
in general. Now this mailing list is probable the right contact place
for TI provided kernels so this point is a bit moot ;)

-- 
"rm -rf" only sounds scary if you don't have backups

Re: USB driver issue

[Greg KH]

On Thu, Jul 31, 2008 at 08:30:26AM -0700, Emanoil Kotsev wrote:
> I think everything is getting pretty messy recently - I was pretty
> satisfied with 2.6.20 and then tried 2.6.24. In fact I can not compile
> 2.6.20 right now because after an upgrade debian testing comes with
> gcc-4.3 that has a background struggle about who's wrong between gcc
> people and Linus Torvalds and the issue is still open.

That's an issue between you and Debian, just downgrade your version of
gcc if you don't like this.  Or use a distro that allows multiple
versions of gcc to be installed at the same time (I trivially switch
between 4 versions of gcc on my box.)

Either way, it's not a kernel issue, how could you blame 2.6.20 for gcc
4.3 issues when gcc 4.3 was not even released when .20 was released?
Are us kernel people time travellers?

> So what I'm pleading for is to focus on stability!

What exactly do you propose for such a "focus"?  How do you see this
happening?

> And yes I'm planing to try 2.6.26, but I'm pretty sure that there
> would be issues with drivers like uvcview, the proprietary ATI and
> NVidia and apps like skype

Closed source drivers have issues, film at 11.  Bah, take it up with
them, there is NOTHING that us developers can do about that, sorry.

Applications are a different story, they should "just work" with
different kernel versions, there should not be any problems there.  If
there are, let the kernel developers know, we take backwards userspace
compatiblity VERY seriously.

thanks,

greg k-h

Re: USB driver issue

[Emanoil Kotsev]

Thanks for having your attention.

--- On Thu, 7/31/08, Greg KH <greg@kroah.com> wrote:

> From: Greg KH <greg@kroah.com>
> Subject: Re: USB driver issue
> To: "Emanoil Kotsev" <deloptes@yahoo.com>
> Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>, "linux-omap-open-source@linux.omap.com" <linux-omap-open-source@linux.omap.com>, "SUBHRANIL CHOUDHURY" <subhra85@gmail.com>, "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
> Date: Thursday, July 31, 2008, 6:36 PM
> On Thu, Jul 31, 2008 at 08:30:26AM -0700, Emanoil Kotsev
> wrote:
> > I think everything is getting pretty messy recently -
> I was pretty
> > satisfied with 2.6.20 and then tried 2.6.24. In fact I
> can not compile
> > 2.6.20 right now because after an upgrade debian
> testing comes with
> > gcc-4.3 that has a background struggle about who's
> wrong between gcc
> > people and Linus Torvalds and the issue is still open.
> 
> That's an issue between you and Debian, just downgrade
> your version of
> gcc if you don't like this.  Or use a distro that
> allows multiple
> versions of gcc to be installed at the same time (I
> trivially switch
> between 4 versions of gcc on my box.)

You are right, and it was ment as an example of inconvenience what happens in developers world and the user (me) is suffering after all.
I personally have other solution for the issue. Using debian testing for a while was just a test.

> 
> Either way, it's not a kernel issue, how could you
> blame 2.6.20 for gcc
> 4.3 issues when gcc 4.3 was not even released when .20 was
> released?
> Are us kernel people time travellers?

:-) good point. Everytime I switch to a new kernel I have to download a bunch of different versions of drivers and software and compile them, install them and test them and end up with a bunch of new bugs. I don't have the time recently to play this nasty game and I'm getting tired
Why should I do this? I just want to fix problems in current kernel that I'm using.
I would agree with you if new versions do not come with new bugs, but they do, thus my suggestion.

> 
> > So what I'm pleading for is to focus on stability!
> 
> What exactly do you propose for such a "focus"? 
> How do you see this
> happening?

Kernel developers should fix bugs in minor kernel versions as they are meant for this purpous and do major changes only in major version. A bunch of bugfixes I see (not only usb related) are just not in place in minor kernel versions. That's my opinion at first place.

Second if you want to have me as happy linux user developers should agree to support older versions to help embeded and other developers working further on their projects.
And I'm writing this because (also in other forums) people tend to have such a neglecting mentality ignoring the needs of others. Just to remember the reason for this discussion was the statement that 2.6.22 was too old, which as Anand pointed out was in it's latest release was issued in the beginning of the year. This is really "windows like"  mentality and as Anand says at least they support the versions they issue - sorry for this - but I think it's kind of truth.

> 
> > And yes I'm planing to try 2.6.26, but I'm
> pretty sure that there
> > would be issues with drivers like uvcview, the
> proprietary ATI and
> > NVidia and apps like skype
> 
> Closed source drivers have issues, film at 11.  Bah, take
> it up with
> them, there is NOTHING that us developers can do about
> that, sorry.

You are neglecting the point and kind of insulting me! So you think I should spent my time convincing about 20 people from different companies to recompile their software because I was told by you to upgrade to fix a usb issue or a kind that is not related to their software and when they finally do it there is a already a new kernel version ... sorry I can not agree with any of you on this point. You want me to spent my time contacting people and not working on my projects ;-)

Why just not be able to patch my old kernel without breaking the ability to use the software I already have installed and is working with the version I use?

I think this is the question no body wants to answer and I think there is a problem with you guys. What are you doing this development if some people are not happy with it and have reasonable arguments.

May be the patches should be split into smaller files related to bugs - just an idea!
You experience a bug and patch - the bug is gone you are happy.
May be there should be some longer period to support at least the latest stable releases ... but something should be done.
I know the Linus policy conserning 2.6. tree has changed for the reason to let us improve faster, but since 1-2 years I have the feeling 1) that it is getting too fast and 2) that I'm not the only one saying this

> 
> Applications are a different story, they should "just
> work" with
> different kernel versions, there should not be any problems
> there.  If
> there are, let the kernel developers know, we take
> backwards userspace
> compatiblity VERY seriously.

gcc-4.3 ;-) is it application or what do you mean ... the compiler is not an application ;-)

thanks for helping me to catch up with the developers opinion. I'm honest about this really

kind regards

> 
> thanks,
> 
> greg k-h
> --
> To unsubscribe from this list: send the line
> "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html


      

Re: USB driver issue

[Felipe Balbi]

Hi,

I hope we end this thread some day...

On Thu, Jul 31, 2008 at 01:38:59PM -0700, Emanoil Kotsev wrote:
> Kernel developers should fix bugs in minor kernel versions as they are meant for this purpous and do major changes only in major version. A bunch of bugfixes I see (not only usb related) are just not in place in minor kernel versions. That's my opinion at first place.
> 
> Second if you want to have me as happy linux user developers should agree to support older versions to help embeded and other developers working further on their projects.
> And I'm writing this because (also in other forums) people tend to have such a neglecting mentality ignoring the needs of others. Just to remember the reason for this discussion was the statement that 2.6.22 was too old, which as Anand pointed out was in it's latest release was issued in the beginning of the year. This is really "windows like"  mentality and as Anand says at least they support the versions they issue - sorry for this - but I think it's kind of truth.
> 

2.6.22 was in Jul 2007, he pointed out a minor stable version out of
2.6.22.

> > > And yes I'm planing to try 2.6.26, but I'm
> > pretty sure that there
> > > would be issues with drivers like uvcview, the
> > proprietary ATI and
> > > NVidia and apps like skype
> > 
> > Closed source drivers have issues, film at 11.  Bah, take
> > it up with
> > them, there is NOTHING that us developers can do about
> > that, sorry.
> 
> You are neglecting the point and kind of insulting me! So you think I should spent my time convincing about 20 people from different companies to recompile their software because I was told by you to upgrade to fix a usb issue or a kind that is not related to their software and when they finally do it there is a already a new kernel version ... sorry I can not agree with any of you on this point. You want me to spent my time contacting people and not working on my projects ;-)

You are really missing the whole point of the discussion.

The driver in question is musb, which is not closed source at all.
Closed source drivers is a different issue and Linux kernel is said that
won't provide a stable API. It's always changing.

Really, musb driver _has_ changed since 2.6.22 and that special 2.6.22
version was coming from a vendor we cannot support vendor kernel. We
support linux mainline git tree, that's all.

I just asked why using that version, I didn't ask nobody to upgrade. But
really, all the changes made from 2.6.22 until now would make any musb
patch from 2.6.22 to be unaplicable to recent musb code, besides,
*again* it might be that the particular bug could have been fixed in all
those set of changes in musb driver from 2.6.22 until now, so why
spending time trying to fix again something that might have been fixed ?
We could only backport that particular bug fix to 2.6.22.

> Why just not be able to patch my old kernel without breaking the ability to use the software I already have installed and is working with the version I use?

You can do it, but you cannot expect that your patch get accepted, it
might even not apply and that was my point.

> I think this is the question no body wants to answer and I think there is a problem with you guys. What are you doing this development if some people are not happy with it and have reasonable arguments.

Talk for yourself, don't "broadcast" it.

> May be the patches should be split into smaller files related to bugs - just an idea!
> You experience a bug and patch - the bug is gone you are happy.
> May be there should be some longer period to support at least the latest stable releases ... but something should be done.

If the api has changed you cannot expect that. Specialy if you're using
vendor-specific kernel, it doesn't matter if it's nokia, redhat, ubuntu,
TI, etc.

> > Applications are a different story, they should "just
> > work" with
> > different kernel versions, there should not be any problems
> > there.  If
> > there are, let the kernel developers know, we take
> > backwards userspace
> > compatiblity VERY seriously.
> 
> gcc-4.3 ;-) is it application or what do you mean ... the compiler is not an application ;-)

And it works it doesn't matter the kernel is running below it. If it can
generate good binaries or not it's a different story. Has nothing to do
with kernel, it's a gcc-related issue, don't you think ?

Anyways, this thread is already way too big.

-- 
balbi

Re: USB driver issue

[Stalin Kenny]

Felipe,

Sorry to say but to say that one has to migrate to latest kernel in
order to get community support is not right....the statement does has
a touch of arrogance. You are not the spokeperson for the community.


On Thu, Jul 31, 2008 at 4:02 PM, Felipe Balbi <me-uiRdBs8odbtmTBlB0Cgj/Q@public.gmane.org> wrote:
> Hi,
>
> I hope we end this thread some day...
>
> On Thu, Jul 31, 2008 at 01:38:59PM -0700, Emanoil Kotsev wrote:
>> Kernel developers should fix bugs in minor kernel versions as they are meant for this purpous and do major changes only in major version. A bunch of bugfixes I see (not only usb related) are just not in place in minor kernel versions. That's my opinion at first place.
>>
>> Second if you want to have me as happy linux user developers should agree to support older versions to help embeded and other developers working further on their projects.
>> And I'm writing this because (also in other forums) people tend to have such a neglecting mentality ignoring the needs of others. Just to remember the reason for this discussion was the statement that 2.6.22 was too old, which as Anand pointed out was in it's latest release was issued in the beginning of the year. This is really "windows like"  mentality and as Anand says at least they support the versions they issue - sorry for this - but I think it's kind of truth.
>>
>
> 2.6.22 was in Jul 2007, he pointed out a minor stable version out of
> 2.6.22.
>
>> > > And yes I'm planing to try 2.6.26, but I'm
>> > pretty sure that there
>> > > would be issues with drivers like uvcview, the
>> > proprietary ATI and
>> > > NVidia and apps like skype
>> >
>> > Closed source drivers have issues, film at 11.  Bah, take
>> > it up with
>> > them, there is NOTHING that us developers can do about
>> > that, sorry.
>>
>> You are neglecting the point and kind of insulting me! So you think I should spent my time convincing about 20 people from different companies to recompile their software because I was told by you to upgrade to fix a usb issue or a kind that is not related to their software and when they finally do it there is a already a new kernel version ... sorry I can not agree with any of you on this point. You want me to spent my time contacting people and not working on my projects ;-)
>
> You are really missing the whole point of the discussion.
>
> The driver in question is musb, which is not closed source at all.
> Closed source drivers is a different issue and Linux kernel is said that
> won't provide a stable API. It's always changing.
>
> Really, musb driver _has_ changed since 2.6.22 and that special 2.6.22
> version was coming from a vendor we cannot support vendor kernel. We
> support linux mainline git tree, that's all.
>
> I just asked why using that version, I didn't ask nobody to upgrade. But
> really, all the changes made from 2.6.22 until now would make any musb
> patch from 2.6.22 to be unaplicable to recent musb code, besides,
> *again* it might be that the particular bug could have been fixed in all
> those set of changes in musb driver from 2.6.22 until now, so why
> spending time trying to fix again something that might have been fixed ?
> We could only backport that particular bug fix to 2.6.22.
>
>> Why just not be able to patch my old kernel without breaking the ability to use the software I already have installed and is working with the version I use?
>
> You can do it, but you cannot expect that your patch get accepted, it
> might even not apply and that was my point.
>
>> I think this is the question no body wants to answer and I think there is a problem with you guys. What are you doing this development if some people are not happy with it and have reasonable arguments.
>
> Talk for yourself, don't "broadcast" it.
>
>> May be the patches should be split into smaller files related to bugs - just an idea!
>> You experience a bug and patch - the bug is gone you are happy.
>> May be there should be some longer period to support at least the latest stable releases ... but something should be done.
>
> If the api has changed you cannot expect that. Specialy if you're using
> vendor-specific kernel, it doesn't matter if it's nokia, redhat, ubuntu,
> TI, etc.
>
>> > Applications are a different story, they should "just
>> > work" with
>> > different kernel versions, there should not be any problems
>> > there.  If
>> > there are, let the kernel developers know, we take
>> > backwards userspace
>> > compatiblity VERY seriously.
>>
>> gcc-4.3 ;-) is it application or what do you mean ... the compiler is not an application ;-)
>
> And it works it doesn't matter the kernel is running below it. If it can
> generate good binaries or not it's a different story. Has nothing to do
> with kernel, it's a gcc-related issue, don't you think ?
>
> Anyways, this thread is already way too big.
>
> --
> balbi
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB driver issue

[Greg KH]

On Thu, Jul 31, 2008 at 07:47:07PM -0500, Stalin Kenny wrote:
> Felipe,
> 
> Sorry to say but to say that one has to migrate to latest kernel in
> order to get community support is not right....the statement does has
> a touch of arrogance. You are not the spokeperson for the community.

Um, yes he is.

And so is everyone else who actually contributes to the kernel.

If Felipe says he doesn't want to support anything but the latest
kernel.org kernel for free, then that is what he is going to do.  Why do
you not believe him?

Personally, that is my stance as well.  And it's the stance of _every_
other kernel developer who I know who contributes their time and effort
here.

There are _lots_ of companies out there willing and able to support
older kernel versions for you.  If you want support for something like
this, it is simple to find.  But that is not something that we can
provide in our community, otherwise we would go insane.

thanks,

greg k-h

Re: USB driver issue

[Alan Stern]

On Thu, 31 Jul 2008, Greg KH wrote:

> On Thu, Jul 31, 2008 at 07:47:07PM -0500, Stalin Kenny wrote:
> > Felipe,
> > 
> > Sorry to say but to say that one has to migrate to latest kernel in
> > order to get community support is not right....the statement does has
> > a touch of arrogance. You are not the spokeperson for the community.
> 
> Um, yes he is.
> 
> And so is everyone else who actually contributes to the kernel.
> 
> If Felipe says he doesn't want to support anything but the latest
> kernel.org kernel for free, then that is what he is going to do.  Why do
> you not believe him?
> 
> Personally, that is my stance as well.  And it's the stance of _every_
> other kernel developer who I know who contributes their time and effort
> here.

That last sentence is slightly overstated.  I am certainly willing to 
help debug problems on kernels that aren't the most recent 
bleeding edge, provided they aren't _so_ old as to be completely 
irrelevant.  It's not uncommon to find that the bug in question is 
still present in today's kernel.

Of course, if I recognize the bug as one that has already been fixed
then there's no point in doing any more testing or debugging.

Alan Stern

Re: USB driver issue

[Stalin Kenny]

On Fri, Aug 1, 2008 at 1:15 AM, Greg KH <greg@kroah.com> wrote:
> On Thu, Jul 31, 2008 at 07:47:07PM -0500, Stalin Kenny wrote:
>> Felipe,
>>
>> Sorry to say but to say that one has to migrate to latest kernel in
>> order to get community support is not right....the statement does has
>> a touch of arrogance. You are not the spokeperson for the community.
>
> Um, yes he is.
>
> And so is everyone else who actually contributes to the kernel.
>
> If Felipe says he doesn't want to support anything but the latest
> kernel.org kernel for free, then that is what he is going to do.  Why do
> you not believe him?
>
> Personally, that is my stance as well.  And it's the stance of _every_
> other kernel developer who I know who contributes their time and effort
> here.
>
> There are _lots_ of companies out there willing and able to support
> older kernel versions for you.  If you want support for something like
> this, it is simple to find.  But that is not something that we can
> provide in our community, otherwise we would go insane.
>
> thanks,
>
> greg k-h
>

Your statements fit well if you are speaking on behalf of a "Company"
and not for "open source community".

There is a difference between "suggesting" and "commanding". What you
or some one are doing here is commanding to use the latest kernel in
order to provide support, and that doesn't bode well with me. Just
because you can work with the latest kernel (that probably has bugs),
you cannot make assumptions that every one has the same bandwidth to
migrate to the latest kernel and keep moving with you.

Again, the problem is not about updating to the latest kernel or not,
the problem is with the few individuals attitude and I sincerely hope
they change it.

regards,
Stalin

Re: USB driver issue

[Koen Kooi]

[-- Attachment #1: Type: text/plain, Size: 506 bytes --]


Op 2 aug 2008, om 17:42 heeft Stalin Kenny het volgende geschreven:
>
> Again, the problem is not about updating to the latest kernel or not,
> the problem is with the few individuals attitude and I sincerely hope
> they change it.

No, the problem is with people wanting free support and getting what  
they payed for. If you demand support for an old kernel, prepare to  
get confronted with rate-cards.

If you want free support then do as the supporters tell you. Again,  
you get what you payed for.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: USB driver issue

[Felipe Balbi]

On Sat, Aug 02, 2008 at 04:45:19PM -0700, Emanoil Kotsev wrote:
> I don't mind testing for you for free, but I need for few reasons something relaible. If you can not make it to offer such a kernel version then admit it and stop writing things that are insulting to hear.

Did you really had a big break with linux since 2.6.20 ??

> I'm using linux because I like the open source philosophy and I contribute to it for free, also because I like it so. If you are trying to earn money or to force me to pay for a support (like Novel/SuSE suggests) then forget it. We all contribute to this philosophy for free and that's why you have so much to do.

And we're gonna still doing it for free. Whenever I leave work, my
company is not paying me anymore. Even the work I have for publishing
stuff, my company is not paying me for. The hours I spent listening and
helping out, the way I can, the community my company is not paying me
for.

> What we would like to see is something between "latest" and "such old" kernel that has fewer bugs, so I may not go to bed and think about if my data is there tomorrow or not. And with the changes you make and go forward without (I repeat) without excessive testing. You can not guarantee this!

And once again you're mistaken. Just to be sure, I've been testing musb
driver (the original bug report was to musb) for over 20 hours and got
no problems so far. And, believe me, there people crazier than me about
stress testing ;-)

> I just wanted to share an experience or impression I have since 2.6.20 and this impression is getting worse the way you think and put forward things.

As Greg said, this model has been working quite well so far and it
doesn't seem we're gonna change it.

> I just wanted to give you an advanced user opinion and to find out what could be done.
> Well, so far nothing and the only solution for me is to stick to my tested 2.4.26 kernel and wait that better times come and something changes in the  kernel development community. Neither 2.6.20 nor 2.6.24 are running wihtout a problem and believe me I'm not testing 2.6.26 FOR FREE on my server where I've stored my data. 

Why don't you file bugs then? The thing is that we really can't stop
moving forward to check something over 1 year old. We have so many
changes from version to version that it's impossible to go 4 versions
back on time and check what's wrong there.

If you have any coding skills, you can provide support for older
versions of the kernel if you feel like, but like Greg said, it's hell a
of work to do.

The 2.6.xx release cycle has been quite stable so far. One thing we do
care is not to break something that was working before - don't reply with
closed source drivers arguments, please; there's nothing we can do about
them - sometimes we have a regression and something gets messed, sorry.
We also commit mistakes. But generaly, things are going quite good. The
fix for that regression will most likely be applied to one of the
-stable team releases.

If you really DO need a stable older version kernel, you can stick with
the pre-compiled images coming from your distro. They are supported and
somewhat frozen. Once in a while you'll get an update for that
particular version.

Saying that neither 2.6.20 nor 2.6.24 are running without a problem is
both vague and true. True because every sw has problems, so has linux
kernel. Vague because you're not telling us where are the problems ?!?

I'm using 2.6.27-rc1 and it has been quite a long time (and I've been
using 2.6 series since 2.6.0) that I don't have big issues with it.
Suspend-to-ram and suspend-to-disk are working just fine, acpi is quite
good (thanks to Arjan and the other people in linux-acpi), usb is also
really good (we have an uncountable number of working drivers), wifi is
working, bluetooth is working, anyways, I really don't have problems
with linux.

ps: only while I was writing this mail I pulled 185 new changes from
linux-2.6.git, not counting merges.

-- 
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB driver issue

[Emanoil Kotsev]

Thank you Stalin!

I gave up the discussion because it leads to nothing. Greg says I'm missing the point but I think they miss my (our) point.

I also think they don't use linux on server or embeded equipment and don't have the responsibility to ralay on something stable, so they do not understand my (our) point.

Anyway I've installed the 2.6.26 kernel and now few things are not working of course wit hthis version, so where is the point of this installation I DO NOT understand. I have to go back to 2.6.24 anyway.

Of course few other things are working better, so somehow all of us are right.

My point is that it would be VERY nice if kernel developers DO SUPPORT one version for longer time and provide bug fixes. May be it could be done in a separate tree, but it would help people working with exotic hardware to propagade linux.

I think we as comunity should support each other, as the most people here do. The problem was with the neglecting statement that something is old afer beeing few months old, so I was thinking may be Felipe and Greg are buying a new house because they don't like the sink in their present one ;-)

I would stop the discussion if it is about who's right and who's wrong - it leads to nothing.
What I want to say is that recently a new kernel installation leads to many hours of senseeless work as in the end you find out that different hard/software developers are not supporting the "latest" version andwhen they finally do it is not the latest and people like Gred say that they won't support it ... well it's your free will to do whatever you like, but it is not cooperative and helpful.

besides how do I activate digest of the USB mailing list, thanks!

cheers

--- On Fri, 8/1/08, Stalin Kenny <stalinlinux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> From: Stalin Kenny <stalinlinux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Subject: Re: USB driver issue
> To: me-uiRdBs8odbtmTBlB0Cgj/Q@public.gmane.org
> Cc: "Emanoil Kotsev" <deloptes-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>, "linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "linux-omap-open-source-P3Mejjx7fphMeHKdZgrLhA@public.gmane.org" <linux-omap-open-source-P3Mejjx7fphMeHKdZgrLhA@public.gmane.org>, "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Date: Friday, August 1, 2008, 2:47 AM
> Felipe,
> 
> Sorry to say but to say that one has to migrate to latest
> kernel in
> order to get community support is not right....the
> statement does has
> a touch of arrogance. You are not the spokeperson for the
> community.
> 
> 
> On Thu, Jul 31, 2008 at 4:02 PM, Felipe Balbi
> <me-uiRdBs8odbtmTBlB0Cgj/Q@public.gmane.org> wrote:
> > Hi,
> >
> > I hope we end this thread some day...
> >
> > On Thu, Jul 31, 2008 at 01:38:59PM -0700, Emanoil
> Kotsev wrote:
> >> Kernel developers should fix bugs in minor kernel
> versions as they are meant for this purpous and do major
> changes only in major version. A bunch of bugfixes I see
> (not only usb related) are just not in place in minor kernel
> versions. That's my opinion at first place.
> >>
> >> Second if you want to have me as happy linux user
> developers should agree to support older versions to help
> embeded and other developers working further on their
> projects.
> >> And I'm writing this because (also in other
> forums) people tend to have such a neglecting mentality
> ignoring the needs of others. Just to remember the reason
> for this discussion was the statement that 2.6.22 was too
> old, which as Anand pointed out was in it's latest
> release was issued in the beginning of the year. This is
> really "windows like"  mentality and as Anand says
> at least they support the versions they issue - sorry for
> this - but I think it's kind of truth.
> >>
> >
> > 2.6.22 was in Jul 2007, he pointed out a minor stable
> version out of
> > 2.6.22.
> >
> >> > > And yes I'm planing to try 2.6.26,
> but I'm
> >> > pretty sure that there
> >> > > would be issues with drivers like
> uvcview, the
> >> > proprietary ATI and
> >> > > NVidia and apps like skype
> >> >
> >> > Closed source drivers have issues, film at
> 11.  Bah, take
> >> > it up with
> >> > them, there is NOTHING that us developers can
> do about
> >> > that, sorry.
> >>
> >> You are neglecting the point and kind of insulting
> me! So you think I should spent my time convincing about 20
> people from different companies to recompile their software
> because I was told by you to upgrade to fix a usb issue or a
> kind that is not related to their software and when they
> finally do it there is a already a new kernel version ...
> sorry I can not agree with any of you on this point. You
> want me to spent my time contacting people and not working
> on my projects ;-)
> >
> > You are really missing the whole point of the
> discussion.
> >
> > The driver in question is musb, which is not closed
> source at all.
> > Closed source drivers is a different issue and Linux
> kernel is said that
> > won't provide a stable API. It's always
> changing.
> >
> > Really, musb driver _has_ changed since 2.6.22 and
> that special 2.6.22
> > version was coming from a vendor we cannot support
> vendor kernel. We
> > support linux mainline git tree, that's all.
> >
> > I just asked why using that version, I didn't ask
> nobody to upgrade. But
> > really, all the changes made from 2.6.22 until now
> would make any musb
> > patch from 2.6.22 to be unaplicable to recent musb
> code, besides,
> > *again* it might be that the particular bug could have
> been fixed in all
> > those set of changes in musb driver from 2.6.22 until
> now, so why
> > spending time trying to fix again something that might
> have been fixed ?
> > We could only backport that particular bug fix to
> 2.6.22.
> >
> >> Why just not be able to patch my old kernel
> without breaking the ability to use the software I already
> have installed and is working with the version I use?
> >
> > You can do it, but you cannot expect that your patch
> get accepted, it
> > might even not apply and that was my point.
> >
> >> I think this is the question no body wants to
> answer and I think there is a problem with you guys. What
> are you doing this development if some people are not happy
> with it and have reasonable arguments.
> >
> > Talk for yourself, don't "broadcast" it.
> >
> >> May be the patches should be split into smaller
> files related to bugs - just an idea!
> >> You experience a bug and patch - the bug is gone
> you are happy.
> >> May be there should be some longer period to
> support at least the latest stable releases ... but
> something should be done.
> >
> > If the api has changed you cannot expect that.
> Specialy if you're using
> > vendor-specific kernel, it doesn't matter if
> it's nokia, redhat, ubuntu,
> > TI, etc.
> >
> >> > Applications are a different story, they
> should "just
> >> > work" with
> >> > different kernel versions, there should not
> be any problems
> >> > there.  If
> >> > there are, let the kernel developers know, we
> take
> >> > backwards userspace
> >> > compatiblity VERY seriously.
> >>
> >> gcc-4.3 ;-) is it application or what do you mean
> ... the compiler is not an application ;-)
> >
> > And it works it doesn't matter the kernel is
> running below it. If it can
> > generate good binaries or not it's a different
> story. Has nothing to do
> > with kernel, it's a gcc-related issue, don't
> you think ?
> >
> > Anyways, this thread is already way too big.
> >
> > --
> > balbi
> > --
> > To unsubscribe from this list: send the line
> "unsubscribe linux-omap" in
> > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> >


      
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB driver issue

[Felipe Balbi]

Hi,

On Sat, Aug 02, 2008 at 12:47:44AM -0700, Emanoil Kotsev wrote:
> I gave up the discussion because it leads to nothing. Greg says I'm missing the point but I think they miss my (our) point.
> 
> I also think they don't use linux on server or embeded equipment and don't have the responsibility to ralay on something stable, so they do not understand my (our) point.

Stop speculating, I'm one developing kernel for maemo devices and I use
recent kernel on my devices, for developing/debugging/testing purposes.
Most of our development is done together with linux-omap community.

> Anyway I've installed the 2.6.26 kernel and now few things are not working of course wit hthis version, so where is the point of this installation I DO NOT understand. I have to go back to 2.6.24 anyway.

And now you report the bugs you found in 2.6.26...

> Of course few other things are working better, so somehow all of us are right.
> 
> My point is that it would be VERY nice if kernel developers DO SUPPORT one version for longer time and provide bug fixes. May be it could be done in a separate tree, but it would help people working with exotic hardware to propagade linux.

And that's called stable tree:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.24.y.git;a=summary
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.25.y.git;a=summary
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.26.y.git;a=summary

> I think we as comunity should support each other, as the most people here do. The problem was with the neglecting statement that something is old afer beeing few months old, so I was thinking may be Felipe and Greg are buying a new house because they don't like the sink in their present one ;-)

This analogy was really bad and you know that, I suppose.

Did you see greg's talk about the kernel development process ? Really,
do it.

-- 
balbi

Re: USB driver issue

[Emanoil Kotsev]

Felipe, thank you for answering. I now see what's the problem with you

> Stop speculating, I'm one developing kernel for maemo
> devices and I use
> recent kernel on my devices, for
> developing/debugging/testing purposes.
> Most of our development is done together with linux-omap
> community.

I don't see anywhere the word "production" in your list, and that's my point. I want something that works and if there is a bug to be able to fix it and make it more stable. 
You debug, test and develop but you DON'T ralay on it. I am willing to have the oposite. NOT developeing, testing and debuging, but just using it - can you understand that?
I want to use a kernel for PRODUCTION purposes, not for playing with it as you obviously do. I don't have time to start over debugging different issues that I did not have with the previous release, especially when it comes to my personal data that's stored out there.

Even commercial companies support flavour of their OS's for years, so why shouldn't the linux community don't do it. It would bring benefit to all of us. Please refer to the discussion with Greg. I thinkg it makes more sense

regards



      
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB driver issue

[Felipe Balbi]

On Sat, Aug 02, 2008 at 02:02:27AM -0700, Emanoil Kotsev wrote:
> Felipe, thank you for answering. I now see what's the problem with you

you should really rephrase this.

> I don't see anywhere the word "production" in your list, and that's my point. I want something that works and if there is a bug to be able to fix it and make it more stable. 

And that will come from the commercial company you said below.
Hopefully that commercial company will also notify the community so that
bug won't happen again in recent kernel versions.

That's exactly what we do when we release a new version of our Maemo SW,
it's not only a theme change, we're fixing bugs all around the thing.

> You debug, test and develop but you DON'T ralay on it. I am willing to have the oposite. NOT developeing, testing and debuging, but just using it - can you understand that?

And this is something you still don't get. I DO relay on it. Of course
we freeze internal development as soon as we release the pieces to
linux-omap, because it doesn't make any sense for us to keep backporting
so many pieces, although I remember backporting some patches to 2.6.18
back in n800 time.

> I want to use a kernel for PRODUCTION purposes, not for playing with it as you obviously do. I don't have time to start over debugging different issues that I did not have with the previous release, especially when it comes to my personal data that's stored out there.

you're wrong here. By the time we release our kernel, we also publish
everything to linux-omap tree. You can get any version of linux-omap and
boot your n8xx up to maemo desktop. That's even not a big deal.
Unfortunately we have a few closed source pieces which we are still
trying to open, believe me, it's not as easy as publishing.

> Even commercial companies support flavour of their OS's for years, so why shouldn't the linux community don't do it. It would bring benefit to all of us. Please refer to the discussion with Greg. I thinkg it makes more sense

But then you can get the support from those commercial companies,
can't you ?

If there is someone else already supporting older versions of the kernel
why should we stop ? The thing is, I just want to be sure the bug
someone is reporting still happens in current code, otherwise I won't
bother looking. If it's fixed, I just don't have enough time to
backport, anyone else can do it for you, or even you if you have the
time/expertise to do so.

-- 
balbi

Re: USB driver issue

[Emanoil Kotsev]

I'll stop this discussion. If you feel you are right, then this should be true and I don't mind it.

The problem was with you calling 2.6.22 a "such old", but I give up this discussion too. You have the right to think it is and I have the right to do not. After I have your point of view I have to live with that, hope the same for you.

It would be anyway nice if you do not make such (2.6.22 - "such old") statments, but if you wish you could and I don't mind either. 

I think I'll spend my time filing bugs instead of arguing with you, as it leads to nothing obviously.

Unfortunately I still don't have a solution - until bugs from 3rd party vednors are solved you label the kernel as old ... but may be in future it will change.

regars

--- On Sat, 8/2/08, Felipe Balbi <me@felipebalbi.com> wrote:

> From: Felipe Balbi <me@felipebalbi.com>
> Subject: Re: USB driver issue
> To: "Emanoil Kotsev" <deloptes@yahoo.com>
> Cc: me@felipebalbi.com, "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>, "linux-omap-open-source@linux.omap.com" <linux-omap-open-source@linux.omap.com>, "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
> Date: Saturday, August 2, 2008, 11:17 AM
> On Sat, Aug 02, 2008 at 02:02:27AM -0700, Emanoil Kotsev
> wrote:
> > Felipe, thank you for answering. I now see what's
> the problem with you
> 
> you should really rephrase this.
> 
> > I don't see anywhere the word
> "production" in your list, and that's my
> point. I want something that works and if there is a bug to
> be able to fix it and make it more stable. 
> 
> And that will come from the commercial company you said
> below.
> Hopefully that commercial company will also notify the
> community so that
> bug won't happen again in recent kernel versions.
> 
> That's exactly what we do when we release a new version
> of our Maemo SW,
> it's not only a theme change, we're fixing bugs all
> around the thing.
> 
> > You debug, test and develop but you DON'T ralay on
> it. I am willing to have the oposite. NOT developeing,
> testing and debuging, but just using it - can you understand
> that?
> 
> And this is something you still don't get. I DO relay
> on it. Of course
> we freeze internal development as soon as we release the
> pieces to
> linux-omap, because it doesn't make any sense for us to
> keep backporting
> so many pieces, although I remember backporting some
> patches to 2.6.18
> back in n800 time.
> 
> > I want to use a kernel for PRODUCTION purposes, not
> for playing with it as you obviously do. I don't have
> time to start over debugging different issues that I did not
> have with the previous release, especially when it comes to
> my personal data that's stored out there.
> 
> you're wrong here. By the time we release our kernel,
> we also publish
> everything to linux-omap tree. You can get any version of
> linux-omap and
> boot your n8xx up to maemo desktop. That's even not a
> big deal.
> Unfortunately we have a few closed source pieces which we
> are still
> trying to open, believe me, it's not as easy as
> publishing.
> 
> > Even commercial companies support flavour of their
> OS's for years, so why shouldn't the linux community
> don't do it. It would bring benefit to all of us. Please
> refer to the discussion with Greg. I thinkg it makes more
> sense
> 
> But then you can get the support from those commercial
> companies,
> can't you ?
> 
> If there is someone else already supporting older versions
> of the kernel
> why should we stop ? The thing is, I just want to be sure
> the bug
> someone is reporting still happens in current code,
> otherwise I won't
> bother looking. If it's fixed, I just don't have
> enough time to
> backport, anyone else can do it for you, or even you if you
> have the
> time/expertise to do so.
> 
> -- 
> balbi


      

Re: USB driver issue

[Koen Kooi]

[-- Attachment #1: Type: text/plain, Size: 4260 bytes --]


Op 2 aug 2008, om 11:53 heeft Emanoil Kotsev het volgende geschreven:

> I'll stop this discussion. If you feel you are right, then this  
> should be true and I don't mind it.
>
> The problem was with you calling 2.6.22 a "such old", but I give up  
> this discussion too. You have the right to think it is and I have  
> the right to do not. After I have your point of view I have to live  
> with that, hope the same for you.
>
> It would be anyway nice if you do not make such (2.6.22 - "such  
> old") statments, but if you wish you could and I don't mind either.
>
> I think I'll spend my time filing bugs instead of arguing with you,  
> as it leads to nothing obviously.
>
> Unfortunately I still don't have a solution - until bugs from 3rd  
> party vednors are solved you label the kernel as old ... but may be  
> in future it will change.


2.6.22 will only get older in the future

>
>
> regars
>
> --- On Sat, 8/2/08, Felipe Balbi <me@felipebalbi.com> wrote:
>
>> From: Felipe Balbi <me@felipebalbi.com>
>> Subject: Re: USB driver issue
>> To: "Emanoil Kotsev" <deloptes@yahoo.com>
>> Cc: me@felipebalbi.com, "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org 
>> >, "linux-omap-open-source@linux.omap.com" <linux-omap-open-source@linux.omap.com 
>> >, "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
>> Date: Saturday, August 2, 2008, 11:17 AM
>> On Sat, Aug 02, 2008 at 02:02:27AM -0700, Emanoil Kotsev
>> wrote:
>>> Felipe, thank you for answering. I now see what's
>> the problem with you
>>
>> you should really rephrase this.
>>
>>> I don't see anywhere the word
>> "production" in your list, and that's my
>> point. I want something that works and if there is a bug to
>> be able to fix it and make it more stable.
>>
>> And that will come from the commercial company you said
>> below.
>> Hopefully that commercial company will also notify the
>> community so that
>> bug won't happen again in recent kernel versions.
>>
>> That's exactly what we do when we release a new version
>> of our Maemo SW,
>> it's not only a theme change, we're fixing bugs all
>> around the thing.
>>
>>> You debug, test and develop but you DON'T ralay on
>> it. I am willing to have the oposite. NOT developeing,
>> testing and debuging, but just using it - can you understand
>> that?
>>
>> And this is something you still don't get. I DO relay
>> on it. Of course
>> we freeze internal development as soon as we release the
>> pieces to
>> linux-omap, because it doesn't make any sense for us to
>> keep backporting
>> so many pieces, although I remember backporting some
>> patches to 2.6.18
>> back in n800 time.
>>
>>> I want to use a kernel for PRODUCTION purposes, not
>> for playing with it as you obviously do. I don't have
>> time to start over debugging different issues that I did not
>> have with the previous release, especially when it comes to
>> my personal data that's stored out there.
>>
>> you're wrong here. By the time we release our kernel,
>> we also publish
>> everything to linux-omap tree. You can get any version of
>> linux-omap and
>> boot your n8xx up to maemo desktop. That's even not a
>> big deal.
>> Unfortunately we have a few closed source pieces which we
>> are still
>> trying to open, believe me, it's not as easy as
>> publishing.
>>
>>> Even commercial companies support flavour of their
>> OS's for years, so why shouldn't the linux community
>> don't do it. It would bring benefit to all of us. Please
>> refer to the discussion with Greg. I thinkg it makes more
>> sense
>>
>> But then you can get the support from those commercial
>> companies,
>> can't you ?
>>
>> If there is someone else already supporting older versions
>> of the kernel
>> why should we stop ? The thing is, I just want to be sure
>> the bug
>> someone is reporting still happens in current code,
>> otherwise I won't
>> bother looking. If it's fixed, I just don't have
>> enough time to
>> backport, anyone else can do it for you, or even you if you
>> have the
>> time/expertise to do so.
>>
>> -- 
>> balbi
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux- 
> omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: USB driver issue

[Igor Stoppa]

On Sat, 2008-08-02 at 02:53 -0700, ext Emanoil Kotsev wrote:

> I think I'll spend my time filing bugs instead of arguing with you, as it leads to nothing obviously.
> 
> Unfortunately I still don't have a solution - until bugs from 3rd party vednors are solved you label the kernel as old ... but may be in future it will change.

If you want a viable solution that avoids you headaches with kernel
version, put your efforts with your 3rd party vendor so that the driver
gets properly integrated into mainline.

Or just change the vendor if you can.

-- 

Cheers, Igor

---

Igor Stoppa
Maemo Software - Nokia Devices R&D - Helsinki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB driver issue

[Greg KH]

On Sat, Aug 02, 2008 at 02:53:08AM -0700, Emanoil Kotsev wrote:
> I'll stop this discussion. If you feel you are right, then this should
> be true and I don't mind it.
> 
> The problem was with you calling 2.6.22 a "such old", but I give up
> this discussion too. You have the right to think it is and I have the
> right to do not. After I have your point of view I have to live with
> that, hope the same for you.

2.6.22 is "old".  It was released a full year ago.

Since then, 38682 changes have been made to the Linux kernel source
tree.

That's a _lot_ of changes.  So as you can see, lots of things have
changed in the past year, making it _very_ difficult for the community
to support such an old kernel release.

> It would be anyway nice if you do not make such (2.6.22 - "such old")
> statments, but if you wish you could and I don't mind either. 

Based on the rapid development of the Linux kernel, I'm confused as to
how you could consider 2.6.22 a "new" kernel?

> I think I'll spend my time filing bugs instead of arguing with you, as
> it leads to nothing obviously.

Please do, we will be glad to fix them as well as we can.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB driver issue

[Emanoil Kotsev]

Greg, the discussion is getting out of control.

I think you are one of the few that understand what we are talking about (may be not compleetly but at least you are not confronting with statements that make me angry) and it seems that you are trying to find a compromise. So I'll write only this one mail and get out of this discussion.

First I do not consider 2.6.22 new, but it would be nice to have longer life cycles.
The problem is that we talk to different 3rd party vendors who re willing to help but can not follow this speed and the changes you do.
At the other hand the kernel needs more testing to step to next level of development.
If you can not do it I would understand it, but this way I'm afraid to install 2.6 kernel on a server, where data storing is done. I did it with 2.6.24 had some oops on the usb (ehci) and end up with restoring raid over 10hours, that's how I came to the usb list.

These two aspekts (issues) are my consern about what you label as old and I just wanted to find out if something could be done to help everybody. I'm working as consultant and could promote linux, but I won't do it for post 2.6.20 kernel versions.
It's just not confident. I could offer a SuSE, RedHat or a kind  of support, what I'm also doing, but this is a different issue.
It is also for me as user and working person with a private life almost not possible to follow the development and to test and check everything. I have equivalent machine and periferal equipment where I could test, but it is very time consuming so I'm looking for solution how we can mutually benefit and not loose confidence in each other.
May be there should be a server and desktop branch (it is an idea) but this situation and also with such confrontation from the developers is very very sad.
At least I'm not writing it to argue with you but to have a meaningful discussion where we could reach some kind of agreement at the end.

If you wish to you could mail me on my mail address, I don't want to continiue the discussion here any more and bother the list participants

thank you for (may be) understanding the point

regards

--- On Sat, 8/2/08, Greg KH <greg@kroah.com> wrote:

> From: Greg KH <greg@kroah.com>
> Subject: Re: USB driver issue
> To: "Emanoil Kotsev" <deloptes@yahoo.com>
> Cc: me@felipebalbi.com, "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>, "linux-omap-open-source@linux.omap.com" <linux-omap-open-source@linux.omap.com>, "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
> Date: Saturday, August 2, 2008, 8:27 PM
> On Sat, Aug 02, 2008 at 02:53:08AM -0700, Emanoil Kotsev
> wrote:
> > I'll stop this discussion. If you feel you are
> right, then this should
> > be true and I don't mind it.
> > 
> > The problem was with you calling 2.6.22 a "such
> old", but I give up
> > this discussion too. You have the right to think it is
> and I have the
> > right to do not. After I have your point of view I
> have to live with
> > that, hope the same for you.
> 
> 2.6.22 is "old".  It was released a full year
> ago.
> 
> Since then, 38682 changes have been made to the Linux
> kernel source
> tree.
> 
> That's a _lot_ of changes.  So as you can see, lots of
> things have
> changed in the past year, making it _very_ difficult for
> the community
> to support such an old kernel release.
> 
> > It would be anyway nice if you do not make such
> (2.6.22 - "such old")
> > statments, but if you wish you could and I don't
> mind either. 
> 
> Based on the rapid development of the Linux kernel, I'm
> confused as to
> how you could consider 2.6.22 a "new" kernel?
> 
> > I think I'll spend my time filing bugs instead of
> arguing with you, as
> > it leads to nothing obviously.
> 
> Please do, we will be glad to fix them as well as we can.
> 
> thanks,
> 
> greg k-h
> --
> To unsubscribe from this list: send the line
> "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html


      

Re: USB driver issue

[Greg KH]

On Sat, Aug 02, 2008 at 05:11:51PM -0700, Emanoil Kotsev wrote:
> Greg, the discussion is getting out of control.

Hm, looks normal to me :)

> I think you are one of the few that understand what we are talking
> about (may be not compleetly but at least you are not confronting with
> statements that make me angry) and it seems that you are trying to
> find a compromise. So I'll write only this one mail and get out of
> this discussion.
> 
> First I do not consider 2.6.22 new, but it would be nice to have
> longer life cycles.

Why?  What good would that do?  How would we, as a community, support
such a thing?  Do you really understand how the kernel development
process works and how fast it moves?

> The problem is that we talk to different 3rd party vendors who re
> willing to help but can not follow this speed and the changes you do.

No, there is no "problem" here.  The 3rd party vendors are EXPLICITLY
not wanting to work within our development process for a variety of
reasons.  Again, there is _NOTHING_ that we can do about this.

They are the ones who do not want to work with us, or abide by our
license.  They are the leaches on our community and investment and cause
us nothing but pain and problems.  We have offered to do their work for
them, for free, for the rest of time, and they do not take us up on it.
What else can we do except ignore them as they really do not want to do
ANYTHING to help change the current situation?

> At the other hand the kernel needs more testing to step to next level
> of development.

"next level"?  What do you mean by this?  What would this level entail?

Is Linux somehow not working properly for the world?  It's in over 80%
of the TOP500 supercomputers and in all of Motorola's new phones,
a flexibility never before achieved by any type of operating system in
the history of computing.

And why do you not think we have a lot of testing?  There is a TON of
testing that happens for new releases.  Sure, we can always use more,
and welcome you to help out if possible.

Take a moment to try to understand how we do development here.  After
that, please try to describe exactly what you feel we are doing wrong,
and how we could change to make you feel better, in detail, given our
constraints.

thanks,

greg k-h

Re: USB driver issue

[Emanoil Kotsev]

Ok, so I've installed 2.6.26 and tested most of the hardware I use. Except hfs everything seems to be working better than with 2.6.24 and much better then 2.6.20 as expected.

I'll give it a try with my server, as you say you do a lot of testing ... and after the hole discussion, I'm understanding your point of better now.

My basic problem is that I'am testing a kind of solution I had in mind time ago, but it still fails for some reason even with the patched 2.4.24 version. I gave it up and didn't test 2.6.25 because I was pretty buzy recently. Now I see it's hard to catch up.

My problem is the follwing one and the question is if it will disapear after I install 2.6.26, or is it a hardware issue. I think somehow the drive does not behave as the others drives I use over usb. I'm using mostly seagate, but this one is WD:

hub 7-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100
hub 7-0:1.0: state 7 ports 2 chg 0000 evt 0000
usb usb4: suspend_rh (auto-stop)
usb usb5: suspend_rh (auto-stop)
usb usb6: suspend_rh (auto-stop)
usb usb7: suspend_rh (auto-stop)
ub(2.3): dir r len/act 4096/0 [sense 0 00 00] retry 1
ehci_hcd 0000:00:0e.2: port 3 high speed
ehci_hcd 0000:00:0e.2: GetStatus port 3 status 001005 POWER sig=se0 PE CONNECT
usb 2-3: reset high speed USB device using ehci_hcd and address 3
usb 2-3: events/0 timed out on ep0in len=0/64
usb 2-3: events/0 timed out on ep0in len=0/64
hub 2-0:1.0: state 7 ports 4 chg 0000 evt 0008
ehci_hcd 0000:00:0e.2: devpath 3 ep0in 3strikes
ehci_hcd 0000:00:0e.2: devpath 3 ep0in 3strikes
ehci_hcd 0000:00:0e.2: GetStatus port 3 status 001002 POWER sig=se0 CSC
hub 2-0:1.0: logical disconnect on port 3
ub(2.3): usb_lock_device_for_reset failed (-19)
hub 2-0:1.0: state 7 ports 4 chg 0008 evt 0008
ehci_hcd 0000:00:0e.2: GetStatus port 3 status 001803 POWER sig=j CSC CONNECT
hub 2-0:1.0: port 3, status 0501, change 0001, 480 Mb/s
usb 2-3: USB disconnect, address 3
end_request: I/O error, dev ubd, sector 0
Buffer I/O error on device ubd, logical block 0
end_request: I/O error, dev ubd, sector 0
Buffer I/O error on device ubd, logical block 0
...
...
...
...
Buffer I/O error on device ubd, logical block 0
ldm_validate_partition_table(): Disk read failed.
end_request: I/O error, dev ubd, sector 0
Buffer I/O error on device ubd, logical block 0
end_request: I/O error, dev ubd, sector 0
end_request: I/O error, dev ubd, sector 0
end_request: I/O error, dev ubd, sector 0
Dev ubd: unable to read RDB block 0
end_request: I/O error, dev ubd, sector 0
end_request: I/O error, dev ubd, sector 0
end_request: I/O error, dev ubd, sector 24
end_request: I/O error, dev ubd, sector 24
end_request: I/O error, dev ubd, sector 0
end_request: I/O error, dev ubd, sector 0
 unable to read partition table
usb 2-3: unregistering device
usb 2-3: usb_disable_device nuking all URBs
usb 2-3: unregistering interface 2-3:1.0
usb 2-3:1.0: uevent
usb 2-3: uevent
hub 2-0:1.0: debounce: port 3: total 100ms stable 100ms status 0x501
ehci_hcd 0000:00:0e.2: port 3 high speed
ehci_hcd 0000:00:0e.2: GetStatus port 3 status 001005 POWER sig=se0 PE CONNECT
usb 2-3: new high speed USB device using ehci_hcd and address 4
ehci_hcd 0000:00:0e.2: port 3 high speed
ehci_hcd 0000:00:0e.2: GetStatus port 3 status 001005 POWER sig=se0 PE CONNECT
usb 2-3: default language 0x0409
usb 2-3: uevent
usb 2-3: usb_probe_device
usb 2-3: configuration #1 chosen from 1 choice
usb 2-3: adding 2-3:1.0 (config #1, interface 0)
usb 2-3:1.0: uevent
drivers/usb/core/inode.c: creating file '004'
usb 2-3: new device strings: Mfr=2, Product=3, SerialNumber=1
usb 2-3: Product: USB to Serial-ATA bridge
usb 2-3: Manufacturer: Sunplus Technology Inc.
usb 2-3: SerialNumber: WDC WD5000     WD-WMASY0076274
ub 2-3:1.0: usb_probe_interface
ub 2-3:1.0: usb_probe_interface - got id
 ubd: ubd1
usbcore: registered new interface driver ub
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.


--- On Sun, 8/3/08, Greg KH <greg@kroah.com> wrote:

> From: Greg KH <greg@kroah.com>
> Subject: Re: USB driver issue
> To: "Emanoil Kotsev" <deloptes@yahoo.com>
> Cc: me@felipebalbi.com, "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>, "linux-omap-open-source@linux.omap.com" <linux-omap-open-source@linux.omap.com>, "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
> Date: Sunday, August 3, 2008, 4:56 AM
> On Sat, Aug 02, 2008 at 05:11:51PM -0700, Emanoil Kotsev
> wrote:
> > Greg, the discussion is getting out of control.
> 
> Hm, looks normal to me :)

Well, "normal" is relative anyway

> 
> > I think you are one of the few that understand what we
> are talking
> > about (may be not compleetly but at least you are not
> confronting with
> > statements that make me angry) and it seems that you
> are trying to
> > find a compromise. So I'll write only this one
> mail and get out of
> > this discussion.
> > 
> > First I do not consider 2.6.22 new, but it would be
> nice to have
> > longer life cycles.
> 
> Why?  What good would that do?  How would we, as a
> community, support
> such a thing?  Do you really understand how the kernel
> development
> process works and how fast it moves?

Yes I am understanding better. I am pretty happy with it. The problem is that I have a feeling (and not only me) that it's at the cost of reliability, but I should admit that response and fixes have also improved.

The question is how could be found a relativ stable compromise between "latest" and "stable" and I think the best option is the vendors kernel, which is maintained by the OS vendor. For testing purposes and recent features (that are to be expected mostly on newer hardware like notebooks etc) the latest version could be installed and tested, because you are focused on it and I don't want to argue against.

> 
> > The problem is that we talk to different 3rd party
> vendors who re
> > willing to help but can not follow this speed and the
> changes you do.
> 
> No, there is no "problem" here.  The 3rd party
> vendors are EXPLICITLY
> not wanting to work within our development process for a
> variety of
> reasons.  Again, there is _NOTHING_ that we can do about
> this.
> 
> They are the ones who do not want to work with us, or abide
> by our
> license.  They are the leaches on our community and
> investment and cause
> us nothing but pain and problems.  We have offered to do
> their work for
> them, for free, for the rest of time, and they do not take
> us up on it.
> What else can we do except ignore them as they really do
> not want to do
> ANYTHING to help change the current situation?

some of them changed their mentality and opinion, but still the drivers are comming later as desired. Though I agree that you or me can not do anything about it. At theend it's still an issue.
Appreciate your (I mean the community) desire to help.

> 
> > At the other hand the kernel needs more testing to
> step to next level
> > of development.
> 
> "next level"?  What do you mean by this?  What
> would this level entail?

Forget it it's obsolate idea, I am coming to the conclusion that I'm writing to the wrong people. From your perspective (and for sure you have a good reason) you are doing the right thing. Somehow there was a turbulence around 2.6.20 till now, but may be it's for good. I hhhope I'll know soon.


> 
> Is Linux somehow not working properly for the world? 
> It's in over 80%
> of the TOP500 supercomputers and in all of Motorola's
> new phones,
> a flexibility never before achieved by any type of
> operating system in
> the history of computing.

thumbs up - the big make a profite but I have a headache

> 
> And why do you not think we have a lot of testing?  There
> is a TON of
> testing that happens for new releases.  Sure, we can always
> use more,
> and welcome you to help out if possible.
> 
> Take a moment to try to understand how we do development
> here.  After
> that, please try to describe exactly what you feel we are
> doing wrong,
> and how we could change to make you feel better, in detail,
> given our
> constraints.

>From my perspective I can not afford the time to follow up. It was possible until 2.6.20 got out but since then I simply can not. The boost in kernel development is really remarkable and I agree that's it's even phenomenal, but I need a relaiable kernel for a server, so "latest" version is not an option and obviously you are the wrong people to discuss with, as I agree that you have your own vision and it's possibly for a good reason.
My desire was to have the attention of the developers from let's say 1-2 versions behind. So while you consider 2.6.26 stable you may fix bugs still found in => 2.6.24, but if it is not possible then there are always different options

So I think I will be using the vendors kernel and bug them if I have an issue with it, when it comes to reliability for example conserning server etc.

The second thing is that (in my example and I don't think I am alone out there) there is misunderstanding who is supporting what and at which level.

I don't know how it could be done, if possible at all, but it's pretty confusing sometimes.
>From user perspective obiously a kernel 2.6.22 is not old and from your perspective it is. I think the best way is to explain why you think so and I and other did explain what our major problem is. So I was hoping to find a solution in the middle, and now I think this could be the OS vendor.

Thanks for the patience and thank you in advance if you can find out what's wwrong with this external drive

regards

> 
> thanks,
> 
> greg k-h


      

Re: USB driver issue

[Greg KH]

On Sat, Aug 02, 2008 at 09:08:26PM -0700, Emanoil Kotsev wrote:
> Ok, so I've installed 2.6.26 and tested most of the hardware I use.
> Except hfs everything seems to be working better than with 2.6.24 and
> much better then 2.6.20 as expected.
> 
> I'll give it a try with my server, as you say you do a lot of testing
> ... and after the hole discussion, I'm understanding your point of
> better now.
> 
> My basic problem is that I'am testing a kind of solution I had in mind
> time ago, but it still fails for some reason even with the patched
> 2.4.24 version. I gave it up and didn't test 2.6.25 because I was
> pretty buzy recently. Now I see it's hard to catch up.
> 
> My problem is the follwing one and the question is if it will disapear
> after I install 2.6.26, or is it a hardware issue. I think somehow the
> drive does not behave as the others drives I use over usb. I'm using
> mostly seagate, but this one is WD:
> 
> hub 7-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100
> hub 7-0:1.0: state 7 ports 2 chg 0000 evt 0000
> usb usb4: suspend_rh (auto-stop)
> usb usb5: suspend_rh (auto-stop)
> usb usb6: suspend_rh (auto-stop)
> usb usb7: suspend_rh (auto-stop)
> ub(2.3): dir r len/act 4096/0 [sense 0 00 00] retry 1

You are using the ub driver, any reason for that?

If you try the usb-storage driver instead, does it work better?  Worse?
Different?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB driver issue

[Emanoil Kotsev]

Thanks for fast response

lsmod
...
usb_storage            44932  0
ub                     18976  8
...

both are loaded but devices hang on ub you are right.

I think linux decided to use ub on it's own  ... how do I change this (ub is new to me  -  I am a kernel time traveler :-D  - I tought it's normal - some kind of new feature)

Is there any sense to install 2.6.26 in this case (would it help me - I know it would please you, but I'm trying to avoid work and fears)?

thanks and regards


--- On Sun, 8/3/08, Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> wrote:

> From: Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
> Subject: Re: USB driver issue
> To: "Emanoil Kotsev" <deloptes-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>
> Cc: me-uiRdBs8odbtmTBlB0Cgj/Q@public.gmane.org, "linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "linux-omap-open-source-P3Mejjx7fphMeHKdZgrLhA@public.gmane.org" <linux-omap-open-source-P3Mejjx7fphMeHKdZgrLhA@public.gmane.org>, "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Date: Sunday, August 3, 2008, 6:18 AM
> On Sat, Aug 02, 2008 at 09:08:26PM -0700, Emanoil Kotsev
> wrote:
> > Ok, so I've installed 2.6.26 and tested most of
> the hardware I use.
> > Except hfs everything seems to be working better than
> with 2.6.24 and
> > much better then 2.6.20 as expected.
> > 
> > I'll give it a try with my server, as you say you
> do a lot of testing
> > ... and after the hole discussion, I'm
> understanding your point of
> > better now.
> > 
> > My basic problem is that I'am testing a kind of
> solution I had in mind
> > time ago, but it still fails for some reason even with
> the patched
> > 2.4.24 version. I gave it up and didn't test
> 2.6.25 because I was
> > pretty buzy recently. Now I see it's hard to catch
> up.
> > 
> > My problem is the follwing one and the question is if
> it will disapear
> > after I install 2.6.26, or is it a hardware issue. I
> think somehow the
> > drive does not behave as the others drives I use over
> usb. I'm using
> > mostly seagate, but this one is WD:
> > 
> > hub 7-0:1.0: debounce: port 2: total 100ms stable
> 100ms status 0x100
> > hub 7-0:1.0: state 7 ports 2 chg 0000 evt 0000
> > usb usb4: suspend_rh (auto-stop)
> > usb usb5: suspend_rh (auto-stop)
> > usb usb6: suspend_rh (auto-stop)
> > usb usb7: suspend_rh (auto-stop)
> > ub(2.3): dir r len/act 4096/0 [sense 0 00 00] retry 1
> 
> You are using the ub driver, any reason for that?
> 
> If you try the usb-storage driver instead, does it work
> better?  Worse?
> Different?
> 
> thanks,
> 
> greg k-h
> --
> To unsubscribe from this list: send the line
> "unsubscribe linux-usb" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html


      
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB driver issue

[Greg KH]

A: No.
Q: Should I include quotations after my reply?

On Sat, Aug 02, 2008 at 09:33:19PM -0700, Emanoil Kotsev wrote:
> Thanks for fast response
> 
> lsmod
> ...
> usb_storage            44932  0
> ub                     18976  8
> ...
> 
> both are loaded but devices hang on ub you are right.
> 
> I think linux decided to use ub on it's own  ... how do I change this
> (ub is new to me  -  I am a kernel time traveler :-D  - I tought it's
> normal - some kind of new feature)

Just don't build it, or rmmod it and then plug your device back in.

> Is there any sense to install 2.6.26 in this case (would it help me -
> I know it would please you, but I'm trying to avoid work and fears)?

What kernel version is this problem happening on?

thanks,

greg k-h

Re: USB driver issue

[Emanoil Kotsev]

Hello,

thanks a lot, this solved the problem I think, because there are no such messages anymore. The answer - question I couldn't understand what you mean

The kernel version is 2.6.24.7.

I have just blacklisted the ub driver now, so it's never auto loaded.

I think it is the "Low Performance USB Block driver" is it correct?

thanks and regards again


--- On Sun, 8/3/08, Greg KH <greg@kroah.com> wrote:

> From: Greg KH <greg@kroah.com>
> Subject: Re: USB driver issue
> To: "Emanoil Kotsev" <deloptes@yahoo.com>
> Cc: me@felipebalbi.com, "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>, "linux-omap-open-source@linux.omap.com" <linux-omap-open-source@linux.omap.com>, "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
> Date: Sunday, August 3, 2008, 6:57 AM
> A: No.
> Q: Should I include quotations after my reply?
> 
> On Sat, Aug 02, 2008 at 09:33:19PM -0700, Emanoil Kotsev
> wrote:
> > Thanks for fast response
> > 
> > lsmod
> > ...
> > usb_storage            44932  0
> > ub                     18976  8
> > ...
> > 
> > both are loaded but devices hang on ub you are right.
> > 
> > I think linux decided to use ub on it's own  ...
> how do I change this
> > (ub is new to me  -  I am a kernel time traveler :-D 
> - I tought it's
> > normal - some kind of new feature)
> 
> Just don't build it, or rmmod it and then plug your
> device back in.
> 
> > Is there any sense to install 2.6.26 in this case
> (would it help me -
> > I know it would please you, but I'm trying to
> avoid work and fears)?
> 
> What kernel version is this problem happening on?
> 
> thanks,
> 
> greg k-h


      

Re: USB driver issue

[Greg KH]

On Thu, Jul 31, 2008 at 01:38:59PM -0700, Emanoil Kotsev wrote:
> > Either way, it's not a kernel issue, how could you
> > blame 2.6.20 for gcc 4.3 issues when gcc 4.3 was not even released
> > when .20 was released?  Are us kernel people time travellers?
> 
> :-) good point. Everytime I switch to a new kernel I have to download
> a bunch of different versions of drivers and software and compile
> them, install them and test them and end up with a bunch of new bugs.

Why are you needing to download new drivers?  Is not everything you need
already in the main kernel tree?  What is missing?

> I don't have the time recently to play this nasty game and I'm getting
> tired Why should I do this? I just want to fix problems in current
> kernel that I'm using.  I would agree with you if new versions do not
> come with new bugs, but they do, thus my suggestion.

All software has bugs, it's how we treat them that matters.

> > > So what I'm pleading for is to focus on stability!
> > 
> > What exactly do you propose for such a "focus"?  How do you see this
> > happening?
> 
> Kernel developers should fix bugs in minor kernel versions as they are
> meant for this purpous and do major changes only in major version. A
> bunch of bugfixes I see (not only usb related) are just not in place
> in minor kernel versions. That's my opinion at first place.

Minor (2.6.x.y) releases happen with only bugfixes every few weeks.
Perhaps you should use them.  But realize that they are only supported
for about 3-4 months, then you are expected to move to the next major
release.

That's how the community works, it is insane for us to do otherwise,
just for the overhead alone.

> Second if you want to have me as happy linux user developers should
> agree to support older versions to help embeded and other developers
> working further on their projects.

Given the rate of change in the Linux kernel (faster than any other
software project known to man), how do you really expect us to do that?
It's pretty impossible.

> > Closed source drivers have issues, film at 11.  Bah, take
> > it up with them, there is NOTHING that us developers can do about
> > that, sorry.
> 
> You are neglecting the point and kind of insulting me! So you think I
> should spent my time convincing about 20 people from different
> companies to recompile their software because I was told by you to
> upgrade to fix a usb issue or a kind that is not related to their
> software and when they finally do it there is a already a new kernel
> version ... sorry I can not agree with any of you on this point. You
> want me to spent my time contacting people and not working on my
> projects ;-)

No, we expect that you would use hardware that works with, and
contributes toward the advancement of Linux.  Not hardware that requires
closed source modules.

Again, if you are stuck with such hardware, there is _nothing_ that I or
any other kernel developer can do about it.  It is physically
impossible.

> Why just not be able to patch my old kernel without breaking the
> ability to use the software I already have installed and is working
> with the version I use?

With the exception of kernel modules, it should all "just work".  If
not, please let us know and we will fix it.

> I think this is the question no body wants to answer and I think there
> is a problem with you guys. What are you doing this development if
> some people are not happy with it and have reasonable arguments.
> 
> May be the patches should be split into smaller files related to bugs
> - just an idea!

We do that already with the -stable release.

Also, every single patch that goes into the kernel is available
separately if you so desire it.

> You experience a bug and patch - the bug is gone you are happy.
> May be there should be some longer period to support at least the
> latest stable releases ... but something should be done.

If anyone wants to step up and maintain a specific kernel release longer
than the current -stable team does so, they are more than willing to do
so.  2 people have done this in the past quite well.

But note, it is a _lot_ of real hard work.  Trust me, I've been doing it
myself for a long time now...

> I know the Linus policy conserning 2.6. tree has changed for the
> reason to let us improve faster, but since 1-2 years I have the
> feeling 1) that it is getting too fast and 2) that I'm not the only
> one saying this

If it's "getting too fast", then that's fine, some people are not
comfortable with rapid change.  Other operating systems change much
slower, perhaps one of them would work out better.

But right now, the Linux kernel is moving very rapidly.  Like it has for
the past 5 years (I have the numbers to back that up...)

Remember, we are changing for real reasons, who is to tell a devloper
that the reason for a change is not allowed just because we want to slow
down?  Does that not make their need somehow less than someone elses?

We change because the world changes.  In order to survive, we also need
to change.

If we stop, we die.

> > Applications are a different story, they should "just work" with
> > different kernel versions, there should not be any problems there.
> > If there are, let the kernel developers know, we take backwards
> > userspace compatiblity VERY seriously.
> 
> gcc-4.3 ;-) is it application or what do you mean ... the compiler is
> not an application ;-)

gcc 4.3 runs just fine on 2.6.22.  It's the fact that you want to _use_
gcc 4.3 to build 2.6.22 that is an issue.  They are two totally
different things here.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB driver issue

[Emanoil Kotsev]

Greg thank you for taking your time to discuss the issue, I think it is important, because both parties have to say something meaningful - you as developer and maintainer and me as user, tester and volunteer

--- On Fri, 8/1/08, Greg KH <greg@kroah.com> wrote:

> From: Greg KH <greg@kroah.com>
> Subject: Re: USB driver issue
> To: "Emanoil Kotsev" <deloptes@yahoo.com>
> Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>, "linux-omap-open-source@linux.omap.com" <linux-omap-open-source@linux.omap.com>, "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
> Date: Friday, August 1, 2008, 8:30 AM
> On Thu, Jul 31, 2008 at 01:38:59PM -0700, Emanoil Kotsev
> wrote:
> > > Either way, it's not a kernel issue, how
> could you
> > > blame 2.6.20 for gcc 4.3 issues when gcc 4.3 was
> not even released
> > > when .20 was released?  Are us kernel people time
> travellers?
> > 
> > :-) good point. Everytime I switch to a new kernel I
> have to download
> > a bunch of different versions of drivers and software
> and compile
> > them, install them and test them and end up with a
> bunch of new bugs.
> 
> Why are you needing to download new drivers?  Is not
> everything you need
> already in the main kernel tree?  What is missing?

I am using a dell notebook. I also support my father and wife who have also notebooks (toshiba and fujitsu).
We all have pretty a like set of hardware (from different vendors and in different versions of course) but in general it is

modem, wireless, video (intel, Nvidia, ATI), pcmcia, MMS/SD slot, firewire, irda, bluetooth.
I'm using a hybrid tv usb stick and uvc webcam.

- the modem is not working
- wireless (ipw3945) is not included in the mainstream kernel (after compile and isntall it works)
- uvcvideo driver is included in the latest kernel version and is working (thanks)
- analog/dvb tv stick is not working as I see it has been included in recent version (2.6.26) but it is looking for the wrong firmware or it is simply a code with the same name meant to support the HVR-950 instead of HVR-900 stick.
- I forgot to mention that I'm not able to sync my phones, so there is a chaos in my contacts since I gave up my Palm III and lost my Siemens S55 that was working somehow
- I also use a Geode based low power (7W) pc as a firewall with (take a deep breath) 2.6.11 (but there are now problems with this)

I also have a pentium III machine that works as a server where all our data is stored and backuped, but this is a different issue I mention it only to underline the fact that it is practically impossible to compile and test there

My father and my wife have a big trouble with the (ATI,NVidia) drivers for their video output and I have a big trouble with dual screen, 3D and intel chip

So because of all this issues and taken the fact that I am not a developer but kind a tester that reads and writes C/C++ code from time to time and also thinking in terms of the video you've send I come to the conclusion that it is getting a bit complicated to keep up with you - the developers. Hense the question if we can not agreee to have a kind of stable released where we only fix bugs - but you have already answered the question - there are planty of commercial companies that would do so.

Talking about such companies I don't see the point to use linux at all, because getting payed support for instance from SuSE brings me to the idea that I could buy an Apple PC with more benefit at the end.

Hence the question, also having the presentation about kernel development in mind, are you developing the kernel as a kind of sport ... or are you developing it so that someone can use it for something?

> 
> > I don't have the time recently to play this nasty
> game and I'm getting
> > tired Why should I do this? I just want to fix
> problems in current
> > kernel that I'm using.  I would agree with you if
> new versions do not
> > come with new bugs, but they do, thus my suggestion.
> 
> All software has bugs, it's how we treat them that
> matters.

You treat them right but not in long terms and this is making me nervous

> 
> > > > So what I'm pleading for is to focus on
> stability!
> > > 
> > > What exactly do you propose for such a
> "focus"?  How do you see this
> > > happening?
> > 
> > Kernel developers should fix bugs in minor kernel
> versions as they are
> > meant for this purpous and do major changes only in
> major version. A
> > bunch of bugfixes I see (not only usb related) are
> just not in place
> > in minor kernel versions. That's my opinion at
> first place.
> 
> Minor (2.6.x.y) releases happen with only bugfixes every
> few weeks.
> Perhaps you should use them.  But realize that they are
> only supported
> for about 3-4 months, then you are expected to move to the
> next major
> release.

This is the issue 3-4 months are enough for ATI or NVidia to bring a new driver
Either change the policy or find a solution!

> 
> That's how the community works, it is insane for us to
> do otherwise,
> just for the overhead alone.

May be I put another question: what are the plans for moving to 2.7 or 2.8 kernel then the 2.6. tree will be open only for bug fixes. The changes compared to 2.4 are extreem so if I would like to take advantage of features in 2.6 kernel I should live with bug fixes and support denial in any 2.6 version

> 
> > Second if you want to have me as happy linux user
> developers should
> > agree to support older versions to help embeded and
> other developers
> > working further on their projects.
> 
> Given the rate of change in the Linux kernel (faster than
> any other
> software project known to man), how do you really expect us
> to do that?
> It's pretty impossible.

The question is - what are you doing this for? What's your goal - I'm going to give up linux soon if it goes this way

> 
> > > Closed source drivers have issues, film at 11. 
> Bah, take
> > > it up with them, there is NOTHING that us
> developers can do about
> > > that, sorry.
> > 
> > You are neglecting the point and kind of insulting me!
> So you think I
> > should spent my time convincing about 20 people from
> different
> > companies to recompile their software because I was
> told by you to
> > upgrade to fix a usb issue or a kind that is not
> related to their
> > software and when they finally do it there is a
> already a new kernel
> > version ... sorry I can not agree with any of you on
> this point. You
> > want me to spent my time contacting people and not
> working on my
> > projects ;-)
> 
> No, we expect that you would use hardware that works with,
> and
> contributes toward the advancement of Linux.  Not hardware
> that requires
> closed source modules.

I spent a lot of time reading about hardware and linu support when IO bought my dell notebook, that's why I choose one with intel video vard inside ... and what happened - I don't have 3D when using dual screen - GREAT!

I know what's wrong with 3D but your statement (or recommendation) brings me to the idea that I could also use a type writer

> 
> Again, if you are stuck with such hardware, there is
> _nothing_ that I or
> any other kernel developer can do about it.  It is
> physically
> impossible.

The problem is, that ATI, NVidia and a lot of other hardware producers are willing to support linux, but can not afford it to bring up drivers for the latest stable kernel in the terms you consider it as stable - and this was my original point.

> 
> > Why just not be able to patch my old kernel without
> breaking the
> > ability to use the software I already have installed
> and is working
> > with the version I use?
> 
> With the exception of kernel modules, it should all
> "just work".  If
> not, please let us know and we will fix it.

Then fix the hfs modem for my dell notebook  (oh ... it is closed driver by connexant - but they are willing to help me and .... oh, they suggest I use the 2.6.24 kernel)
And also please fix the em28* driver to work with my hybrid HVR-900 properly as it does with the v4l-dvb tree in 2.6.24

Do you understand what I mean with this discussion?


> 
> > I think this is the question no body wants to answer
> and I think there
> > is a problem with you guys. What are you doing this
> development if
> > some people are not happy with it and have reasonable
> arguments.
> > 
> > May be the patches should be split into smaller files
> related to bugs
> > - just an idea!
> 
> We do that already with the -stable release.
Where are patches for 2.6.26?
> 
> Also, every single patch that goes into the kernel is
> available
> separately if you so desire it.

> 
> > You experience a bug and patch - the bug is gone you
> are happy.
> > May be there should be some longer period to support
> at least the
> > latest stable releases ... but something should be
> done.
> 
> If anyone wants to step up and maintain a specific kernel
> release longer
> than the current -stable team does so, they are more than
> willing to do
> so.  2 people have done this in the past quite well.

I want to know more about it

> 
> But note, it is a _lot_ of real hard work.  Trust me,
> I've been doing it
> myself for a long time now...

Yes this is for sure, but for few taasks it might be useful

> 
> > I know the Linus policy conserning 2.6. tree has
> changed for the
> > reason to let us improve faster, but since 1-2 years I
> have the
> > feeling 1) that it is getting too fast and 2) that
> I'm not the only
> > one saying this
> 
> If it's "getting too fast", then that's
> fine, some people are not
> comfortable with rapid change.  Other operating systems
> change much
> slower, perhaps one of them would work out better.
> 
> But right now, the Linux kernel is moving very rapidly. 
> Like it has for
> the past 5 years (I have the numbers to back that up...)

I have the problem since 2.6.20

> 
> Remember, we are changing for real reasons, who is to tell
> a devloper
> that the reason for a change is not allowed just because we
> want to slow
> down?  Does that not make their need somehow less than
> someone elses?

This is not the issue - the original point was to reconsider your understanding what is old in terms of kernel from the user point of view

> 
> We change because the world changes.  In order to survive,
> we also need
> to change.
> 
> If we stop, we die.

This is true, but out of scope - see above. There is no sence to install a new kernel that does not support my hardware and also is outaged when I have the drivers for this kernel version.

> 
> > > Applications are a different story, they should
> "just work" with
> > > different kernel versions, there should not be
> any problems there.
> > > If there are, let the kernel developers know, we
> take backwards
> > > userspace compatiblity VERY seriously.
> > 
> > gcc-4.3 ;-) is it application or what do you mean ...
> the compiler is
> > not an application ;-)
> 
> gcc 4.3 runs just fine on 2.6.22.  It's the fact that
> you want to _use_
> gcc 4.3 to build 2.6.22 that is an issue.  They are two
> totally
> different things here.

Yes I've got your point, you are right. It's producing crap ;-)

>From the user point of view something works if it produces something useful - until then it's not working. 


thank you for the discussion I hope it brings something useful at the end.
I've been using linux since 1999 so I think I have the right feeling in what I need and what I say, though I'm not that close to the kernel dev as you are, as I'm working if different field, so I hope nobody is insulted and I'm trying to put forward a messages and find some useful solution. 

> 
> thanks,

Thank you too

> 
> greg k-h
> --
> To unsubscribe from this list: send the line
> "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html


      

Re: USB driver issue

[Greg KH]

On Sat, Aug 02, 2008 at 01:51:59AM -0700, Emanoil Kotsev wrote:
> 
> > Why are you needing to download new drivers?  Is not
> > everything you need
> > already in the main kernel tree?  What is missing?
> 
> I am using a dell notebook. I also support my father and wife who have
> also notebooks (toshiba and fujitsu).  We all have pretty a like set
> of hardware (from different vendors and in different versions of
> course) but in general it is
> 
> modem, wireless, video (intel, Nvidia, ATI), pcmcia, MMS/SD slot,
> firewire, irda, bluetooth.  I'm using a hybrid tv usb stick and uvc
> webcam.
> 
> - the modem is not working

Did it ever work?  :)

> - wireless (ipw3945) is not included in the mainstream kernel (after
> compile and isntall it works)

It's included in the main kernel tree, has for a while now.

> - uvcvideo driver is included in the latest kernel version and is
> working (thanks)

Good.

> - analog/dvb tv stick is not working as I see it has been included in
> recent version (2.6.26) but it is looking for the wrong firmware or it
> is simply a code with the same name meant to support the HVR-950
> instead of HVR-900 stick.

Talk to the dvb developers, they should be able to fix this quite
easily.

> - I forgot to mention that I'm not able to sync my phones, so there is
> a chaos in my contacts since I gave up my Palm III and lost my Siemens
> S55 that was working somehow

That should have nothing to do with the kernel.

> I also have a pentium III machine that works as a server where all our
> data is stored and backuped, but this is a different issue I mention
> it only to underline the fact that it is practically impossible to
> compile and test there

Build on a faster machine and copy over the image to it.  That's what I
do for my firewalls.

> My father and my wife have a big trouble with the (ATI,NVidia) drivers
> for their video output and I have a big trouble with dual screen, 3D
> and intel chip

Intel drivers should "just work", but that's an xorg issue, not a kernel
issue most likely.  Have you filed a bug with those developers?  They
are usually very quick to respond.

As for ATI and Nvidia, you are on your own there, sorry, nothing anyone
in the community can do to help you out here, sorry.

> Talking about such companies I don't see the point to use linux at
> all, because getting payed support for instance from SuSE brings me to
> the idea that I could buy an Apple PC with more benefit at the end.

Why?   SuSE offers great support, and so does Red Hat.  Heck, even
Ubuntu offers paid support these days if you are liking Debian-based
systems.  And if you have something else, IBM will support it as well,
they support anything.

If you are using Linux only because you get free support, well, then you
need to use the latest releases as the community is not set up at all to
support older releases, it is impossible.

> Hence the question, also having the presentation about kernel
> development in mind, are you developing the kernel as a kind of sport
> ... or are you developing it so that someone can use it for something?

I'm developing it for use by people.  Somehow it seems to be working :)

> > Minor (2.6.x.y) releases happen with only bugfixes every
> > few weeks.  Perhaps you should use them.  But realize that they are
> > only supported for about 3-4 months, then you are expected to move
> > to the next major release.
> 
> This is the issue 3-4 months are enough for ATI or NVidia to bring a new driver
> Either change the policy or find a solution!

How can I have any influence on what ATI or nvidia does?  They know our
release schedule.  They can look at and run our development releases.
But I have no way of seeing their code or running it.

You should be upset at them, not us.

> > That's how the community works, it is insane for us to
> > do otherwise,
> > just for the overhead alone.
> 
> May be I put another question: what are the plans for moving to 2.7 or
> 2.8 kernel then the 2.6. tree will be open only for bug fixes. The
> changes compared to 2.4 are extreem so if I would like to take
> advantage of features in 2.6 kernel I should live with bug fixes and
> support denial in any 2.6 version

Switching the number means nothing, sorry.

See the presentation I liked to for reasons why we will not be switching
the development model any time soon.

In short, this one works _way_ better than the old one.

> > Given the rate of change in the Linux kernel (faster than any other
> > software project known to man), how do you really expect us to do
> > that?  It's pretty impossible.
> 
> The question is - what are you doing this for? What's your goal - I'm
> going to give up linux soon if it goes this way

No one is forcing you to use Linux.  If you don't like it, how it is
developed, the license for it, or how it works, feel free to switch to
something else.  It will not bother me at all.

We'll still be here waiting when you come back :)

> > Again, if you are stuck with such hardware, there is _nothing_ that
> > I or any other kernel developer can do about it.  It is physically
> > impossible.
> 
> The problem is, that ATI, NVidia and a lot of other hardware producers
> are willing to support linux, but can not afford it to bring up
> drivers for the latest stable kernel in the terms you consider it as
> stable - and this was my original point.

No, it's not a matter of "affording" to do anything by these companies.
The community has offered to develop and support drivers for ANY
hardware from ANY company, FOR FREE.  ATI has taken us up on this offer,
and they are getting new drivers because of that.  nvidia does not, and
that is their own issue, not ours.

See www.linuxdriverproject.org for details about this program if you are
curious.

> > With the exception of kernel modules, it should all
> > "just work".  If not, please let us know and we will fix it.
> 
> Then fix the hfs modem for my dell notebook  (oh ... it is closed
> driver by connexant - but they are willing to help me and .... oh,
> they suggest I use the 2.6.24 kernel) And also please fix the em28*
> driver to work with my hybrid HVR-900 properly as it does with the
> v4l-dvb tree in 2.6.24

Please file bugs, these issues will and should be quickly fixed.

As for the hfs modem, I think that should work just fine with the open
drivers we have for them in the kernel tree.

> > We do that already with the -stable release.
> Where are patches for 2.6.26?

Was released yesterday on kernel.org.

> > If anyone wants to step up and maintain a specific kernel release
> > longer than the current -stable team does so, they are more than
> > willing to do so.  2 people have done this in the past quite well.
> 
> I want to know more about it

What specifically do you want to know?

thanks,

greg k-h

Re: USB driver issue

[Daniel Stone]

[-- Attachment #1: Type: text/plain, Size: 5622 bytes --]

On Sat, Aug 02, 2008 at 01:51:59AM -0700, ext Emanoil Kotsev wrote:
> > > Kernel developers should fix bugs in minor kernel
> > versions as they are
> > > meant for this purpous and do major changes only in
> > major version. A
> > > bunch of bugfixes I see (not only usb related) are
> > just not in place
> > > in minor kernel versions. That's my opinion at
> > first place.
> > 
> > Minor (2.6.x.y) releases happen with only bugfixes every
> > few weeks.
> > Perhaps you should use them.  But realize that they are
> > only supported
> > for about 3-4 months, then you are expected to move to the
> > next major
> > release.
> 
> This is the issue 3-4 months are enough for ATI or NVidia to bring a new driver
> Either change the policy or find a solution!

The policy is 'we do not support proprietary drivers' (both in X.Org and
in the kernel).  The solution is for vendors not to produce proprietary
drivers.  Intel, AMD/ATI, and others have already got the message and
already work with us to provide high-quality open source drivers.

If this bothers you, please tell NVIDIA that you're a customer who's
purchased their product, and that you wish to have acceptable (i.e.,
open source) Linux kernel + X.Org support.  That's the only way it will
ever get fixed, full stop.  (Well, either that or through Nouveau.)

> > Given the rate of change in the Linux kernel (faster than
> > any other
> > software project known to man), how do you really expect us
> > to do that?
> > It's pretty impossible.
> 
> The question is - what are you doing this for? What's your goal

I think the primary motivation for most people could be summed up by the
title of Linus Torvalds's autobiography: 'Just for Fun'.  As soon as
it's no longer fun (hint: attempting to force people to do things they
don't think are good ideas usually drains some amount of the fun),
people will begin to walk away.

> I'm going to give up linux soon if it goes this way

I've never met you before, so you'll have to understand if myself and
most others on this list aren't dropping everything to ensure you don't
carry out this threat.

> > No, we expect that you would use hardware that works with,
> > and
> > contributes toward the advancement of Linux.  Not hardware
> > that requires
> > closed source modules.
> 
> I spent a lot of time reading about hardware and linu support when IO bought my dell notebook, that's why I choose one with intel video vard inside ... and what happened - I don't have 3D when using dual screen - GREAT!

Upgrade to Xorg 7.3 or above.  Anything with xorg-server 1.3.0 or above
and xf86-video-intel 2.x.x supports dual screen with 3D just fine, via
XRandR 1.2.  As an added bonus, you get to drop the static configuration
in xorg.conf, and you can have hotplug monitor support, on-the-fly
reconfiguration, etc.  See http://www.intellinuxgraphics.org for more
details.  The Radeon driver also supports this in 6.8.x and above.

> > Again, if you are stuck with such hardware, there is
> > _nothing_ that I or
> > any other kernel developer can do about it.  It is
> > physically
> > impossible.
> 
> The problem is, that ATI, NVidia and a lot of other hardware producers are willing to support linux, but can not afford it to bring up drivers for the latest stable kernel in the terms you consider it as stable - and this was my original point.

AMD/ATI already support it in this model, except for fglrx, which is not
actually for home consumers and game players at all, but for people like
Pixar with huge renderfarms, or heavy CAD users.  Hence the extreme
focus on absolute GL spec compliance, et al.  NVIDIA have chosen not to
support that model.  Their loss.

> Then fix the hfs modem for my dell notebook  (oh ... it is closed driver by connexant - but they are willing to help me and .... oh, they suggest I use the 2.6.24 kernel)

That's not much help then, is it? What happens when NVIDIA have a bug
that forces you to downgrade to 2.6.22, which hfs doesn't support in
that version?

Incidentally, Ubuntu are now having to ship four NVIDIA drivers, because
they keep deprecating support, and the old drivers don't always keep up
with new kernel versions (even stable ones: they receive literally zero
updates once your card is deemed too old).  I assume this is the kind of
'help' and 'support' you keep talking about.

> > We change because the world changes.  In order to survive,
> > we also need
> > to change.
> > 
> > If we stop, we die.
> 
> This is true, but out of scope - see above. There is no sence to install a new kernel that does not support my hardware and also is outaged when I have the drivers for this kernel version.

No-one can do anything about third-party drivers.  If the driver for
your NVIDIA chipset, which is written and shipped by NVIDIA, does not
support the newest kernel version, then complain to NVIDIA, not the
people working on the kernel.  As everyone in this discussion has
repeatedly said, there's nothing anyone can do about third-party
drivers.

Incidentally, a senior NVIDIA manager said a while ago that the reason
their driver isn't open source is because everyone who has any idea
about 3D driver development already works for NVIDIA.  This is their
public justification for keeping the code closed, which means you're
unable to migrate to newer kernels.

If you want to support open source, I'd recommend moving away from
vendors such as these, who clearly don't 'help' or 'support' anything to
do with open source at all.

Cheers,
Daniel

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: USB driver issue

[Daniel Stone]

On Thu, Jul 31, 2008 at 01:38:59PM -0700, ext Emanoil Kotsev wrote:
> Kernel developers should fix bugs in minor kernel versions as they are meant for this purpous and do major changes only in major version. A bunch of bugfixes I see (not only usb related) are just not in place in minor kernel versions. That's my opinion at first place.

Except that the code has often changed as a result of these major
changes, and not everyone wants to track everything that happens in two
branches.  You said it yourself: you don't want to go to the effort of
tracking one major branch.  So why are you trying to force developers to
track two?

> Second if you want to have me as happy linux user developers should agree to support older versions to help embeded and other developers working further on their projects.

That's unbelievably selfish and insulting.  'This free operating system
you gave me is shit! You need to change the entire way you develop for
my benefit!'

No, sorry.

If you want to support older versions, then no-one's stopping you.
Hell, there's still a 2.0 maintainer.  No-one's forcing them to move up
to new versions.

> > Closed source drivers have issues, film at 11.  Bah, take
> > it up with
> > them, there is NOTHING that us developers can do about
> > that, sorry.
> 
> You are neglecting the point and kind of insulting me! So you think I should spent my time convincing about 20 people from different companies to recompile their software because I was told by you to upgrade to fix a usb issue or a kind that is not related to their software and when they finally do it there is a already a new kernel version ... sorry I can not agree with any of you on this point. You want me to spent my time contacting people and not working on my projects ;-)

You said it yourself -- you object to kernel developers, who have given
you a free kernel, telling you how to spend your time.  Yet you have the
right to tell the kernel developers how to spend _their_ time, including
supporting closed-source drivers, which basically amounts to reverse
engineering?

Have you any idea how unbelievably rude this is?

> Why just not be able to patch my old kernel without breaking the ability to use the software I already have installed and is working with the version I use?

If you want, you can follow the development tree and backport the
patches to the last stable version.  No-one's trying to stop you.

> I think this is the question no body wants to answer and I think there is a problem with you guys. What are you doing this development if some people are not happy with it and have reasonable arguments.

I think there's a problem with your attitude, and a pretty serious one
at that.

Open source development generally happens because people enjoy doing it.
If you think they're doing it wrong, do it your way.  I was up until
5:30am last night writing code, and was rewarded with a splitting
headache.  If you think you have a better way to do it and the others
disagree, well, it's up to you to just put in and do it.

Think that's hard? Have other things to do? Well yes, it is hard, and
yes, we all have other things to do.  Now you understand why you
attempting to force people to change the way they work is disrespectful
and insulting, I hope.

> May be the patches should be split into smaller files related to bugs - just an idea!

They are.

> You experience a bug and patch - the bug is gone you are happy.
> May be there should be some longer period to support at least the latest stable releases ... but something should be done.
> I know the Linus policy conserning 2.6. tree has changed for the reason to let us improve faster, but since 1-2 years I have the feeling 1) that it is getting too fast and 2) that I'm not the only one saying this

Okay, so put your money where your mouth is.  Contribute.

Until I see patches (instead of mails telling us how hard your life is
because you don't have the time to test one kernel version, but kernel
developers should all spend the time to test two or more) from you, I
have nothing more to say to you.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB driver issue

[Riku Voipio]

On Thu, Jul 31, 2008 at 08:30:26AM -0700, Emanoil Kotsev wrote:
> I think everything is getting pretty messy recently - I was pretty satisfied with 2.6.20 and then tried 2.6.24. In fact I can not compile 2.6.20 right now because after an upgrade debian testing comes with gcc-4.3 that has a background struggle about who's wrong between gcc people and Linus Torvalds and the issue is still open.

apt-get install gcc-4.1

Now that was hard.

Cheers, Riku

-- 

RE: USB driver issue

[Dasgupta, Romit]

What is the application you are using and could you turn the musb driver debug options? You can try it by

echo "D 3"  > /proc/driver/musb_hdrc  (Check if MUSB_DEBUG is enabled).

This should give more helpful messages.



>-----Original Message-----
>From: linux-omap-open-source-bounces@linux.omap.com [mailto:linux-omap-open-
>source-bounces@linux.omap.com] On Behalf Of SUBHRANIL CHOUDHURY
>Sent: Wednesday, July 30, 2008 5:50 PM
>To: Gadiyar, Anand
>Cc: linux-omap-open-source@linux.omap.com
>Subject: Re: USB driver issue
>
>hi,
>I am using Mistral OMAP3430 OSK2.1 board. It is the USB OTG port.
>The Philips tranciever ISP1504.
>I am enabling the EHCI and OHCI in the kernel menuconfig.
>
>This was the error print i was getting:
>
>Unable to handle kernel NULL pointer dereference at virtual address 00000000
>pgd = c54d8000
>[00000000] *pgd=81401031, *pte=00000000, *ppte=00000000
>Internal error: Oops: 817 [#1]
>Modules linked in:
>CPU: 0    Not tainted  (2.6.22.18-omap3 #29)
>PC is at consistent_sync+0x40/0xa4
>LR is at usb_hcd_submit_urb+0x7b0/0x8b4
>pc : [<c00315ac>]    lr : [<c02307e0>]    psr: 20000013
>sp : c1403c48  ip : c1403c58  fp : c1403c54
>r10: ffff8003  r9 : 00000020  r8 : 00000020
>r7 : c483dc20  r6 : c0569000  r5 : c23c040c  r4 : ff2d2000
>r3 : 00000000  r2 : 00000002  r1 : ff2dba38  r0 : ff2d2000
>Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  Segment user
>Control: 00c5387f  Table: 854d8018  DAC: 00000015
>
>Do you get some clue from this about what is happening?
>
>
>
>
>On Wed, Jul 30, 2008 at 5:35 PM, Gadiyar, Anand <gadiyar@ti.com> wrote:
>
>> > Hi all,
>> > I am trying to validate the USB driver on OMAP3430 with the
>> > 2.6.22.18kernel. I am facing problems in the process while trying to
>> > do a USB transfer with DMA enabled.
>> > The apllication is breaking in a function called
>> > consistent_sync. The error message is like "Unable to handle kernel Null
>> pointer".
>>
>> Which board are you using? Which is the USB port - EHCI/OHCI/OTG?
>>
>> Assuming it is the USB OTG port (because that is the only one where you
>> can enable or disable DMA), what is the transceiver being used on the port?
>>
>>
>> > The issue is same with both OHCI and EHCI controller. And the
>> > issue is not coming if i disable DMA.
>>
>> I don't think you have control over DMA disabling with the OHCI/EHCI
>> controller. Are you sure you are using the OHCI/EHCI controller?
>>
>> The "Unable to handle kernel Null pointer" message comes with some more
>> data.
>> We won't be able to help you out without the rest of the log, but the
>> answers to
>> questions above are essential before we move on to this.
>>
>> >
>> > Has anyone tried USB packet transfer with DMA enabled? Please
>> > let me know.
>> >
>> > Regards,
>> > Subhro
>>
>_______________________________________________
>Linux-omap-open-source mailing list
>Linux-omap-open-source@linux.omap.com
>http://linux.omap.com/mailman/listinfo/linux-omap-open-source

Re: USB driver issue

[Felipe Balbi]

On Wed, Jul 30, 2008 at 06:28:35PM +0530, ext Dasgupta, Romit wrote:
> What is the application you are using and could you turn the musb driver debug options? You can try it by
> 
> echo "D 3"  > /proc/driver/musb_hdrc  (Check if MUSB_DEBUG is enabled).

it's D3, together :-)

> 
> This should give more helpful messages.
> 
> 
> 
> >-----Original Message-----
> >From: linux-omap-open-source-bounces@linux.omap.com [mailto:linux-omap-open-
> >source-bounces@linux.omap.com] On Behalf Of SUBHRANIL CHOUDHURY
> >Sent: Wednesday, July 30, 2008 5:50 PM
> >To: Gadiyar, Anand
> >Cc: linux-omap-open-source@linux.omap.com
> >Subject: Re: USB driver issue
> >
> >hi,
> >I am using Mistral OMAP3430 OSK2.1 board. It is the USB OTG port.
> >The Philips tranciever ISP1504.
> >I am enabling the EHCI and OHCI in the kernel menuconfig.
> >
> >This was the error print i was getting:
> >
> >Unable to handle kernel NULL pointer dereference at virtual address 00000000
> >pgd = c54d8000
> >[00000000] *pgd=81401031, *pte=00000000, *ppte=00000000
> >Internal error: Oops: 817 [#1]
> >Modules linked in:
> >CPU: 0    Not tainted  (2.6.22.18-omap3 #29)
> >PC is at consistent_sync+0x40/0xa4
> >LR is at usb_hcd_submit_urb+0x7b0/0x8b4
> >pc : [<c00315ac>]    lr : [<c02307e0>]    psr: 20000013
> >sp : c1403c48  ip : c1403c58  fp : c1403c54
> >r10: ffff8003  r9 : 00000020  r8 : 00000020
> >r7 : c483dc20  r6 : c0569000  r5 : c23c040c  r4 : ff2d2000
> >r3 : 00000000  r2 : 00000002  r1 : ff2dba38  r0 : ff2d2000
> >Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  Segment user
> >Control: 00c5387f  Table: 854d8018  DAC: 00000015
> >
> >Do you get some clue from this about what is happening?

there must be a backtrace right after that, can you paste it as well?

-- 
balbi