Kernel oops on KVM switching from this RPi to another RPi #252
Assignees
Comments
|
Can you post a full lsusb -v and dmesg for the kvm/devices attached to it (as seen by both Pis)? Does this happen with every switch? |
|
It is indeed repeatable. Message in 2 halves as Git says too many char's. RPi 1 ++++++++++++ |
|
RPi 2 |
|
Your 2nd Pi log suggests that you managed several switches - can you manage at least 1 switch without it crashing? |
|
Yes, It seems to be worse in one direction than the other. |
|
fiq_fsm should now handle dequeues (that would happen when a device disappears) a lot better. Can you retest with latest BRANCH=next firmware? |
|
Just the same I'm afraid, instant lockup on switching, thus no specific log entry. Intrigued by jdb's reference on RPi forum to high speed isoc' FIQ now being implemented (mask 7), I wanted to test with my 290e tuner, but as previously mentioned,recent kernels prevent it being initialised. Anyway, I changed the kernel.img to 3.10.16, leaving cmdline.txt as is, along with last night's firmware update. Tuner came up fine, as you can see in the log (but of course fails when I switch back to new kernel), but watching hdtv via omxplayer exhibited the artefacts I've come to recognise as being USB transfer related. Next I added KrfVan's last 3 cmdline options (basically trans_backoff). That didn't help except that now omxplayer gave up displaying the stream after a minute or so, leaving just the last remaining frame displayed. Just as a reference point, I then changed cmdline.txt for the "old" version that I had good results with using KrfVan's implementation, in other words, removed the 3 options for the new FIQ implementation. Rebooted & now a watchable stream, pretty much as I had several weeks ago. part of kern.log: |
|
On the failing system with the KVM, can you just boot into textmode and do KVM switches until it crashes? The panic should be visible on HDMI output. I need to see if the output has changed. |
|
I should have thought of that, sorry. |
|
I realised afterwards that wasn't BRANCH= next I updated today, so reinstalled next, & no change. |
|
@tvjon are you still getting crashes? A lot of error cases that could lead to a crash have been squashed in the most recent version of BRANCH=next firmware. |
|
Ah, thank you for the reminder. As you can imagine, I abandoned the KVM approach, as it was becoming unworkable, & I forgot to try again! So far, so good. No panics, & what was perhaps worse, no spurious unmounting/ remounting of USB storage devices :-) I haven't tried cascading hubs, but I only do that on a model A anyway. So, to summarise, what I'm testing with is a Logitech unifying receiver plugged into a small KVM, with each of the 2 outputs going into 1 of the 2 possible USB inputs on each of 2 RPi's. The other USB port on each RPi has a 13 input USB 2 hub, carrying several storage devices. I'm typing this on one of those RPi's. Hopefully I can now put away this other keyboard so I don't inadvertently sudo halt the wrong RPi :-) |
|
Alrighty then. I still need to send back your box 'o gubbins. Email me as to your swag requirements. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Removing the 3 new dwc_otg_fiq options from cmdline.txt restores normal operation.
The text was updated successfully, but these errors were encountered: