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

[earias]

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.

[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?

[earias]

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

[Quozl]

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?

[earias]

Yes, you can close

[Quozl]

Thanks.

[reuben]

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.

[reuben]

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.

[reuben]

Any progress here?

[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?

[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.

[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?

[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?

[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.

[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.

[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.

[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.

[Quozl]

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.

[Quozl]

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

[earias]

We have tested and runs ok.

[Quozl]

Is in Q2F12.

[Quozl]

Is in Q3C07.

[Quozl]

Is in Q4D17.

[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.

[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

[Quozl]

Is in Q4D25.

[Quozl]

Is in Q7B08.