Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
lava
lava
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 111
    • Issues 111
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 29
    • Merge Requests 29
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • lava
  • lavalava
  • Merge Requests
  • !1117

Closed
Opened Apr 14, 2020 by Larry Shen@atlineContributor
  • Report abuse
Report abuse

Check out, review, and merge locally

Step 1. Fetch and check out the branch for this merge request

git fetch "https://git.lavasoftware.org/atline/lava.git" "feature/serial_reconnect"
git checkout -b "atline/lava-feature/serial_reconnect" FETCH_HEAD

Step 2. Review the changes locally

Step 3. Merge the branch and fix any conflicts that come up

git fetch origin
git checkout "master"
git merge --no-ff "atline/lava-feature/serial_reconnect"

Step 4. Push the result of the merge to GitLab

git push origin "master"

Note that pushing to GitLab requires write access to this repository.

Tip: You can also checkout merge requests locally by following these guidelines.

Reconnect serial for connection when retry.

  • Overview 15
  • Commits 1
  • Pipelines 3
  • Changes 2

In our lab, we found some boards will disconnect from usb hub, especially for some imx6 ard boards.

This all happens when lava try to connect to the device, pdu reset, and then begin to operate the uboot command line, reported below dmesg on lava slave:

[Mon Apr 13 10:21:42 2020] ftdi_sio ttyUSB8: usb_serial_generic_read_bulk_callback - urb stopped: -32
[Mon Apr 13 10:21:42 2020] usb 2-1.6.3-port2: disabled by hub (EMI?), re-enabling...
[Mon Apr 13 10:21:42 2020] ftdi_sio ttyUSB8: FTDI USB Serial Device converter now disconnected from ttyUSB8
[Mon Apr 13 10:21:43 2020] usb 2-1.6.3.2: FTDI USB Serial Device converter now attached to ttyUSB8

Then, when operate uboot, lava reported Connection closed. Although we define retry, but lava reported Already connected which then not try to open the serial connection any more.

You can see the serial ttyUSB8 just leave for about 1 second, if reconnect, everything will be ok. In fact, after this job incomplete, if run a new job again quickly which open a new connection, you will see it's ok.

So, we propose this MR to open serial again if serial leaves a while, not let lava to maintain a invalid connection there.

Log without serial reconnect when retry: job_without_reconnect.log

Log with serial reconnect when retry (applied this patch): job_with_reconnect.log

I know this is an issue maybe just existed in our product chip, but let lava's connection always maintain a valid raw serial link sounds reasonable?

Assignee
Assign to
2020.06
Milestone
2020.06 (Past due)
Assign milestone
Time tracking
Reference: lava/lava!1117
Source branch: feature/serial_reconnect