Announcement

Collapse
No announcement yet.

BIT Linux parallel port issue

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • BIT Linux parallel port issue

    Hello,

    We are developing a new IC about parallel port function.
    We can read/write via /dev/lp0, but when we want to try loopback with BIT in Linux 3.3 build1001 . It'll crash and add log in dmesg with following

    traps: bit_gui_x32[2526] general protection ip:807d2f7 sp:a92ec040 error:0 in bit_gui_x32[8048000+222000]
    traps: bit_gui_x32[2594] general protection ip:807d2f7 sp:a92af040 error:0 in bit_gui_x32[8048000+222000]
    traps: bit_gui_x32[2676] general protection ip:807d2f7 sp:a87ff040 error:0 in bit_gui_x32[8048000+222000]
    traps: bit_gui_x32[2772] general protection ip:807d2f7 sp:a926f040 error:0 in bit_gui_x32[8048000+222000]
    traps: bit_gui_x32[2876] general protection ip:807d2f7 sp:a9079040 error:0 in bit_gui_x32[8048000+222000]

    Also could you provide me the paralle port self test flow??

    Thanks

  • #2
    It looks like the crash has occurred around initialising the parallel port, in particular near where we use the base address of the port for the first time.

    Could you please launch BurnInTest with the command line parameter -d, reproduce the crash and send us a copy of the debug.log file that is created.

    Comment


    • #3
      Originally posted by Tim (PassMark) View Post
      It looks like the crash has occurred around initialising the parallel port, in particular near where we use the base address of the port for the first time.

      Could you please launch BurnInTest with the command line parameter -d, reproduce the crash and send us a copy of the debug.log file that is created.

      Hi Tim,

      I had uploaded the log to GoogleDriver, Please use the following link.
      https://drive.google.com/file/d/0B8v...ew?usp=sharing

      The IO address of this device is using D062h (53346) with SPP mode.
      D062h + 0: data
      D062h + 1: status
      D062h + 2: control

      I can test for this if you need try with debug version BIT.

      Thanks

      Comment


      • #4
        Thanks, we believe the issue was that BurnInTest was not correctly getting permission to access this base address before attempting to read from it.

        Could you please try this build out and let us know how it goes.

        Comment


        • #5
          Originally posted by Tim (PassMark) View Post
          Thanks, we believe the issue was that BurnInTest was not correctly getting permission to access this base address before attempting to read from it.

          Could you please try this build out and let us know how it goes.

          Hi Tim,

          This build works good. I can burnin with our new PCIE-to-LPT device.

          I had some question, The BIT seems to get /dev/lp[x] io address
          and direct write data and read status from IO ports. It's ok on legacy
          & PCI devices. But if the device is implements with USB-to-LPT
          (e.g., http://www.asix.com.tw/products.php?...4;109&PLine=74 ), the BIT will failed.

          IMO, Could you survey to change raw access from IO port to /dev/parport[x] access? (e.g., http://yyao.ca/projects/ParallelPortLinux/). It's more portable and widely support for a lot device.

          Thanks

          Comment


          • #6
            We'll look into adding the /dev/parportX entries to the test configuration list for selection as well.

            Comment

            Working...
            X