Opened 4 years ago

Last modified 3 years ago

#12713 assigned bug

input_server crash at boot

Reported by: Pete Owned by: nobody
Priority: normal Milestone: R1
Component: Servers/input_server Version: R1/Development
Keywords: Cc:
Blocked By: #12412 Blocking:
Has a Patch: no Platform: All

Description (last modified by diver)

Recent nightlies have been giving me a very odd KDL. I get the KDL white-screen but it goes away before I have time to read it! Then I get a normal looking Desktop... but everything is dead. I have to use Ctrl-Alt-Del to reboot.

I think it's due to having my twitchy hand on the mouse. The crash doesn't always happen but I think it does when I've moved the mouse. I just tried and deliberately moved the mouse, and it crashed. I have a USB wireless mouse.

I've never been able to read the fast-disappearing KDL screen, but looking at the syslog, this seems to be it:

KERN: bfs: mounted "Haiku" (root node at 524288, device = /dev/disk/scsi/0/4/0/2)
KERN: /dev/net/iprowifi4965/0: media change, media 0x300a0 quality 1000 speed 1000000000
KERN: usb_hid: no handlers for hid device
KERN: loaded driver /boot/system/add-ons/kernel/drivers/dev/input/usb_hid
KERN: ps2_hid: init_hardware
KERN: ps2_hid: init_driver
KERN: ps2: active multiplexing v1.1 enabled
KERN: ps2_hid: publish_devices
KERN: ps2_hid: uninit_driver
KERN: loaded driver /boot/system/add-ons/kernel/drivers/dev/input/ps2_hid
KERN: ps2: reset failed
KERN: ps2: devfs_publish_device input/mouse/ps2/0, status = 0xffffffff
KERN: loaded driver /boot/system/add-ons/kernel/drivers/dev/input/wacom
KERN: usb_hid: keyboard device unhandled control 0x00002710
Last message repeated 1 time
KERN: vm_soft_fault: va 0x10000 not covered by area in address space
KERN: vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0x10000, ip 0x60b951, write 1, user 1, thread 0x2b9
KERN: vm_page_fault: thread "_input_server_event_loop_" (697) in team "input_server" (683) tried to write address 0x10000, ip 0x60b951 ("libroot.so_seg0ro" +0x36951)
KERN: debug_server: Thread 697 entered the debugger: Segment violation
KERN: stack trace, current PC 0x60b951  atomic_set + 0xd:
KERN:   (0x79b19948)  0x219b60f  _DispatchEvents__11InputServerRt11BObjectList1Z8BMessage + 0x4f
KERN:   (0x79b19978)  0x219aaa9  _EventLoop__11InputServer + 0x1d9
KERN:   (0x79b199f8)  0x219a8c7  _EventLooper__11InputServerPv + 0x1f
KERN:   (0x79b19a28)  0x606d23  thread_entry + 0x23

Any ideas? I am currently at hrev50180 but it's been happening for a while.

Change History (9)

comment:1 by Pete, 4 years ago

Why can I (as the creator of the ticket) not seem to be able to modify it? Two stupid typos I missed, but also I should see if I can find a better category -- and change the milestone to 'R1'. "Modify Ticket" just gives me the field "Leave as new"...

comment:2 by diver, 4 years ago

Component: - GeneralServers/input_server
Description: modified (diff)
Keywords: KDL removed
Milestone: UnscheduledR1
Owner: changed from nobody to korli
Platform: x86All

comment:3 by diver, 4 years ago

Blocked By: 12412 added
Resolution: duplicate
Status: newclosed

Probably a dupe of #12412

comment:4 by Pete, 4 years ago

Thanks for fixing the original post! (Though the subject line still has the erroneous space.)

I'm not so sure this is a duplicate, though. From reading the other ticket, that seems to have been a full (persisting) KDL. He was able to take a photo of the screen. When it happens to me, the white-screen is only visible for at most 1 second, before it goes back to booting, and ends up with a normal-looking desktop. Input is frozen, though.

I also scanned through the syslog(s) in the other ticket, and I don't see the 'soft_fault' and bad address that I found in mine.

Worth reopening?

comment:5 by Pete, 4 years ago

Resolution: duplicate
Status: closedreopened

I've done considerably more testing, and I'm convinced this is not related to #12412. The other KDL is reported as only hsppening on the first boot after an install; this one is reproducible at will. The "soft_fault" that I consistently see (shown in the syslog excerpt above) does not appear anywhere in the #12412 syslogs. The fact that the KDL is momentary is also totally consistent -- and totally strange to me!

I have established fairly solidly that it only happens if I move the mouse during boot. If I don't touch it, the boot is always OK.

I noticed that the fault is always just preceded by loading the wacom driver, so I tried installing an old pre-PM copy (that has never given any trouble) in non-packaged... It made no difference to the crash (though it seems to work just as well).

I hadn't been using my Wacom, but I plugged it in this time, and found that moving the pen has exactly the same effect as moving the mouse. OTOH I haven't been able to cause a crash by activating the laptop's TrackPad. Both the mouse and Wacom are USB, so maybe the problem is somewhere in that area.

Reopening the ticket...

[BTW I still have to use my custom Wacom Intuos device (not the driver), because my submitted patch #4847 of a few years ago is still hanging...!]

in reply to:  5 ; comment:6 by ttcoder, 4 years ago

I'd bet dollars to donuts you're not seeing a KDL but an app_server/input_server crash (as per the _input_server_event_loop_ in your stack crawl from the syslog). Those are handled by Debugger but appear as screenbuffer black-on-white stuff of course (you can't display a BWindow without the servers). That would also explain (?) why the report is erased in a fraction of a second.

[BTW I still have to use my custom Wacom Intuos device (not the driver), because my submitted patch #4847 of a few years ago is still hanging...!]

For years now the Haiku dudes have been telling me to "build my own Haiku image" to use my own build profile (release mode ..etc) and include patches to which they're giving the "japanese inspection treatment" :-b .. I finally broke down and went with the flow.. Maybe it would help you too ;-)

in reply to:  6 comment:7 by Pete, 4 years ago

Replying to ttcoder:

I'd bet dollars to donuts you're not seeing a KDL but an app_server/input_server crash (as per the _input_server_event_loop_ in your stack crawl from the syslog). Those are handled by Debugger but appear as screenbuffer black-on-white stuff of course (you can't display a BWindow without the servers). That would also explain (?) why the report is erased in a fraction of a second.

Hah! I guess that's it! I couldn't understand why a 'KDL', which supposedly stops everything, could go away again. Maybe it's a pity it's not a KDL, because then I might get a clue... (:-/)

Strange that it seems to be happening only to me. Maybe everyone else is good about not touching the mouse...

comment:8 by korli, 3 years ago

Owner: changed from korli to nobody
Status: reopenedassigned

comment:9 by diver, 3 years ago

Summary: "Momen tary" KDL at bootinput_server crash at boot
Note: See TracTickets for help on using tickets.