On Mon, Dec 21, 2015 at 06:44:18PM +0000, edward wandasiewicz wrote:
With 47-g977a7d4, we get
- YES - we get no duplicate of the Philips, and get just one of each
appear in the boot list, Mushkin & Philips
- NO - we sometimes get just the Mushkin only - no Philips detected -
with both devices plugged in, about 1 in 10 cold boot starts - both plugged in USB 3 port and both plugged in Type C port
The 2 Type C cables used, are those from the Google Play Store, for the record.
cbmem attached for each.
It looks like in both of the failure logs that the super/high confusion delayed the usb3 connection notification past the time SeaBIOS was looking for connection notifications. I suspect you could get around this by increasing "etc/usb-time-sigatt". (For example, by adding "$CBFSTOOL $CBFSFILE add-int -i 300 -n etc/usb-time-sigatt" to the "Other settings" section of the chrome image building script I previously sent.) This "secondary failure" after patch 47 is one of the reasons I'm not sure how to really fix the dup drive issue.
-Kevin
FYI, the current testing branch (commit 977a7d4) has issues booting Windows 10 via USB / Windows installer media on a Haswell ChromeBox (XHCI only), locks up on the Windows logo. Tag 1.9.0 (commit 01a84be) has no such issues. Will re-test with upstream master and report back
On 12/21/2015 1:08 PM, Kevin O'Connor wrote:
On Mon, Dec 21, 2015 at 06:44:18PM +0000, edward wandasiewicz wrote:
With 47-g977a7d4, we get
- YES - we get no duplicate of the Philips, and get just one of each
appear in the boot list, Mushkin & Philips
- NO - we sometimes get just the Mushkin only - no Philips detected -
with both devices plugged in, about 1 in 10 cold boot starts - both plugged in USB 3 port and both plugged in Type C port
The 2 Type C cables used, are those from the Google Play Store, for the record.
cbmem attached for each.
It looks like in both of the failure logs that the super/high confusion delayed the usb3 connection notification past the time SeaBIOS was looking for connection notifications. I suspect you could get around this by increasing "etc/usb-time-sigatt". (For example, by adding "$CBFSTOOL $CBFSFILE add-int -i 300 -n etc/usb-time-sigatt" to the "Other settings" section of the chrome image building script I previously sent.) This "secondary failure" after patch 47 is one of the reasons I'm not sure how to really fix the dup drive issue.
-Kevin
SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
On Mon, Dec 21, 2015 at 04:53:24PM -0600, Matt DeVillier wrote:
FYI, the current testing branch (commit 977a7d4) has issues booting Windows 10 via USB / Windows installer media on a Haswell ChromeBox (XHCI only), locks up on the Windows logo. Tag 1.9.0 (commit 01a84be) has no such issues. Will re-test with upstream master and report back
Thanks. I'm surprised as not much has changed since 1.9.0. If you can bisect the error that would really help.
-Kevin
On 12/21/2015 5:02 PM, Kevin O'Connor wrote:
On Mon, Dec 21, 2015 at 04:53:24PM -0600, Matt DeVillier wrote:
FYI, the current testing branch (commit 977a7d4) has issues booting Windows 10 via USB / Windows installer media on a Haswell ChromeBox (XHCI only), locks up on the Windows logo. Tag 1.9.0 (commit 01a84be) has no such issues. Will re-test with upstream master and report back
Thanks. I'm surprised as not much has changed since 1.9.0. If you can bisect the error that would really help.
-Kevin
my apologies, seems like an errant coreboot change (on my local repo, not upstream) was the problem, not SeaBIOS. Testing branch boots fine now that I reverted to a working coreboot version. Sorry for the false alarm
-
Kevin O'Connor -
Matt DeVillier