On Fri, Dec 18, 2015 at 11:51:16AM +0000, edward wandasiewicz wrote:
I thought, lets try swapping over the devices, but keeping the same Type-C cables on the left and right hand side and see what happens.
I get scenario 5.
- NO - Type C & Type C - one Philiips & no Mushkin
cbmem.no.TypeC.TypeC.one.Philips.no.Mushkin
Unfortunately, that log gets truncated before the interesting part. Can you reproduce with debug log 3? (Using 46-g0cc3233 is fine.)
-Kevin
How quickly do you think you'll upstream these changes, Kevin? - they make a USB 3.0 M2 SSD enclosure I've just bought, work, on the USB 3.0 port, whereas it will only work with the USB 2.0 on upstream.
John.
On 2015-12-18 22:54, Kevin O'Connor wrote:
On Fri, Dec 18, 2015 at 11:51:16AM +0000, edward wandasiewicz wrote:
I thought, lets try swapping over the devices, but keeping the same Type-C cables on the left and right hand side and see what happens.
I get scenario 5.
- NO - Type C & Type C - one Philiips & no Mushkin
cbmem.no.TypeC.TypeC.one.Philips.no.Mushkin
Unfortunately, that log gets truncated before the interesting part. Can you reproduce with debug log 3? (Using 46-g0cc3233 is fine.)
-Kevin
On Sat, Dec 19, 2015 at 05:20:08PM +0000, John Lewis wrote:
How quickly do you think you'll upstream these changes, Kevin? - they make a USB 3.0 M2 SSD enclosure I've just bought, work, on the USB 3.0 port, whereas it will only work with the USB 2.0 on upstream.
Which version works, 0cc3233? For my reference, can you send a log of the working and failing cases?
I think it will take about a week to upstream.
-Kevin
On 2015-12-20 07:59, Kevin O'Connor wrote:
On Sat, Dec 19, 2015 at 05:20:08PM +0000, John Lewis wrote:
How quickly do you think you'll upstream these changes, Kevin? - they make a USB 3.0 M2 SSD enclosure I've just bought, work, on the USB 3.0 port, whereas it will only work with the USB 2.0 on upstream.
Which version works, 0cc3233? For my reference, can you send a log of the working and failing cases?
According to the cbmem console it's b65c2b6. Sure, see attached.
Also, I note the enclosure gets lower boot priority than the onboard SSD when on the USB 3.0 port, but not when on the USB 2.0 port. Do I need to do something to the bootorder file for USB 3.0?
John.
On Sun, Dec 20, 2015 at 07:43:19PM +0000, John Lewis wrote:
On 2015-12-20 07:59, Kevin O'Connor wrote:
On Sat, Dec 19, 2015 at 05:20:08PM +0000, John Lewis wrote:
How quickly do you think you'll upstream these changes, Kevin? - they make a USB 3.0 M2 SSD enclosure I've just bought, work, on the USB 3.0 port, whereas it will only work with the USB 2.0 on upstream.
Which version works, 0cc3233? For my reference, can you send a log of the working and failing cases?
According to the cbmem console it's b65c2b6. Sure, see attached.
Thanks, but the "badboot" log doesn't seem to show the failure.
Also, I note the enclosure gets lower boot priority than the onboard SSD when on the USB 3.0 port, but not when on the USB 2.0 port. Do I need to do something to the bootorder file for USB 3.0?
Your boot order file only seems to extend to ports 1-7, while it looks like the controller defines up to 15 ports. (In particular, it looks like port '/pci@i0cf8/usb@14/usb-*@c' is needed.)
-Kevin
Thanks, but the "badboot" log doesn't seem to show the failure.
Apologies, not thinking again. How about that one?
Also, I note the enclosure gets lower boot priority than the onboard SSD when on the USB 3.0 port, but not when on the USB 2.0 port. Do I need to do something to the bootorder file for USB 3.0?
Your boot order file only seems to extend to ports 1-7, while it looks like the controller defines up to 15 ports. (In particular, it looks like port '/pci@i0cf8/usb@14/usb-*@c' is needed.)
Thanks for the tip, I'll try fixing that up.
John.
On Sun, Dec 20, 2015 at 08:23:40PM +0000, John Lewis wrote:
Thanks, but the "badboot" log doesn't seem to show the failure.
Apologies, not thinking again. How about that one?
Okay - looks like you don't have the high/super confusion, but do need the wait for port enable. I cleaned up the patches and pushed them to the testing branch, it would be great if you and Edward can verify that the testing branch works as before.
-Kevin
On 2015-12-20 21:03, Kevin O'Connor wrote:
On Sun, Dec 20, 2015 at 08:23:40PM +0000, John Lewis wrote:
Thanks, but the "badboot" log doesn't seem to show the failure.
Apologies, not thinking again. How about that one?
Okay - looks like you don't have the high/super confusion, but do need the wait for port enable. I cleaned up the patches and pushed them to the testing branch, it would be great if you and Edward can verify that the testing branch works as before.
Yep, looks fine my end. Thanks.
John.
As requested, for rel-1.9.0-46-g636cbb4.
Is it worth testing the double scenario, or maybe put it down to a "manufacturer's flaw" going forward?
Edward.
On Sun, Dec 20, 2015 at 9:03 PM, Kevin O'Connor kevin@koconnor.net wrote:
On Sun, Dec 20, 2015 at 08:23:40PM +0000, John Lewis wrote:
Thanks, but the "badboot" log doesn't seem to show the failure.
Apologies, not thinking again. How about that one?
Okay - looks like you don't have the high/super confusion, but do need the wait for port enable. I cleaned up the patches and pushed them to the testing branch, it would be great if you and Edward can verify that the testing branch works as before.
-Kevin
-
edward wandasiewicz -
John Lewis -
Kevin O'Connor