XO-1.75 Open Firmware reports Data Abort during Linux kernel load if a PL2303 USB serial adapter is present

[Quozl]

Fixed by svn 2983.

On XO-1.75, ?usb-keyboard searches for a USB serial adapter /usb/serial and binds it to the console multiplexor. This results in a Data Abort during boot when the multiplexor is torn down without the device being closed.

XO-1 and XO-1.5 are unaffected. /usb/serial is an inadequate device specification, because the probed device starts with /pci.

ftrace:

$find-next        Called from $find-word                at  fda0a5a8
$find-word        Called from $call-self                at  fda2d88c
   Catch frame - SP: fdbfbea0   my-self: fda07bb8   handler: fdbfb690 
catch             Called from ?close                    at  fda2ddd8
?close            Called from close-parents             at  fda2de74
close-parents     Called from close-dev                 at  fda2dec0
 fd9fff90
close-dev         Called from close                     at  fda899ec
execute           Called from $call-self                at  fda2d898
   Catch frame - SP: fdbfbef4   my-self: fd9fff90   handler: fdbfb690 
catch             Called from ?close                    at  fda2ddd8
?close            Called from close-parents             at  fda2de74
close-parents     Called from close-dev                 at  fda2dec0
        0
close-dev         Called from teardown-mux-io           at  fdac7854
teardown-mux-io   Called from quiesce                   at  fdac7878
quiesce           Called from linux-hook-freeze         at  fdaca298

[Quozl]

Symptom does not occur with boot of os883.zd4 with 'X' game key held down.

[pgf]

this weekend i saw a similar symptom with a USB GPS dongle. right now i'm getting "Data Abort", but what i was getting before was continuous "Keyboard Interrupt" indications from OFW. product also identifies as a Prolific USB-Serial controller (067b:2303). the GPS dongle may have been sending data at the time, likely at the wrong baud rate.

(reporting, in case the "Keyboard Interrupt" symptom implies a second issue.)

[Quozl]

Thanks. 067b:2302 is indeed in the list of recognised devices. It would be bound as a keyboard and be visible in the output of the .mux command. If the "keyboard" transmitted the break key code or reported a serial break condition, then Keyboard interrupt is expected. Unlike XO-1 and XO-1.5, the XO-1.75 build allows multiple keyboard interrupt events.

[pgf]

i can't tell whether you're agreeing that it is, or isn't, a bug. it seems that this behavior won't be fixed by the commit above, right?

the mismatched baud rate could certainly cause a serial break from the device, and therefore keep the system from booting. should i trac it separately?

[Quozl]

Before the fix in this ticket, you would see the Data Abort symptom you described. After the fix, you would not. The Keyboard interrupt thing might or might not be fixed, I'm not sure. I can't test. Here's a build you can test with: http://dev.laptop.org/~quozl/q4d14jb.rom

[pgf]

i've reproduced, but it's not the bug i thought it was.

while experiencing what was no doubt the Data Abort symptom over the weekend, i rebooted the machine with serial attached, and hit ESC for an ok prompt. at that point i started getting the Keyboard Interrupt loop. since i had just been having trouble booting, and was now seeing a loop at the OFW commandline, i mistakenly thought i'd found the cause of the boot problem.

this seems like a regression. can you remind me of the use case for the new "USB serial access to OFW" feature?

(the other symptom, Data Abort, is gone with q4d14jb.rom.)

[Quozl]

Replying to pgf:

i've reproduced, but it's not the bug i thought it was. while experiencing what was no doubt the Data Abort symptom over the weekend, i rebooted the machine with serial attached, and hit ESC for an ok prompt. at that point i started getting the Keyboard Interrupt loop. since i had just been having trouble booting, and was now seeing a loop at the OFW commandline, i mistakenly thought i'd found the cause of the boot problem. this seems like a regression.

Agreed. Raised #11887 to investigate, since it is a separate problem.

can you remind me of the use case for the new "USB serial access to OFW" feature?

This is not a new feature, it has been there since the VIA demo board support in the biosload build (svn 1152), and XO-1.5 (svn 1154). It was backported to XO-1 as part of the fixes for #10042 and #10043 in svn 1758. It was since broken on XO-1 and XO-1.5 by device naming changes, where USB is placed under PCI. XO-1.75 exposed it because USB devices are now higher up the device hierarchy.

I'm not aware of a use case, but I could speculate. It allows access to Open Firmware on a unit where the keyboard has failed, and a USB keyboard is not available, but a USB serial device is available. Perhaps it is no longer required, in which case #11887 can be closed by removing the code.

If it is to remain, then either an alias or a fix to the device path is needed.

[Quozl]

Mitch has agreed we can remove the USB serial keyboard support from all models.

[Quozl]

Fixed in svn 2985.

[Quozl]

Released in Q4D15 and is in os12.

[Quozl]

Tested Q4D15 is present, automatic upgrade from Q4D14 occurs, closing.

[carrott]

Confirmed that XO-1.75 12.1.0 os12 does not hang during boot with a pl2303 serial port connected.