Opened 3 years ago

Closed 2 years ago

Last modified 2 years ago

#11845 closed defect (fixed)

Firmware q2f10: Hardware Test: USB: on second attempt after a device is removed, does not detect port in use correctly

Reported by: earias Owned by: Quozl
Priority: high Milestone:
Component: ofw - open firmware Version: Development firmware
Keywords: Cc: reuben, wmb@…
Blocked By: Blocking:
Deployments affected: Action Needed: no action
Verified: no

Description

The older versions, If I connect pendrive USB in some port, the system shows: "Hub port <number> in use" but, version q2f10 does not detect the port in use.

Change History (28)

comment:1 Changed 3 years ago by Quozl

  • Action Needed changed from never set to reproduce
  • Component changed from not assigned to ofw - open firmware
  • Milestone Not Triaged deleted
  • Owner changed from quozl@… to Quozl
  • Status changed from new to assigned
  • Version changed from not specified to Development firmware

Thank you for your problem report.

I have tested Q2E48 and Q2F10 with and without a USB drive attached, with a USB drive attached before boot and after boot. In each case, test /usb gave correct output, identifying the port in use.

Please advise your older firmware version, whether the USB drive was attached before or after boot, and the make and model of your USB drive?

comment:2 Changed 3 years ago by earias

Runs ok only if you connect USB drive before boot. On Q2E45 and Q2F10.

comment:3 Changed 3 years ago by Quozl

  • Action Needed changed from reproduce to no action

I'm was still waiting for details of your USB drive.

I've tested here, using test /usb, and it works correctly regardless of which port is used, and regardless of whether the USB drive is connected before boot or not.

However, if a USB drive is removed after test /usb, and then test /usb is repeated, the port in use is not detected. This only occurs on XO-1. On XO-1.5 the test output is as expected. On XO-1.75 with test /usb/hub the test output is as expected. So on XO-1 the test output is inconsistent when a USB drive has been removed after a previous test. I don't think this needs to be fixed.

I see no difference at all between Q2E45 and Q2F10 as far as test /usb is concerned, so this is not a regression.

I don't know why you think this is a problem for you. You haven't explained the impact. I speculate that you wish to test laptops after repair. On that assumption, I suggest that you use the extended diagnostics when testing USB ports. Like this:

ok true to diag-switch?
ok test /usb
USB 2.0 port 0  in use                          <-- this is the wireless device
Please connect a device to USB port 1           <-- the right hand lower port
Device connected - probing ... scsi disk Done
Please connect a device to USB port 2           <-- the right hand upper port
Device connected - probing ... scsi disk Done
Please connect a device to USB port 3           <-- the left hand port
Device connected - probing ... scsi disk Done
ok 

The port test order is different on XO-1.5.

May we close this ticket now?

comment:4 Changed 3 years ago by earias

Yes, you can close

comment:5 Changed 3 years ago by Quozl

  • Resolution set to worksforme
  • Status changed from assigned to closed

Thanks.

comment:6 Changed 2 years ago by reuben

  • Cc reuben added
  • Resolution worksforme deleted
  • Status changed from closed to reopened

I do not think this was fixed. Let's reopen and discuss keeping in mind deployments using security cannot access OFW to issue test commands.

comment:7 Changed 2 years ago by reuben

  • Cc wmb added

Test using Q2E41:

-The USB port in use is not detected unless it was inserted before boot.

Test using q2f11:

-You can boot the xo insert USB and run test /usb and the correct port is found. However if you then switch to another port and rerun the test the port is not correctly identified.

The feeling from the team is that the USB ports should be enumerated before test /usb is run.

comment:8 Changed 2 years ago by reuben

Any progress here?

comment:9 follow-up: Changed 2 years ago by Quozl

  • Action Needed changed from no action to diagnose
  • Summary changed from Firmware q2f10: Hardware Test: USB: does not detect the port in use. to Firmware q2f10: Hardware Test: USB: on second attempt after a device is removed, does not detect port in use correctly

Is the problem: the port in use display is incorrect if a device is moved from one port to another between successive USB tests?

comment:10 Changed 2 years ago by Quozl

  • Action Needed changed from diagnose to design
  • Cc wmb@… added; wmb removed

comment:11 in reply to: ↑ 9 Changed 2 years ago by reuben

Replying to Quozl:

Is the problem: the port in use display is incorrect if a device is moved from one port to another between successive USB tests?

Yes. Have you attempted to reproduce? I believe the issue becomes clear if you try to reproduce.

comment:12 Changed 2 years ago by Quozl

Yes, I have reproduced, nine days ago in this ticket, and yesterday, but that didn't make the issue clear, because I saw conflicting information. I needed your confirmation.

Are the testers hoping to use this port in use indicator as evidence that the port is working? If so, shouldn't we change it to a test that actually checks this, with a probe?

comment:13 Changed 2 years ago by reuben

I am confused -- what is the point of test if it is not to test if the port is working...In other words, yes..they want to test all of the ports are working. I think they are looking for something similar to "final" at Quanta were the operator passes the USB by each port before the test proceeds; however, I am not sure that is the best case for all general testall usage.. What do you propose?

comment:14 follow-ups: Changed 2 years ago by Quozl

Summary: I propose:

  • removing the fisheye pattern feature, as it is of no use to deployments or laptop owners, and has caused misinformation,
  • probing each port and reporting the type of device found.

This will allow a deployment to begin testing USB ports, provided they have at least one USB device available in the repair location. It will not require that devices be fed to it though.

Background detail:

As far as the USB host is concerned, the current test does test the host.

As far as the USB ports are concerned, the current test does not test them. The test has the following attributes:

  • it does not check that a port is working,
  • it provides a test signal for an electrical check, as part of design verification,
  • it requires the use of an external instrument,
  • the result must be determined by observation of the instrument,
  • the firmware part of the test cannot determine, alone, whether the test is successful,
  • the firmware part of the test avoids a port if it is in use, so that the test signal is not sent to any device.

It appears that this has led to your deployment using the test as evidence that a port is working. We apologise for letting you think that.

Still, that the test does not properly detect which ports are in use after the first attempt, may be leading to the test signal being sent unnecessarily to USB devices. I plan to fix that too.

comment:15 in reply to: ↑ 14 Changed 2 years ago by reuben

Replying to Quozl:

Summary: I propose:

  • removing the fisheye pattern feature, as it is of no use to deployments or laptop owners, and has caused misinformation,

Instead of removing:

*Prompt user to insert USB before testing testing the port
*If no USB is inserted in 5(?) seconds begin fisheye pattern and allow automated tests to continue
*If User inserts USB launch actual port testing

This has the benefit of not halting automated testing unless the user know they want to actually test port operation.

  • probing each port and reporting the type of device found.

This will allow a deployment to begin testing USB ports, provided they have at least one USB device available in the repair location. It will not require that devices be fed to it though.

Background detail:

As far as the USB host is concerned, the current test does test the host.

As far as the USB ports are concerned, the current test does not test them. The test has the following attributes:

  • it does not check that a port is working,
  • it provides a test signal for an electrical check, as part of design verification,
  • it requires the use of an external instrument,
  • the result must be determined by observation of the instrument,
  • the firmware part of the test cannot determine, alone, whether the test is successful,
  • the firmware part of the test avoids a port if it is in use, so that the test signal is not sent to any device.

It appears that this has led to your deployment using the test as evidence that a port is working. We apologise for letting you think that.

Still, that the test does not properly detect which ports are in use after the first attempt, may be leading to the test signal being sent unnecessarily to USB devices. I plan to fix that too.

comment:16 follow-up: Changed 2 years ago by Quozl

Why do you want the fisheye pattern test? The fisheye pattern test on XO-1 hangs each port it acts on, which is one of the reasons why this ticket was raised. There was an obvious misunderstanding about what it does. It is better to remove the test than allow misunderstanding to continue.

Automated testing is halted by the touchpad test on all models, and by the lid and ebook switch tests on XO-1.5 and XO-1.75. I don't think we need more halts or delays. Wouldn't it be more appropriate to simply report what devices are present? The user could then choose USB testing from the menu after the automatic tests are complete.

comment:17 in reply to: ↑ 16 Changed 2 years ago by reuben

Replying to Quozl:

Why do you want the fisheye pattern test? The fisheye pattern test on XO-1 hangs each port it acts on, which is one of the reasons why this ticket was raised. There was an obvious misunderstanding about what it does. It is better to remove the test than allow misunderstanding to continue.

Automated testing is halted by the touchpad test on all models, and by the lid and ebook switch tests on XO-1.5 and XO-1.75.

Valid point.

I don't think we need more halts or delays.

Agreed.

Wouldn't it be more appropriate to simply report what devices are present?

Yes, I agree now.

The user could then choose USB testing from the menu after the automatic tests are complete.

comment:18 in reply to: ↑ 14 Changed 2 years ago by Quozl

  • Action Needed changed from design to test in build

Replying to Quozl:

  • removing the fisheye pattern feature, as it is of no use to deployments or laptop owners, and has caused misinformation,
  • probing each port [...]

Completed in svn 3004. The test now probes each USB port on XO-1 and XO-1.5, and reports "Done" or "Failed". The fisheye test is skipped but remains available for manual use from the ok prompt. A test build is available at http://dev.laptop.org/~quozl/q2f11ji.rom

Replying to Quozl:

[...] and reporting the type of device found.

Not implemented. This only occurs as a side-effect of device node creation, so does not repeat if the test repeats. I didn't understand this at the time I wrote it.

comment:19 Changed 2 years ago by Quozl

Any update? I'd like to know this is fixed before I make the next release.

comment:20 Changed 2 years ago by earias

We have tested and runs ok.

comment:21 Changed 2 years ago by Quozl

  • Action Needed changed from test in build to add to release

comment:22 Changed 2 years ago by Quozl

  • Action Needed changed from add to release to no action
  • Resolution set to fixed
  • Status changed from reopened to closed

Is in Q2F12.

comment:23 Changed 2 years ago by Quozl

Is in Q3C07.

comment:24 Changed 2 years ago by Quozl

Is in Q4D17.

comment:25 Changed 2 years ago by wmb@…

svn 3444 modifies the selftest logic so that devices that are already present prior to selftest execution are not reprobed, but rather their identification information is displayed. Reprobing is bad because it can cause devices to become unresponsive due to reassignment of device IDs; this is especially problematic for built-in hubs. See also #12254.

comment:26 Changed 2 years ago by Quozl

Retested in local build q2f13ji, works to my satisfaction.

If others would like to test, a test build is available here:
http://dev.laptop.org/~quozl/q2f13ji.rom

comment:27 Changed 2 years ago by Quozl

Is in Q4D25.

comment:28 Changed 2 years ago by Quozl

Is in Q7B08.

Note: See TracTickets for help on using tickets.