Opened 5 months ago

Closed 5 months ago

#15172 closed bug (fixed)

SMAP violation when attaching FTDI based serial device

Reported by: probono Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: Drivers/TTY Version: R1/Development
Keywords: Cc: PulkoMandy
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

Kernel panic when attaching FTDI based serial device

KDL screenshot: https://i.imgur.com/GWMmSRA.jpg

Reproducible:

  • Attach a FTDI based device (Arduino mini)
  • Try to open the port with the SerialConnect tool

Disabling SMEP and SMAP in bootloader prevents this crash from happening.

Change History (18)

comment:1 by diver, 5 months ago

Component: - GeneralDrivers/USB/XHCI
Owner: changed from nobody to waddlesplash

comment:2 by probono, 5 months ago

/> uname -a
Haiku shredder 1 hrev53259+3 Jul 15 2019 23:37:0 x86_64 x86_64 Haiku

comment:3 by waddlesplash, 5 months ago

The return value of PrepareKernelAccess is not checked here: https://xref.plausible.coop/source/xref/haiku/src/add-ons/kernel/busses/usb/xhci.cpp#2804

However, it is very curious this appears as a "user mapped address"; I would expect InitKernelAccess to have made it into a kernel one (by subtracting off the area base). The syslog tail should show what is really happening.

comment:4 by probono, 5 months ago

How can I get a syslog tail? To trigger the exception, I need to open the port in SerialConnect (which requires a mouse or keyboard, which I don't have while KDL is open). Once I have triggered the exception by opening the port, the USB keyboard becomes unresponsive so that I cannot type anything anymore in KDL.

comment:5 by diver, 5 months ago

Try running /bin/kernel_debugger first and then exit from KDL with es.

Last edited 5 months ago by diver (previous) (diff)

comment:6 by probono, 5 months ago

When I do that and then open the port in SerialConnect, KDL appears but I cannot enter anything.

comment:7 by probono, 5 months ago

Maybe KDL should print the last 50 lines of syslog by default?

comment:8 by diver, 5 months ago

Do you maybe have ps2 keyboard laying around? That should work in KDL.

comment:9 by probono, 5 months ago

Unfortunately, I the machine does not have that port anymore, and I don't have a PS/2 keyboard around anymore.

comment:10 by diver, 5 months ago

Maybe KDL can print last 50 lines of syslog after 1 minute timeout is not that bad after all?

comment:11 by waddlesplash, 5 months ago

Doing that would be pretty difficult.

Actually I have an idea as to what might be going wrong here. The error message still doesn't make sense, but hopefully my hunch will be correct.

comment:12 by waddlesplash, 5 months ago

hrev53280~1 may fix this, please test when you get a chance.

comment:13 by waddlesplash, 5 months ago

Cc: PulkoMandy added
Component: Drivers/USB/XHCIDrivers/TTY
Owner: changed from waddlesplash to nobody

Actually the real culprit seems to be this: https://github.com/haiku/haiku/blob/master/src/add-ons/kernel/drivers/ports/usb_serial/SerialDevice.cpp#L91

Since this create_area is called in the kernel, it will be mapped into the kernel address space but with user-writeable permissions; thus IS_USER_ADDRESS will return false and the USB stack will not use the user functions to access it.

AFAICT, it is not used outside this driver or passed to user-space, so the solution seems to be to simply change it to be mapped in the kernel only. PulkoMandy, can you confirm this is correct?

comment:14 by pulkomandy, 5 months ago

The area is used for 3 tings:

  • interrupt driver is passed to the USB module. You may know better than me what happens to this one
  • output buffer is passed to the TTY module. I have no idea what happens there
  • write buffer seems to be completely internal to the driver.

comment:15 by probono, 5 months ago

Still getting this in hrev53259+3. I don't know how to get hrev53280~1. It is not offered to me, pkgman update thinks I am up to date.

comment:16 by diver, 5 months ago

Package repos are not currently being generated automatically due to a switch to another CI. Anyboot images are being updated as before, thought.

comment:17 by probono, 5 months ago

I see. Nightly repository was known to the system but not enabled. After enabling it and rebooting, I now have hrev53293. The issue persists, though.

Last edited 5 months ago by probono (previous) (diff)

comment:18 by waddlesplash, 5 months ago

Resolution: fixed
Status: newclosed

Fixed in hrev53309.

Note: See TracTickets for help on using tickets.