Re: Backport of a 2.6.x USB driver to 2.4.32 - help needed

Re: Backport of a 2.6.x USB driver to 2.4.32 - help needed

[Pete Zaitcev]

On Tue, 06 Jun 2006 11:48:36 +0200, Heiko Gerstung <heiko.gerstung@meinberg.de> wrote:

> [...] The maintainer of the driver
> modified a few things for me in order to address this problem ("it
> happens because get/set_registers() are called with no process
> context"), but he was only able to modify the 2.6.x driver for me.

> I started to backport the modified version, but it seems that I ran into
> dependency hell because I get the following two missing functions
> reported when I try to compile the backported module:
> 
> rtl8150.c: In Funktion »rtl8150_get_settings«:
> rtl8150.c:790: Warnung: implicit declaration of function `in_atomic'
> rtl8150.c: In Funktion »rtl8150_thread«:
> rtl8150.c:857: Warnung: implicit declaration of function
> `schedule_timeout_uninterruptible'

Tell the author to do it differently. Drivers have no business
to call in_atomic(). So, he postpones some accesses until later.
This is an easy way out, I did it myself in 2.4's usb-serial,
but it's wrong. I don't see what his excuse is. Mine was that
I didn't want to debug a freaking gazillion of usb-storage
subdrivers.

Who's the guy, anyway? Was it Petkan? I'm sure he'll listen
to reason, I worked with him before.

I'm going to keep an eye on rtl8150 and oppose in_atomic when
it sneaks in.

-- Pete

Re: Backport of a 2.6.x USB driver to 2.4.32 - help needed

[Heiko Gerstung]

Hi, Pete:

Pete Zaitcev wrote:
> On Tue, 06 Jun 2006 11:48:36 +0200, Heiko Gerstung <heiko.gerstung@meinberg.de> wrote:
> 
>> [...] The maintainer of the driver
>> modified a few things for me in order to address this problem ("it
>> happens because get/set_registers() are called with no process
>> context"), but he was only able to modify the 2.6.x driver for me.
> 
>> I started to backport the modified version, but it seems that I ran into
>> dependency hell because I get the following two missing functions
>> reported when I try to compile the backported module:
>>
>> rtl8150.c: In Funktion »rtl8150_get_settings«:
>> rtl8150.c:790: Warnung: implicit declaration of function `in_atomic'
>> rtl8150.c: In Funktion »rtl8150_thread«:
>> rtl8150.c:857: Warnung: implicit declaration of function
>> `schedule_timeout_uninterruptible'
> 
> Tell the author to do it differently. Drivers have no business
> to call in_atomic(). So, he postpones some accesses until later.
> This is an easy way out, I did it myself in 2.4's usb-serial,
> but it's wrong. I don't see what his excuse is. Mine was that
> I didn't want to debug a freaking gazillion of usb-storage
> subdrivers.

His "excuse" is that he simply has not enough time to "do it right"(tm),
he just wanted to help me with a quick workaround.

> Who's the guy, anyway? Was it Petkan? I'm sure he'll listen
> to reason, I worked with him before.
Yes, it's Petko and I know that he is a good coder and just wanted to
help me out, although he was busy with projects he gets paid for.

> I'm going to keep an eye on rtl8150 and oppose in_atomic when
> it sneaks in.
Don't worry, I was not able to resolve the problems I got by working
around other problems. We will have to check if there is another
solution for our product as we have no chance to use a 2.4 kernel anymore.

Kind regards,
Heiko


> 
> -- Pete


-- 
------------------------------------------------------------------------

*MEINBERG Funkuhren GmbH & Co. KG*
Auf der Landwehr 22
D-31812 Bad Pyrmont, Germany
Tel.: ++49 (0)5281 9309-25
Fax: ++49 (0)5281 9309-30
eMail: heiko.gerstung@meinberg.de <mailto:heiko.gerstung@meinberg.de>
Internet: www.meinberg.de <http://www.meinberg.de/>

------------------------------------------------------------------------

Meinberg radio clocks: 25 years of accurate time worldwide

Re: Backport of a 2.6.x USB driver to 2.4.32 - help needed

[Robert Hancock]

Jesper Juhl wrote:
> On 06/06/06, Heiko Gerstung <heiko.gerstung@meinberg.de> wrote:
>> Hi!
>>
>> Short Version (tm): I try to backport a USB driver (rtl8150.c) from
>> 2.6.15.x to 2.4.32 and have no idea how to substitue two functions:
>> in_atomic() and schedule_timeout_uninterruptible() ... I really would
>> appreciate any help, because I am no kernel hacker at all ...
>>
> in_atomic() is used to test if the kernel is in a state where sleeping
> is allowed or not. The 2.4.x kernel is not preemptive and has quite
> coarse grained SMP support (the BKL "Big Kernel Lock"), it didin't
> need in_atomic() in the same way as 2.6.x does.

There's little difference in the need for it, 2.4 just doesn't have it. 
I don't see a call to that function in that driver's code though?

> 
> schedule_timeout_uninterruptible() is used to sleep on a wait-queue,
> which 2.4.x does not have.

Huh? 2.4 did have wait queues, but that call has nothing to do with 
them. You should be able to replace it with:

set_current_state( TASK_UNINTERRUPTIBLE );
schedule_timeout( timeout );

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: Backport of a 2.6.x USB driver to 2.4.32 - help needed

[Heiko Gerstung]

Robert Hancock wrote:
> Jesper Juhl wrote:
>> On 06/06/06, Heiko Gerstung <heiko.gerstung@meinberg.de> wrote:
>>> Hi!
>>>
>>> Short Version (tm): I try to backport a USB driver (rtl8150.c) from
>>> 2.6.15.x to 2.4.32 and have no idea how to substitue two functions:
>>> in_atomic() and schedule_timeout_uninterruptible() ... I really would
>>> appreciate any help, because I am no kernel hacker at all ...
>>>
>> in_atomic() is used to test if the kernel is in a state where sleeping
>> is allowed or not. The 2.4.x kernel is not preemptive and has quite
>> coarse grained SMP support (the BKL "Big Kernel Lock"), it didin't
>> need in_atomic() in the same way as 2.6.x does.
> 
> There's little difference in the need for it, 2.4 just doesn't have it.
> I don't see a call to that function in that driver's code though?
It is in the modified version. In the long version of my post I wrote
that the maintainer of the driver was so kind to modify the 2.6 driver
code for me, because using such an interface in a bonding configuration
always leads to kernel crashes in 2.4 kernels (I tested 2.4.20 and
2.4.32). Backporting the unmodified 2.6 driver did not change that and
it seems that the crashes are caused by the way the bonding code is
accessing the interface (in combination with the buggy driver, of course).

>> schedule_timeout_uninterruptible() is used to sleep on a wait-queue,
>> which 2.4.x does not have.
> 
> Huh? 2.4 did have wait queues, but that call has nothing to do with
> them. You should be able to replace it with:
> 
> set_current_state( TASK_UNINTERRUPTIBLE );
> schedule_timeout( timeout );

Thanks for the tip!

I will take a look into the differences between the 2.4 and 2.6 bonding
code and will come back here with questions (that one is for sure!).

Kind regards,
Heiko



-- 
------------------------------------------------------------------------

*MEINBERG Funkuhren GmbH & Co. KG*
Auf der Landwehr 22
D-31812 Bad Pyrmont, Germany
Tel.: ++49 (0)5281 9309-25
Fax: ++49 (0)5281 9309-30
eMail: heiko.gerstung@meinberg.de <mailto:heiko.gerstung@meinberg.de>
Internet: www.meinberg.de <http://www.meinberg.de/>

------------------------------------------------------------------------

Meinberg radio clocks: 25 years of accurate time worldwide

Backport of a 2.6.x USB driver to 2.4.32 - help needed

[Heiko Gerstung]

Hi!

Short Version (tm): I try to backport a USB driver (rtl8150.c) from
2.6.15.x to 2.4.32 and have no idea how to substitue two functions:
in_atomic() and schedule_timeout_uninterruptible() ... I really would
appreciate any help, because I am no kernel hacker at all ...

Long Version (tm):
I have problems backporting a USB driver from 2.6.15.x to 2.4.32 and I
am at a total loss because I am not really a device driver hacker and it
seems that the original author/maintainer is currently very busy and has
no chance to support me in this case (although his support so far was
excellent!).

I still fight with the driver for Realtek 8150 based USB-to-Ethernet
products (drivers/usb/net/rtl8150.c in 2.6.x kernels,
/drivers/usb/rtl8150.c in the 2.4 kernel tree).

Under 2.4.32 this driver crashes (kernel panic) when I try to enslave a
network interface handled by it, with a 2.6 kernel there is no such
problem. Unfortunately I cannot go ahead with a 2.6 kernel at the
moment, because it lacks a properly running PPS support.

I therefore backported the 2.6.x driver to compile cleanly under 2.4.32
and it still crashes when I try to enslave such an interface in miimon
mode. I think there is a difference in the way the bonding module checks
 the MII link status of the device. The maintainer of the driver
modified a few things for me in order to address this problem ("it
happens because get/set_registers() are called with no process
context"), but he was only able to modify the 2.6.x driver for me.

I started to backport the modified version, but it seems that I ran into
dependency hell because I get the following two missing functions
reported when I try to compile the backported module:

rtl8150.c: In Funktion »rtl8150_get_settings«:
rtl8150.c:790: Warnung: implicit declaration of function `in_atomic'
rtl8150.c: In Funktion »rtl8150_thread«:
rtl8150.c:857: Warnung: implicit declaration of function
`schedule_timeout_uninterruptible'

Now I would need help in finding a way to substitute the two missing
functions in a 2.4 kernel environment and I desperately hope that
someone sees my dilemma and can help me somehow...

Anyway, thank you for spending the time to at least read this post (and
thanks a lot if you could spend a few cycles on thinking about a
possible solution!).

Kind regards,
Heiko



-- 
------------------------------------------------------------------------

*MEINBERG Funkuhren GmbH & Co. KG*
Auf der Landwehr 22
D-31812 Bad Pyrmont, Germany
Tel.: ++49 (0)5281 9309-25
Fax: ++49 (0)5281 9309-30
eMail: heiko.gerstung@meinberg.de <mailto:heiko.gerstung@meinberg.de>
Internet: www.meinberg.de <http://www.meinberg.de/>

------------------------------------------------------------------------

Meinberg radio clocks: 25 years of accurate time worldwide

Re: Backport of a 2.6.x USB driver to 2.4.32 - help needed

[Jesper Juhl]

On 06/06/06, Heiko Gerstung <heiko.gerstung@meinberg.de> wrote:
> Hi!
>
> Short Version (tm): I try to backport a USB driver (rtl8150.c) from
> 2.6.15.x to 2.4.32 and have no idea how to substitue two functions:
> in_atomic() and schedule_timeout_uninterruptible() ... I really would
> appreciate any help, because I am no kernel hacker at all ...
>
in_atomic() is used to test if the kernel is in a state where sleeping
is allowed or not. The 2.4.x kernel is not preemptive and has quite
coarse grained SMP support (the BKL "Big Kernel Lock"), it didin't
need in_atomic() in the same way as 2.6.x does.

schedule_timeout_uninterruptible() is used to sleep on a wait-queue,
which 2.4.x does not have.


[snip]
>
> Under 2.4.32 this driver crashes (kernel panic) when I try to enslave a
> network interface handled by it, with a 2.6 kernel there is no such
> problem. Unfortunately I cannot go ahead with a 2.6 kernel at the
> moment, because it lacks a properly running PPS support.
>
Wouldn't it make more sense to work on improving PPS (I assume you are
refering to NTP "pulse per second" btw) support in 2.6.x rather than
backporting an USB driver to 2.4.x ???


[snip]
>
> Now I would need help in finding a way to substitute the two missing
> functions in a 2.4 kernel environment and I desperately hope that
> someone sees my dilemma and can help me somehow...
>
The book "Linux Device Drivers" third edition is available for free
online and describes 2.6.x USB drivers in a fair bit of detail.
Earlier editions of the book describe the 2.4.x kernel (don't know if
those are available for free, but it should be possible to get them
from a bookstore in any case).

Getting hold of the second & third editions of LDD and comparing the
USB info from both should give you some idea of where to start...


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: Backport of a 2.6.x USB driver to 2.4.32 - help needed

[Heiko Gerstung]

Jesper Juhl wrote:
> in_atomic() is used to test if the kernel is in a state where sleeping
> is allowed or not. The 2.4.x kernel is not preemptive and has quite
> coarse grained SMP support (the BKL "Big Kernel Lock"), it didin't
> need in_atomic() in the same way as 2.6.x does.
OK, so I guess I can safely ommit this.

> schedule_timeout_uninterruptible() is used to sleep on a wait-queue,
> which 2.4.x does not have.
Is there any similiar functionality in a 2.4 kernel environment? A
pointer to a 2.4 kernel driver using such a mechanism would be a good
starter...

> [snip]
> Wouldn't it make more sense to work on improving PPS (I assume you are
> refering to NTP "pulse per second" btw) support in 2.6.x rather than
> backporting an USB driver to 2.4.x ???
Yes, but unfortunately I have no chance to do this and therefore I rely
on others to do this. Well, the same applies to [me] and [kernel
drivers], but I hoped that it might be easier to try and backport one
driver instead of trying to improve other people's code (maybe that is
what OPC stands for :-)), especially when this code has a much larger
impact on several parts of the kernel.

> [snip]
> The book "Linux Device Drivers" third edition is available for free
> online and describes 2.6.x USB drivers in a fair bit of detail.
> Earlier editions of the book describe the 2.4.x kernel (don't know if
> those are available for free, but it should be possible to get them
> from a bookstore in any case).
> 
> Getting hold of the second & third editions of LDD and comparing the
> USB info from both should give you some idea of where to start...
OK, I will try to do so, but I am afraid that I will run out of time in
the meantime.

Thank you very much for your help and your fast response.

Kind regards,
Heiko




-- 
------------------------------------------------------------------------

*MEINBERG Funkuhren GmbH & Co. KG*
Auf der Landwehr 22
D-31812 Bad Pyrmont, Germany
Tel.: ++49 (0)5281 9309-25
Fax: ++49 (0)5281 9309-30
eMail: heiko.gerstung@meinberg.de <mailto:heiko.gerstung@meinberg.de>
Internet: www.meinberg.de <http://www.meinberg.de/>

------------------------------------------------------------------------

Meinberg radio clocks: 25 years of accurate time worldwide

Re: Backport of a 2.6.x USB driver to 2.4.32 - help needed

[Lennart Sorensen]

On Tue, Jun 06, 2006 at 01:41:02PM +0200, Heiko Gerstung wrote:
> Yes, but unfortunately I have no chance to do this and therefore I rely
> on others to do this. Well, the same applies to [me] and [kernel
> drivers], but I hoped that it might be easier to try and backport one
> driver instead of trying to improve other people's code (maybe that is
> what OPC stands for :-)), especially when this code has a much larger
> impact on several parts of the kernel.

Which part of PPS doesn't work on 2.6 if you have the PPS-kit-light
installed?  There is a version for 2.6.15 around, which applies to
2.6.16 with minimal fixing.  Only problem I found so far with the code
was that it breaks the serial console on my system, but that was easy to
fix.  I still have to test it though since my serial port has the CD
line stuck high at the moment until I can get the board fixed, so
testing is a bit tricky.

I know I have run a gps receiver with PPS on the CD line under 2.6.8
using PPS-kit-light, and it worked rather well.

Len Sorensen

Re: Backport of a 2.6.x USB driver to 2.4.32 - help needed

[Heiko Gerstung]

Hi, Lennart:

Lennart Sorensen wrote:
> On Tue, Jun 06, 2006 at 01:41:02PM +0200, Heiko Gerstung wrote:
>> Yes, but unfortunately I have no chance to do this and therefore I rely
>> on others to do this. Well, the same applies to [me] and [kernel
>> drivers], but I hoped that it might be easier to try and backport one
>> driver instead of trying to improve other people's code (maybe that is
>> what OPC stands for :-)), especially when this code has a much larger
>> impact on several parts of the kernel.
> 
> Which part of PPS doesn't work on 2.6 if you have the PPS-kit-light
> installed?  There is a version for 2.6.15 around, which applies to
> 2.6.16 with minimal fixing.  Only problem I found so far with the code
> was that it breaks the serial console on my system, but that was easy to
> fix.  I still have to test it though since my serial port has the CD
> line stuck high at the moment until I can get the board fixed, so
> testing is a bit tricky.
> 
> I know I have run a gps receiver with PPS on the CD line under 2.6.8
> using PPS-kit-light, and it worked rather well.

It works but on my system it takes ~4 hours before I reach lower
microsecond offsets, where the 2.4 ppskit is below 10 microseconds after
four polling cycles. I already tried to fix that but the internal kernel
pps discipline is not working as good as  it did with the 2.4 ppskit
versions.

> 
> Len Sorensen

Kind regards,
Heiko



-- 
------------------------------------------------------------------------

*MEINBERG Funkuhren GmbH & Co. KG*
Auf der Landwehr 22
D-31812 Bad Pyrmont, Germany
Tel.: ++49 (0)5281 9309-25
Fax: ++49 (0)5281 9309-30
eMail: heiko.gerstung@meinberg.de <mailto:heiko.gerstung@meinberg.de>
Internet: www.meinberg.de <http://www.meinberg.de/>

------------------------------------------------------------------------

Meinberg radio clocks: 25 years of accurate time worldwide

Re: Backport of a 2.6.x USB driver to 2.4.32 - help needed

[Lennart Sorensen]

On Tue, Jun 06, 2006 at 04:48:44PM +0200, Heiko Gerstung wrote:
> It works but on my system it takes ~4 hours before I reach lower
> microsecond offsets, where the 2.4 ppskit is below 10 microseconds after
> four polling cycles. I already tried to fix that but the internal kernel
> pps discipline is not working as good as  it did with the 2.4 ppskit
> versions.

I guess that is the light part. :)

Len Sorensen

Re: Backport of a 2.6.x USB driver to 2.4.32 - help needed

[Nish Aravamudan]

On 6/6/06, Jesper Juhl <jesper.juhl@gmail.com> wrote:
> On 06/06/06, Heiko Gerstung <heiko.gerstung@meinberg.de> wrote:
> > Hi!
> >
> > Short Version (tm): I try to backport a USB driver (rtl8150.c) from
> > 2.6.15.x to 2.4.32 and have no idea how to substitue two functions:
> > in_atomic() and schedule_timeout_uninterruptible() ... I really would
> > appreciate any help, because I am no kernel hacker at all ...
> >
> in_atomic() is used to test if the kernel is in a state where sleeping
> is allowed or not. The 2.4.x kernel is not preemptive and has quite
> coarse grained SMP support (the BKL "Big Kernel Lock"), it didin't
> need in_atomic() in the same way as 2.6.x does.
>
> schedule_timeout_uninterruptible() is used to sleep on a wait-queue,
> which 2.4.x does not have.

schedule_timeout_uninterruptible(timeout_value) is just a wrapper for

set_current_state(TASK_UNINTERRUPTIBLE);
schedule_timeout(timeout_value);

Maybe you were thinking of sleep_on*()?

Thanks,
Nish

Re: Backport of a 2.6.x USB driver to 2.4.32 - help needed

[Jesper Juhl]

On 06/06/06, Nish Aravamudan <nish.aravamudan@gmail.com> wrote:
> On 6/6/06, Jesper Juhl <jesper.juhl@gmail.com> wrote:
> > On 06/06/06, Heiko Gerstung <heiko.gerstung@meinberg.de> wrote:
> > > Hi!
> > >
> > > Short Version (tm): I try to backport a USB driver (rtl8150.c) from
> > > 2.6.15.x to 2.4.32 and have no idea how to substitue two functions:
> > > in_atomic() and schedule_timeout_uninterruptible() ... I really would
> > > appreciate any help, because I am no kernel hacker at all ...
> > >
> > in_atomic() is used to test if the kernel is in a state where sleeping
> > is allowed or not. The 2.4.x kernel is not preemptive and has quite
> > coarse grained SMP support (the BKL "Big Kernel Lock"), it didin't
> > need in_atomic() in the same way as 2.6.x does.
> >
> > schedule_timeout_uninterruptible() is used to sleep on a wait-queue,
> > which 2.4.x does not have.
>
> schedule_timeout_uninterruptible(timeout_value) is just a wrapper for
>
> set_current_state(TASK_UNINTERRUPTIBLE);
> schedule_timeout(timeout_value);
>
> Maybe you were thinking of sleep_on*()?
>

Yeah, you are right, that was what I was thinking of. My bad.
Thank you for the correction.

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html