Ticket #11845 (closed defect: fixed)

Opened 2 years ago

Last modified 17 months ago

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@…
Action Needed: no action Verified: no
Deployments affected: Blocked By:
Blocking:

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

  Changed 2 years ago by Quozl

  • status changed from new to assigned
  • next_action changed from never set to reproduce
  • component changed from not assigned to ofw - open firmware
  • version changed from not specified to Development firmware
  • milestone deleted
  • owner changed from quozl@… to Quozl

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?

  Changed 2 years ago by earias

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

  Changed 2 years ago by Quozl

  • next_action 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?

  Changed 2 years ago by earias

Yes, you can close

  Changed 2 years ago by Quozl

  • status changed from assigned to closed
  • resolution set to worksforme

Thanks.

  Changed 2 years ago by reuben

  • cc reuben added
  • status changed from closed to reopened
  • resolution deleted

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.

  Changed 23 months 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.

  Changed 23 months ago by reuben

Any progress here?

follow-up: ↓ 11   Changed 23 months ago by Quozl

  • next_action 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?

  Changed 23 months ago by Quozl

  • cc wmb@… added; wmb removed
  • next_action changed from diagnose to design

in reply to: ↑ 9   Changed 23 months 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.

  Changed 23 months 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?

  Changed 23 months 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?

follow-ups: ↓ 15 ↓ 18   Changed 23 months 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.

in reply to: ↑ 14   Changed 23 months 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.

follow-up: ↓ 17   Changed 23 months 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.

in reply to: ↑ 16   Changed 23 months 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.

in reply to: ↑ 14   Changed 23 months ago by Quozl

  • next_action 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.

  Changed 23 months ago by Quozl

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

  Changed 23 months ago by earias

We have tested and runs ok.

  Changed 23 months ago by Quozl

  • next_action changed from test in build to add to release

  Changed 23 months ago by Quozl

  • status changed from reopened to closed
  • next_action changed from add to release to no action
  • resolution set to fixed

Is in Q2F12.

  Changed 23 months ago by Quozl

Is in Q3C07.

  Changed 23 months ago by Quozl

Is in Q4D17.

  Changed 17 months 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.

  Changed 17 months 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

  Changed 17 months ago by Quozl

Is in Q4D25.

  Changed 17 months ago by Quozl

Is in Q7B08.

Note: See TracTickets for help on using tickets.