deps: bump uart_16550 to 0.6.0#565
Conversation
phip1611
changed the title
phip1611
force-pushed
the
uart
branch
2 times, most recently
from
69442f7 to
21dd2d3
Compare
Freax13
left a comment
Freax13
left a comment
There was a problem hiding this comment.
Thank you for your contribution!
| use core::fmt; | ||
| use uart_16550::backend::PioBackend; | ||
|
|
||
| pub struct SerialPort { |
There was a problem hiding this comment.
Should we replace SerialPort with Uart16550Tty? Both implement core::fmt::Write, so I don't see much of a reason to keep SerialPort around. Uart16550Tty also does the \n to \r\n conversion SerialPort does.
There was a problem hiding this comment.
I tried but for some reason on of these checks fails:
This surprises me becaue in the integration test of uart_16550 it works in QEMU. I don't have time to investigate for now. Can we move forward?
I've added a TODO comment in the code
There was a problem hiding this comment.
Looks to me like it's spinning somewhere. I think it's spinning in receive_bytes_exact.
There was a problem hiding this comment.
could you help me investigating please? I'd love to understand why it fails
There was a problem hiding this comment.
could you help me investigating please? I'd love to understand why it fails
I tried looking into this yesterday. I think it's some kind of race condition in the self-test code. I can't trigger the issue reliably though. Adding artificial system load seems to make it easier to reproduce, but it's still not completely reliable.
For some reason, I had a harder time reproducing the error with the latest HEAD for uart_16550. I'm not sure why.
I might be able to take another look at this later today.
I think my next step is going to be looking at the serial port implementation in QEMU to see if there's anything that could explain the race condition (maybe asynchronous processing?).
There was a problem hiding this comment.
I don't know about you, but I've only seen this happen when booting with UEFI. Maybe UEFI's initialization and use of the serial port before the bootloader somehow causes issues?
There was a problem hiding this comment.
Interesting - the UEFI console takes ownership of the serial device by default. One must therefore disconnect the UEFI console from using the serial device (as long as boot services are active but one wants to use the serial device). I think this is the problem.
The forced disconnct is also fairly easy
There was a problem hiding this comment.
The forced disconnct is also fairly easy
How would one do that?
Here's something interesting: Wrapping the call to Uart16550Tty::new_port in x86_64::instructions::interrupts::without_interrupts fixes the issue. Disabling interrupts in the tty config (config.interrupts = IER::empty();) does not work however.
There was a problem hiding this comment.
The forced disconnct is also fairly easy
How would one do that?
Regarding interrupts:thanks! That's something I can use for my testing and debugging
There was a problem hiding this comment.
BTW I'm preparing an update of the uefi dependency
Uart16550 has a layout of (32 /* size*/, 4 /* align*/) whereas the old SerialPort had (2, 2). The test shows that this small change is sufficient to fail the test with the old stack size. We slightly increase the stack therefore.
2 participants
Let's use the latest and greatest version