Loading ...
Sorry, an error occurred while loading the content.

Requirements for OpenDebianSlug and some other questions

Expand Messages
  • mbanditt
    OpenDebianSlug sounds very interesting because of its huge package repository (when its finished :-). However, I`ve been wondering about the memory and cpu
    Message 1 of 17 , Aug 31, 2005
    • 0 Attachment
      OpenDebianSlug sounds very interesting because of its huge package
      repository (when its finished :-).

      However, I`ve been wondering about the memory and cpu requirements of
      a Debian OS versus the OpenSlug OS. As I understand it, OpenSlug is
      based on OpenEmbedded, which aims at providing packages optimized for
      low memory and cpu usage. Considering the only 32MB of RAM and the
      slow CPU (266MHz), I wonder how OpenDebianSlug performs vs. OpenSlug.
      What's your experience?

      Furthermore, there is one other question I have. One of the problems
      I'm having with OpenSlug is that I cannot get hpoj to work (scanner
      support for HP Officejets). hpoj compiles and installs fine, however
      the transport component 'ptal-mcld' produces a lot of runtime
      alignment errors
      and thus simply doesn't work.

      Now, would a DebianSlug help? Or would the DebianSlug also have the
      same problems as it is also a BigEndian OS?

      By the way, if I get to install OpenDebianSlug, I would be interested
      in the following packages: thttpd, cups, saned, libjpeg, openvpn,
      ctorrent, amule (though not sure if that's not too heavy...), screen
      :-)

      Cheers,

      Michael
    • Mario
      ... yeah! :) ... This is a GOOD question. ... My guess: yes. ... my addition: rtorrent. Mario -- Home Page: http://www.marioland.it GnuPG/PGP key (ID BAC3EBB1)
      Message 2 of 17 , Aug 31, 2005
      • 0 Attachment
        mbanditt wrote:
        > OpenDebianSlug sounds very interesting because of its huge package
        > repository (when its finished :-).

        yeah! :)

        > However, I`ve been wondering about the memory and cpu requirements of
        > a Debian OS versus the OpenSlug OS. As I understand it, OpenSlug is
        > based on OpenEmbedded, which aims at providing packages optimized for
        > low memory and cpu usage. Considering the only 32MB of RAM and the
        > slow CPU (266MHz), I wonder how OpenDebianSlug performs vs. OpenSlug.
        > What's your experience?

        This is a GOOD question.

        > Furthermore, there is one other question I have. One of the problems
        > I'm having with OpenSlug is that I cannot get hpoj to work (scanner
        > support for HP Officejets). hpoj compiles and installs fine, however
        > the transport component 'ptal-mcld' produces a lot of runtime
        > alignment errors
        > and thus simply doesn't work.
        >
        > Now, would a DebianSlug help? Or would the DebianSlug also have the
        > same problems as it is also a BigEndian OS?

        My guess: yes.

        > By the way, if I get to install OpenDebianSlug, I would be interested
        > in the following packages: thttpd, cups, saned, libjpeg, openvpn,
        > ctorrent, amule (though not sure if that's not too heavy...), screen

        my addition: rtorrent.

        Mario

        --
        Home Page: http://www.marioland.it
        GnuPG/PGP key (ID BAC3EBB1) available on key-servers
      • Inge Bjørnvall Arnesen
        ... Well, I guess there hasn t been much experience at all, but I can provide some as well as informed armchair reflections: - The kernel and modules will be
        Message 3 of 17 , Aug 31, 2005
        • 0 Attachment
          > However, I`ve been wondering about the memory and cpu
          > requirements of a Debian OS versus the OpenSlug OS. As I
          > understand it, OpenSlug is based on OpenEmbedded, which
          > aims at providing packages optimized for low memory and
          > cpu usage. Considering the only 32MB of RAM and the slow
          > CPU (266MHz), I wonder how OpenDebianSlug performs vs.
          > OpenSlug. What's your experience?

          Well, I guess there hasn't been much experience at all, but I can provide
          some as well as informed armchair reflections:

          - The kernel and modules will be the same as Openslug
          - OpenDebianSlug will probably take up some more disk space. Packages
          include proper docs and so on. I don't think this will matter to people with
          hard drives. The Memstick-people should perhaps think twice before heading
          there (little disk space and often no swap).
          - Since the slug has disk and swap space, many of the openembedded
          considerations wrt. installation memory use is not as important as with
          iPaq's and stuff like that.
          - I don't think there should be much difference between the applications as
          they are distributed in Unslung, OpenSlug and OpenDebianSlug. Any
          differences are probably due to removing features or setting lower buffer
          sizes. I don't think there is much like that in Unslung/Openslug. BUT - look
          at this (some fragments from top on Unslung 5.5 vs. OpenDebianSlug). Lines
          starting with "U" are from Unslung and "D" from OpenDebianSlug. The relevant
          columns are number 5, 6 and 7 counting from the left, being virtual,
          resident and shared memory respectivly (I believe):

          U: 1461 bob 9 0 1692 1272 1192 S 0.0 4.2 0:11.61 smbd
          D: 761 root 16 0 9220 2692 2100 S 0.0 8.8 0:00.57 smbd

          Note: Unslung is version 2 and Debian version 3. No buffers tweaked.

          U: 3618 root 16 0 832 792 656 R 1.0 2.6 1:40.11 top
          D: 2615 root 15 0 2188 920 752 R 3.8 3.0 0:00.08 top

          U: 250 root 9 0 984 552 552 S 0.0 1.8 0:17.76 nmbd
          D: 759 root 16 0 7056 2016 1548 S 0.0 6.6 0:02.48 nmbd


          U:19965 root 9 0 572 520 520 S 0.0 1.7 3:49.86 syslog-ng
          D: 859 root 15 0 1944 816 672 S 0.0 2.7 0:00.81 syslog-ng

          U:30259 root 9 0 580 240 240 S 0.0 0.8 0:02.36 bash
          D: 532 root 15 0 2700 1500 1204 S 0.0 4.9 0:00.84 bash

          U: 426 root 8 0 284 196 196 S 0.0 0.6 0:03.18 xinetd
          D: 916 root 16 0 2636 840 728 S 0.0 2.7 0:00.09 xinetd

          U: 287 root 8 0 180 136 116 S 0.0 0.4 0:00.62 cron
          D: 493 root 16 0 1876 708 612 S 0.0 2.3 0:00.04 cron

          U: 432 root 9 0 144 88 80 S 0.0 0.3 0:06.98 dropbear
          D: 530 root 16 0 6956 1972 1644 S 0.0 6.4 0:04.10 sshd
          (not fair - dropbear is smaller, but was not in the Debian feed)

          Anybody want a stab at explaining these differences?

          best,

          -- Inge
        • mbanditt
          ... Packages ... people with ... Agreed, disk space is for the hd people more or less irrelevant (myself is using a 300 GB disk ;-) ... Lines ... relevant ...
          Message 4 of 17 , Aug 31, 2005
          • 0 Attachment
            --- In nslu2-linux@yahoogroups.com, Inge Bjørnvall Arnesen
            <i.b.arnesen@f...> wrote:
            >
            > - OpenDebianSlug will probably take up some more disk space.
            Packages
            > include proper docs and so on. I don't think this will matter to
            people with
            > hard drives.

            Agreed, disk space is for the hd people more or less irrelevant
            (myself is using a 300 GB disk ;-)

            > BUT - look
            > at this (some fragments from top on Unslung 5.5 vs. OpenDebianSlug).
            Lines
            > starting with "U" are from Unslung and "D" from OpenDebianSlug. The
            relevant
            > columns are number 5, 6 and 7 counting from the left, being virtual,
            > resident and shared memory respectivly (I believe):
            >
            > U: 1461 bob 9 0 1692 1272 1192 S 0.0 4.2 0:11.61 smbd
            > D: 761 root 16 0 9220 2692 2100 S 0.0 8.8 0:00.57 smbd
            >
            > Note: Unslung is version 2 and Debian version 3. No buffers tweaked.
            >
            > U: 3618 root 16 0 832 792 656 R 1.0 2.6 1:40.11 top
            > D: 2615 root 15 0 2188 920 752 R 3.8 3.0 0:00.08 top
            >
            > U: 250 root 9 0 984 552 552 S 0.0 1.8 0:17.76 nmbd
            > D: 759 root 16 0 7056 2016 1548 S 0.0 6.6 0:02.48 nmbd
            >
            >
            > U:19965 root 9 0 572 520 520 S 0.0 1.7 3:49.86
            syslog-ng
            > D: 859 root 15 0 1944 816 672 S 0.0 2.7 0:00.81
            syslog-ng
            >
            > U:30259 root 9 0 580 240 240 S 0.0 0.8 0:02.36 bash
            > D: 532 root 15 0 2700 1500 1204 S 0.0 4.9 0:00.84 bash
            >
            > U: 426 root 8 0 284 196 196 S 0.0 0.6 0:03.18
            xinetd
            > D: 916 root 16 0 2636 840 728 S 0.0 2.7 0:00.09
            xinetd
            >
            > U: 287 root 8 0 180 136 116 S 0.0 0.4 0:00.62 cron
            > D: 493 root 16 0 1876 708 612 S 0.0 2.3 0:00.04 cron
            >
            > U: 432 root 9 0 144 88 80 S 0.0 0.3 0:06.98
            dropbear
            > D: 530 root 16 0 6956 1972 1644 S 0.0 6.4 0:04.10 sshd
            > (not fair - dropbear is smaller, but was not in the Debian feed)
            >

            Well, these are tremendous differences!!! OpenDebian apps need
            according to these figures 3 to 10 times the memory! I haven't thought
            that the difference would be this big... :(

            And also, look at the cpu% used by the processes. They seem to consume
            in general more cpu time on the DebianSlug compared to the Unslung.
            That's really a pity, it seems. Or are we mistaken?

            Michael
          • Inge Bjørnvall Arnesen
            ... There might be good explanations for this (besides larger lib sizes). I am also uncertain wrt. the top reports. Is this including paged out memory - note
            Message 5 of 17 , Aug 31, 2005
            • 0 Attachment
              > Well, these are tremendous differences!!! OpenDebian apps
              > need according to these figures 3 to 10 times the memory!

              There might be good explanations for this (besides larger lib sizes). I am
              also uncertain wrt. the top reports. Is this including paged out memory -
              note that the Unslung host has been running for 29 days (last power outage
              in Oslo), while the Debian has been up 2.

              > And also, look at the cpu% used by the processes. They
              > seem to consume in general more cpu time on the
              > DebianSlug compared to the Unslung.

              I can't see that - what column? The CPU % says nothing and the amount of CPU
              spent is way larger on Unslung due to the 29 day uptime.


              > That's really a pity,
              > it seems. Or are we mistaken?

              We are probably mistaken - it is more a question of understanding how :-)

              best,

              -- Inge
            • mbanditt
              ... memory - The colums should be a follows: PID USR .. .. VIRT RES SHR U:30259 root 9 0 580 240 240 S 0.0 0.8 0:02.36 bash D: 532 root 15 0 2700 1500
              Message 6 of 17 , Aug 31, 2005
              • 0 Attachment
                --- In nslu2-linux@yahoogroups.com, Inge Bjørnvall Arnesen
                <i.b.arnesen@f...> wrote:
                > I am
                > also uncertain wrt. the top reports. Is this including paged out
                memory -

                The colums should be a follows:

                PID USR .. .. VIRT RES SHR

                U:30259 root 9 0 580 240 240 S 0.0 0.8 0:02.36 bash
                D: 532 root 15 0 2700 1500 1204 S 0.0 4.9 0:00.84 bash

                U: 426 root 8 0 284 196 196 S 0.0 0.6 0:03.18 xinetd
                D: 916 root 16 0 2636 840 728 S 0.0 2.7 0:00.09 xinetd

                U: 287 root 8 0 180 136 116 S 0.0 0.4 0:00.62 cron
                D: 493 root 16 0 1876 708 612 S 0.0 2.3 0:00.04 cron

                As I understand it, the reserved part stays in memory all the time.
                Thus bash seems to reserve 8 times the memory in DebianSlug vs.
                Unslung.


                > I can't see that - what column? The CPU % says nothing and the
                amount of CPU
                > spent is way larger on Unslung due to the 29 day uptime.
                >

                Right, i took the wrong column (%MEM).

                > We are probably mistaken - it is more a question of understanding
                how :-)
                >

                Right, I've just compared my top reading for bash, xinetd and cron on
                OpenSlug and they pretty much resemble those of DebianSlug. So the
                question rather seems to be why you have such low Unslung values?

                Cheers,

                Michael
              • Øyvind Repvik
                ... Debian samba probably has a lot more support compiled in (ldap-type of stuff) Here s the same for OpenSlug: O: 923 root 18 0 5316 1868 1548 S 0.0
                Message 7 of 17 , Aug 31, 2005
                • 0 Attachment
                  Inge Bjørnvall Arnesen wrote:

                  > U: 1461 bob 9 0 1692 1272 1192 S 0.0 4.2 0:11.61 smbd
                  > D: 761 root 16 0 9220 2692 2100 S 0.0 8.8 0:00.57 smbd
                  > U: 250 root 9 0 984 552 552 S 0.0 1.8 0:17.76 nmbd
                  > D: 759 root 16 0 7056 2016 1548 S 0.0 6.6 0:02.48 nmbd
                  > Note: Unslung is version 2 and Debian version 3. No buffers tweaked.
                  Debian samba probably has a lot more support compiled in (ldap-type of
                  stuff)

                  Here's the same for OpenSlug:
                  O: 923 root 18 0 5316 1868 1548 S 0.0 6.1 0:00.00 smbd
                  O: 924 root 16 0 3524 1424 1192 S 0.0 4.6 0:00.19 nmbd


                  > U: 3618 root 16 0 832 792 656 R 1.0 2.6 1:40.11 top
                  > D: 2615 root 15 0 2188 920 752 R 3.8 3.0 0:00.08 top
                  O: 1023 root 16 0 2180 1132 908 R 1.3 3.7 0:00.84 top

                  > U:19965 root 9 0 572 520 520 S 0.0 1.7 3:49.86 syslog-ng
                  > D: 859 root 15 0 1944 816 672 S 0.0 2.7 0:00.81 syslog-ng
                  O: 883 root 15 0 1720 736 580 S 0.0 2.4 0:00.04 syslog-ng

                  > U:30259 root 9 0 580 240 240 S 0.0 0.8 0:02.36 bash
                  > D: 532 root 15 0 2700 1500 1204 S 0.0 4.9 0:00.84 bash
                  O: 1009 root 16 0 2676 1580 1256 S 0.0 5.1 0:00.12 bash

                  > U: 426 root 8 0 284 196 196 S 0.0 0.6 0:03.18 xinetd
                  > D: 916 root 16 0 2636 840 728 S 0.0 2.7 0:00.09 xinetd
                  O: 945 root 18 0 2768 896 760 S 0.0 2.9 0:00.03 xinetd

                  > U: 287 root 8 0 180 136 116 S 0.0 0.4 0:00.62 cron
                  > D: 493 root 16 0 1876 708 612 S 0.0 2.3 0:00.04 cron
                  O: 987 root 16 0 1464 548 480 S 0.0 1.8 0:00.00 cron

                  > U: 432 root 9 0 144 88 80 S 0.0 0.3 0:06.98 dropbear
                  > D: 530 root 16 0 6956 1972 1644 S 0.0 6.4 0:04.10 sshd
                  O: 1005 root 16 0 3636 1792 1464 S 0.0 5.8 0:00.54 sshd

                  > Anybody want a stab at explaining these differences?

                  Which version of the utilities are you running? Are any of these perhaps
                  the busybox version?


                  > best,
                  >
                  > -- Inge
                • Inge Bjørnvall Arnesen
                  Thanks for your numbers, Øyvind. They seem to confirm that Openslug and OpenDebianSlug are close in these respects. ... DebianOpenSlug (which is too long a
                  Message 8 of 17 , Aug 31, 2005
                  • 0 Attachment
                    Thanks for your numbers, Øyvind. They seem to confirm that Openslug and
                    OpenDebianSlug are close in these respects.

                    > > Anybody want a stab at explaining these differences?
                    >
                    > Which version of the utilities are you running? Are any
                    > of these perhaps the busybox version?

                    :-o Good heavens, no. It is procps/psproc "top" on both Unslung and
                    DebianOpenSlug (which is too long a name and will in later emails be called
                    DOS :-D - hmm... maybe BigDebSlug or plain Big Deb).

                    As you seem to understand the impact of these numbers: Could library
                    differences explain these differences? The reason I ask is that the amount
                    of free memory seem to be more or less the same on Unslung (eh, well
                    _slightly_ less) as on DebianOpenSlug when buffers, cache and free RAM is
                    calculated, even though all the applications seem to take up more space on
                    the latter platform.

                    best,

                    - inge
                  • grahame@falvey.net
                    Ok, I m at an impass. I m trying to set up a build environment on OpenSlug 2.5. I have done the following: ipkg install openslug-native mkdir -p ~/slug cd
                    Message 9 of 17 , Aug 31, 2005
                    • 0 Attachment
                      Ok, I'm at an impass.

                      I'm trying to set up a build environment on OpenSlug 2.5. I have done the
                      following:

                      ipkg install openslug-native
                      mkdir -p ~/slug
                      cd ~/slug
                      wget --cache=off http://www.nslu2-linux.org/Makefile
                      make setup
                      make build openslug

                      and I get the following:

                      ------------------------8<------------------------
                      grahame@SLUG:~/slug$ make build-openslug
                      ( cd openslug ; make )
                      make[1]: Entering directory `/home/grahame/slug/openslug'
                      echo "TOPDIR='`pwd`'" >conf/topdir.conf
                      . conf/topdir.conf && test "`pwd`" = "$TOPDIR" || echo "TOPDIR='`pwd`'" >
                      conf/topdir.conf
                      . ./setup-env; exec bitbake "openslug-native"-packages
                      NOTE: Psyco JIT Compiler (http://psyco.sf.net) not available. Install it
                      to increase performance.
                      NOTE: Using cache in '/home/grahame/slug/openslug/tmp/cache'
                      NOTE: Handling BitBake files: | (0001/0011) [ 9 %]ERROR: [Errno 2] No such
                      file or directory:
                      '/home/grahame/slug/openslug/openembedded/packages/openssl/*.bb' while
                      parsing /home/grahame/slug/openslug/openembedded/packages/openssl/*.bb
                      ERROR: [Errno 2] No such file or directory:
                      '/home/grahame/slug/openslug/openembedded/packages/ipkg-utils/*.bb' while
                      parsing /home/grahame/slug/openslug/openembedded/packages/ipkg-utils/*.bb
                      ERROR: [Errno 2] No such file or directory:
                      '/home/grahame/slug/openslug/openembedded/packages/meta/package-index.bb'
                      while parsing
                      /home/grahame/slug/openslug/openembedded/packages/meta/package-index.bb
                      ERROR: [Errno 2] No such file or directory:
                      '/home/grahame/slug/openslug/openembedded/packages/meta/openslug-native-packages.bb'
                      while parsing
                      /home/grahame/slug/openslug/openembedded/packages/meta/openslug-native-packages.bb
                      NOTE: Handling BitBake files: - (0007/0011) [63 %]ERROR: [Errno 2] No such
                      file or directory:
                      '/home/grahame/slug/openslug/openembedded/packages/pcre/*.bb' while
                      parsing /home/grahame/slug/openslug/openembedded/packages/pcre/*.bb
                      NOTE: Parsing finished. 0 cached, 6 parsed, 0 skipped, 0 masked.
                      NOTE: build 200510011501: started

                      OE Build Configuration:
                      TARGET_ARCH = "armeb"
                      TARGET_OS = "linux"
                      MACHINE = "nslu2"
                      DISTRO = "openslug-native"
                      TARGET_FPU = "soft"

                      ERROR: Nothing provides openslug-native-packages
                      make[1]: *** [distro] Error 1
                      make[1]: Leaving directory `/home/grahame/slug/openslug'
                      make: *** [build-openslug] Error 2
                      ------------------------8<------------------------


                      If anyone has any suggestions they would be greatly appreciated.

                      Thanks,
                      Gra
                    • Josh Parsons
                      ... Alignment faults aren t to do with whether a processor is big-endian, but whether it silently corrects misaligned reads (as i386 does). If you ve found a
                      Message 10 of 17 , Aug 31, 2005
                      • 0 Attachment
                        mbanditt wrote:

                        > Furthermore, there is one other question I have. One of the problems
                        > I'm having with OpenSlug is that I cannot get hpoj to work (scanner
                        > support for HP Officejets). hpoj compiles and installs fine, however
                        > the transport component 'ptal-mcld' produces a lot of runtime
                        > alignment errors
                        > and thus simply doesn't work.
                        >
                        > Now, would a DebianSlug help? Or would the DebianSlug also have the
                        > same problems as it is also a BigEndian OS?

                        Alignment faults aren't to do with whether a processor is big-endian,
                        but whether it silently corrects misaligned reads (as i386 does). If
                        you've found a piece of software that requires the processor to do this,
                        then it is not portable and will fail on many systems, big or little endian.

                        I suggest you report this as a bug to the authors of 'ptal-mcld'.

                        --
                        Josh Parsons
                        Philosophy Department
                        1238 Social Sciences and Humanities Bldg.
                        University of California
                        Davis, CA 95616-8673
                        USA

                        Please avoid sending me Word or PowerPoint attachments.
                        See http://www.gnu.org/philosophy/no-word-attachments.html
                      • Jon Pounder
                        ... You ve got me curious - how could a programmer actually cause that ? isn t it up to the compiler to pad to the alignment boundaries when it allocates
                        Message 11 of 17 , Aug 31, 2005
                        • 0 Attachment
                          > Alignment faults aren't to do with whether a processor is big-endian,
                          > but whether it silently corrects misaligned reads (as i386 does). If
                          > you've found a piece of software that requires the processor to do this,
                          > then it is not portable and will fail on many systems, big or little
                          > endian.

                          You've got me curious - how could a programmer actually cause that ? isn't
                          it up to the compiler to pad to the alignment boundaries when it allocates
                          storage locations ? or would it take something like

                          char[n]
                          and then read (word)char[1]

                          to cause the problem ?




                          >
                          > I suggest you report this as a bug to the authors of 'ptal-mcld'.
                          >
                          > --
                          > Josh Parsons
                          > Philosophy Department
                          > 1238 Social Sciences and Humanities Bldg.
                          > University of California
                          > Davis, CA 95616-8673
                          > USA
                          >
                          > Please avoid sending me Word or PowerPoint attachments.
                          > See http://www.gnu.org/philosophy/no-word-attachments.html
                          >
                          >
                          >
                          >
                          > Yahoo! Groups Links
                          >
                          >
                          >
                          >
                          >
                          >
                          >
                          >


                          Jon Pounder

                          _/_/_/ _/ _/ _/ _/_/_/ _/ _/ _/_/_/_/
                          _/ _/_/ _/ _/ _/ _/_/ _/ _/_/
                          _/ _/ _/_/ _/ _/ _/ _/_/ _/
                          _/_/_/ _/ _/ _/_/_/_/ _/_/_/ _/ _/ _/_/_/_/


                          Inline Internet Systems Inc.
                          Thorold, Ontario, Canada

                          Tools to Power Your e-Business Solutions
                          www.inline.net
                          www.ihtml.com
                          www.ihtmlmerchant.com
                          www.opayc.com
                        • Rod Whitby
                          ... It s currently called OpenDebianSlug (BE Debian with OpenSlug bootloader ... hopefully eventually be known as the armeb port of official Debian with an
                          Message 12 of 17 , Aug 31, 2005
                          • 0 Attachment
                            On 9/1/05, Inge Bjørnvall Arnesen <i.b.arnesen@...> wrote:
                            DebianOpenSlug (which is too long a name and will in later emails be called
                            DOS :-D - hmm... maybe BigDebSlug or plain Big Deb).
                             
                            It's currently called OpenDebianSlug (BE Debian with OpenSlug "bootloader" :-), will soon be known as "Debonaras binary-armeb on NSLU2", and will hopefully eventually be known as the armeb port of official Debian with an NSLU2 installer.
                             
                            -- Rod
                          • mbanditt
                            ... big-endian, ... If ... this, ... endian. ... Thanks John, I m still trying to understand what exactly is happening when alignment errors occur. ptal-mlcd
                            Message 13 of 17 , Aug 31, 2005
                            • 0 Attachment
                              --- In nslu2-linux@yahoogroups.com, Josh Parsons <jbparsons@u...>
                              wrote:
                              >
                              > Alignment faults aren't to do with whether a processor is
                              big-endian,
                              > but whether it silently corrects misaligned reads (as i386 does).
                              If
                              > you've found a piece of software that requires the processor to do
                              this,
                              > then it is not portable and will fail on many systems, big or little
                              endian.
                              >
                              > I suggest you report this as a bug to the authors of 'ptal-mcld'.
                              >
                              > --
                              > Josh Parsons
                              > Philosophy Department
                              > 1238 Social Sciences and Humanities Bldg.
                              > University of California
                              > Davis, CA 95616-8673
                              > USA

                              Thanks John, I'm still trying to understand what exactly is happening
                              when alignment errors occur.

                              'ptal-mlcd' is the transport component of the official hpoj (HP
                              officejet) driver (hpoj.sf.net). It works well on my desktop PC.

                              Native compilation and installation of the hpoj driver works on the
                              slug, however ptal-mlcd is not able to communicate with the printer
                              (though it is connected and one can print via cups using the raw
                              printer driver). The syslog shows hundreds of alignment errors
                              happening in ptal-mlcd. With "echo 3 > /proc/cpu/alignment" (warn &
                              fix), there are still some errors and no connection is possible. The
                              syslog looks like this:

                              Aug 30 13:24:45 (none) lpr.notice ptal-mlcd: SYSLOG at
                              /public/share/sources/hpo
                              j-0.91/mlcd/ExMgr.h:646, dev=<mlc:usb:probe@/dev/usb/lp0>, pid=2312,
                              e=25, t=112
                              5401085 ptal-mlcd successfully activated, mode=1284.4.
                              Aug 30 13:24:45 (none) user.warn kernel: Alignment trap: ptal-mlcd
                              (2312) PC=0x0
                              0028168 Instr=0xe5813044 Address=0x00049df2 FSR 0x813
                              Aug 30 13:24:45 (none) user.warn kernel: Alignment trap: ptal-mlcd
                              (2312) PC=0x0
                              00287e4 Instr=0xe5953044 Address=0x00049df2 FSR 0x013
                              Aug 30 13:24:45 (none) user.warn kernel: Alignment trap: ptal-mlcd
                              (2312) PC=0x0
                              0028168 Instr=0xe5813044 Address=0x00049df2 FSR 0x813
                              Aug 30 13:24:45 (none) user.warn kernel: Alignment trap: ptal-mlcd
                              (2312) PC=0x0
                              00287e4 Instr=0xe5953044 Address=0x00049df2 FSR 0x013
                              Aug 30 13:24:45 (none) user.warn kernel: Alignment trap: ptal-mlcd
                              (2312) PC=0x0
                              0028168 Instr=0xe5813044 Address=0x00049df2 FSR 0x813
                              Aug 30 13:24:45 (none) user.warn kernel: Alignment trap: ptal-mlcd
                              (2312) PC=0x0
                              00287e4 Instr=0xe5953044 Address=0x00049df2 FSR 0x013
                              A

                              The software hpoj is a well established driver, being the main driver
                              software for nearly all HP printers (only been replaced by a newer
                              software design hplip, which, however, still has some problems with HP
                              Officejets).

                              So, I'm not sure, how to proceed. If you're right, it should be best
                              to contact HP (however, I'm not sure, whether they are able to
                              reproduce the error as they certainly don't have a slug). I'll post to
                              their mailing list. Let's see what happens...

                              Cheers,

                              Michael
                            • dyoung8888
                              ... have a look at http://groups.yahoo.com/group/nslu2-linux/message/8122
                              Message 14 of 17 , Aug 31, 2005
                              • 0 Attachment
                                >
                                > You've got me curious - how could a programmer actually cause that ? isn't
                                > it up to the compiler to pad to the alignment boundaries when it allocates
                                > storage locations ? or would it take something like
                                >
                                > char[n]
                                > and then read (word)char[1]
                                >
                                > to cause the problem ?

                                have a look at http://groups.yahoo.com/group/nslu2-linux/message/8122
                              • Josh Parsons
                                ... As you ve guessed, casting between pointers to types with different alignment (e.g.) (char*) to (int*) is the most usual cause. You can also instruct a
                                Message 15 of 17 , Aug 31, 2005
                                • 0 Attachment
                                  Jon Pounder wrote:

                                  > You've got me curious - how could a programmer actually cause that ? isn't
                                  > it up to the compiler to pad to the alignment boundaries when it allocates
                                  > storage locations ? or would it take something like...

                                  As you've guessed, casting between pointers to types with different
                                  alignment (e.g.) (char*) to (int*) is the most usual cause. You can
                                  also instruct a compiler to ignore usual alignment constraints (for
                                  example with gcc's "packed" type attribute), but it's hard to do that
                                  without being made aware that you're doing something that will cause
                                  portability problems (to compilers other than gcc for example).

                                  mbanditt wrote:

                                  > 'ptal-mlcd' is the transport component of the official hpoj (HP
                                  > officejet) driver (hpoj.sf.net). It works well on my desktop PC.
                                  >
                                  > Native compilation and installation of the hpoj driver works on the
                                  > slug, however ptal-mlcd is not able to communicate with the printer
                                  > (though it is connected and one can print via cups using the raw
                                  > printer driver). The syslog shows hundreds of alignment errors
                                  > happening in ptal-mlcd. With "echo 3 > /proc/cpu/alignment" (warn &
                                  > fix), there are still some errors and no connection is possible. The
                                  > syslog looks like this:

                                  The best way to start is to build a copy of the ptal-mlcd binary (or any
                                  other hpoj component that causes trouble) with debugging turned on with
                                  "-g" . Then run it under gdb with /proc/cpu/alignment set to 5. When
                                  an alignment fault occurs, gdb will report the line of code which
                                  provoked it. Then you can look at the source to see what might be
                                  causing the problem (or just report the details to this list if you
                                  can't tell what the problem or can't understand the sources to hpoj).

                                  --
                                  Josh Parsons
                                  Philosophy Department
                                  1238 Social Sciences and Humanities Bldg.
                                  University of California
                                  Davis, CA 95616-8673
                                  USA

                                  Please avoid sending me Word or PowerPoint attachments.
                                  See http://www.gnu.org/philosophy/no-word-attachments.html
                                • John Bowler
                                  From: dyoung8888 ... isn t ... allocates ... Correct - the compiler gets it right, the programmer has to fool the compiler somehow, the above is, indeed, the
                                  Message 16 of 17 , Sep 1 1:22 PM
                                  • 0 Attachment
                                    From: dyoung8888
                                    >From: Jon Pounder
                                    >> You've got me curious - how could a programmer actually cause that ?
                                    isn't
                                    >> it up to the compiler to pad to the alignment boundaries when it
                                    allocates
                                    >> storage locations ? or would it take something like
                                    >>
                                    >> char[n]
                                    >> and then read (word)char[1]

                                    Correct - the compiler gets it right, the programmer has to fool the
                                    compiler somehow, the above is, indeed, the normal method.

                                    >have a look at http://groups.yahoo.com/group/nslu2-linux/message/8122

                                    Or go back to around the start of the year when it was discussed at length.
                                    The result was written up in this wiki page:

                                    http://www.nslu2-linux.org/wiki/Info/Alignment

                                    The only common C programming technique which will cause a mis-aligned
                                    access is a cast - strictly what is called reinterpret_cast in C++ (i.e. a
                                    static_cast is always safe, as are const_cast and dynamic_cast). The
                                    trivial test case (in C++):

                                    #include <iostream>
                                    #include <iomanip>
                                    int main(void) {
                                    char buffer[8];
                                    for (int i(0); i<8; ++i)
                                    buffer[i] = i;
                                    int *ptr = reinterpret_cast<int*>(buffer+1);
                                    std::cout << std::hex << *ptr << std::endl;
                                    return 0;
                                    }

                                    Which will cause an alignment fault on ARM and, instead of outputing (big
                                    endian) 01020304 will probably output 01020300

                                    John Bowler <jbowler@...>
                                  • mbanditt
                                    ... any ... with ... When ... hpoj). ... Thanks Josh and also John for the great explanation on the wiki! I posted a report about the problem on the hpoj-devel
                                    Message 17 of 17 , Sep 2 8:38 AM
                                    • 0 Attachment
                                      --- In nslu2-linux@yahoogroups.com, Josh Parsons <jbparsons@u...>
                                      wrote:
                                      > The best way to start is to build a copy of the ptal-mlcd binary (or
                                      any
                                      > other hpoj component that causes trouble) with debugging turned on
                                      with
                                      > "-g" . Then run it under gdb with /proc/cpu/alignment set to 5.
                                      When
                                      > an alignment fault occurs, gdb will report the line of code which
                                      > provoked it. Then you can look at the source to see what might be
                                      > causing the problem (or just report the details to this list if you
                                      > can't tell what the problem or can't understand the sources to
                                      hpoj).
                                      >

                                      Thanks Josh and also John for the great explanation on the wiki!

                                      I posted a report about the problem on the hpoj-devel mailing list,
                                      however, it seems that this project is more or less dead as nearly no
                                      new posts are on the list and also no answer yet.

                                      I tried to compile it with the debugging option, but I`m afraid I'm
                                      missing to much knowledge as to get this working. And also, I guess, I
                                      wouldn't be able to interpret the results. Pity...

                                      Then I tried to compile the successor project hplip (hpinkjet.sf.net),
                                      although this driver still has some problems with scanning via an ADF.

                                      But here I'm already experiencing too many obstacles to even get it
                                      compiled. Some of them I have overcome, but at the moment I'm stopped
                                      by this problem:

                                      /usr/lib/gcc/armeb-linux/3.4.4/../../../../armeb-linux/bin/ld: ERROR:
                                      /usr/lib/gcc/armeb-linux/3.4.4/../../../libcups.so uses hardware FP,
                                      whereas build/lib.linux-armv5teb-2.4/cupsext.so uses software FP
                                      /usr/lib/gcc/armeb-linux/3.4.4/../../../../armeb-linux/bin/ld: failed
                                      to merge target specific data of file
                                      /usr/lib/gcc/armeb-linux/3.4.4/../../../libcups.so

                                      The libcups.so comes from the unslung cups package. The cupsext.so
                                      seems to be part of the hp driver.

                                      Maybe it's better I wait until somebody with more experience tries to
                                      get this working...

                                      Cheers,

                                      Michael
                                    Your message has been successfully submitted and would be delivered to recipients shortly.