[jp] Sync problems

  • Previous message: [jp] Sync problems
  • Next message: [jp] Sync problems
  • Peter Jay Salzman p at dirac.org
    Thu Nov 23 10:10:58 EST 2006

     

    On Thu 23 Nov 06, 12:05 PM, Alan J Munday (Most Rev.) <almunday at ilovecountry.net> said:
    > If I may join in here, as one who has similarly not been able to get s
    > sync at all -
    
    LOL!
    
    
    > As Pete suggested -
    > 
    > >You can check to see if it's built directly into the kernel (as opposed
    > >to a loadable module) with:
    > >
    > >   $ zcat /proc/config.gz | grep -i visor
    > 
    > I tried this and got the result "CONFIG_USB_SERIAL_VISOR=m".  What does
    > this mean please?
     
    Alan, I don't know how much you know, so please forgive me if I explain
    anything you already know.
    
    Linux kernel modules can be either built directly into the kernel or built
    as loadable modules.
    
    If they're built directly into the kernel, they are available immediately
    for use when their service is requested.
    
    If they're built as modules, they are loaded into the kernel at run time
    when their service is requested.
    
    The meaning of "when their service is requested" is when the device file
    that represents the hardware they're responsible for is accessed.  Here's an
    examaple:
    
    Suppose I print a file.  The user-space printer daemon (lpd) opens the device
    file /dev/lp and writes data into the file.  The kernel searches a list of
    "registered modules" for any driver that registers itself as the handler of
    /dev/lp.
    
    The driver that handles the parallel port (/dev/lp) is called parport.  If
    parport was built into the kernel, then the kernel finds the module and
    executes the module to handle the writing of data into /dev/lp.  On the
    other hand, if parport is built as a module, the kernel doesn't find parport
    but finds out that parport is available as a module.  It then loads parport
    into kernel space at runtime and executes it.
    
    
    How do you configure a driver to be built into the kernel or built as a
    module?  When you configure the kernel before compiling it, you can specify
    this.  There's a file called ".config" that is a list of all the modules
    available to the Linux kernel, along with whether they're to be built as a
    module or not.
    
    The file /proc/config.gz is one of the coolest, most useful additions to the
    kernel.  I don't remember when it first appeared --- it was sometime in the
    late 90's, I think.  But I remember when I first saw it, I fell in love.  It
    seemed like such an obvious idea.  This file is the image of the ".config"
    that was used to build the kernel.
    
    End of theory.  Sorry if this wasn't explained correctly, I was up very late
    last night, and my head is spinning from lack of sleep.
    
    You said that you saw this in your /proc/config.gz:
    
       "CONFIG_USB_SERIAL_VISOR=m"
    
    This means that the visor driver was built as a module for the kernel you're
    using.  This is pretty standard for kernels that come directly from Linux
    distros.  They tend to build everything as a module so their kernels aren't
    huge behemoth files.
    
    > If there are some tweaks that might put my system working in the right
    > direction, please, if this indicates that it is not, I would appreciate
    > further advice.
     
    BTW, I've lost the ability to sync my visor too, but I think my problem is
    with udev.  I haven't had time to fix the problem, but I may be able to help
    you with your problem.
    
    So now we know your visor driver is built as a module.  The next step is to
    make sure the driver is loaded.  The command "lsmod" lists all the currently
    loaded modules.  Do this:
    
       $ lsmod
    
    Do you see "visor" in the output?  If not, do this to load the module:
    
       $ modprobe -a visor
    
    If you *do* see "visor" in the output, I don't think I can help you further
    (but I'll try).
    
    > I do not intend any offence, but from what I have seen, the advice
    > available on various fora, always seems to be on the basis of "try
    > this", but with little follow up advice and the information goes cold.
    
    Usually that means the person helping you is out of ideas.  It's not really
    their fault they don't know how to help further.
    
    > I suppose it would be useful for some kind of on-line faq to be produced
    > with different recipes relating to different possible set-ups, so that
    > we could all benefit.  It is extremely frustrating as it is at the moment.
     
    Yeah, that would be useful, I agree.
    
    > For those of you who are able to sync without any problems, what kernels
    > are you using and are there any of you who run on the same kernels, but
    > which do not work for  you?  If we could pin down a kernel that gives
    > satisfaction on this, perhaps this would help.
    
    I'm not aware of any current visor module bugs.  If anyone can confirm this,
    it would be useful.
    
    > To those of you who live in the USA, hope you are having a wonderful
    > Thanksgiving.
     
    Many thanks!  It seems like we're having less and less to be thankful for in
    this crazy world of ours.  But at least we (USA) now have a more balanced
    government.  Maybe that'll make things better.
    
    In any event, I'm looking forward to tonight's dinner...   :-)
    
    Peter
    
    -- 
    How VBA rounds a number depends on the number's internal representation.
    You cannot always predict how it will round when the rounding digit is 5.
    If you want a rounding function that rounds according to predictable rules,
    you should write your own.
                  -- MSDN, on Microsoft VBA's "stochastic" rounding function
    
    Peter Jay Salzman, email: p at dirac.org web: http://www.dirac.org/p    
    PGP Fingerprint: B9F1 6CF3 47C4 7CD8 D33E  70A9 A3B9 1945 67EA 951D
    
    

     

     

    More information about the jpilot mailing list