Bug 202645 - x11/xorg Mouse driver problem causes infinite loop in err log output
Summary: x11/xorg Mouse driver problem causes infinite loop in err log output
Status: Closed Feedback Timeout
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-x11 (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-08-25 09:08 UTC by nogcjx
Modified: 2018-05-20 15:21 UTC (History)
2 users (show)

See Also:


Attachments
the head and tail of Xorg log (was 400MB), pciconf, pkg info (12.00 KB, application/x-compressed-tar)
2015-08-25 09:08 UTC, nogcjx
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description nogcjx 2015-08-25 09:08:37 UTC
Created attachment 160336 [details]
the head and tail of Xorg log (was 400MB), pciconf, pkg info

System freeze and Xorg log file files to 400+MB after a possible problem loading a mouse driver -- running in kvm/qemu virtualization. I have had the problem at least twice since yesterday when I first intalled FreeBSD 11.  I have been running FreeBSD 10.1 in the same virtualization environment with no problems.

The main error might have been this:

[    88.415] (II) Mouse: ps2EnableDataReporting: succeeded
(EE) BUG: triggered 'if (inSignalContext)'
(EE) BUG: log.c:599 in LogVMessageVerb()
(EE) Warning: attempting to log data in a signal unsafe manner while in signal context.
Please update to check inSignalContext and/or use LogMessageVerbSigSafe() or ErrorFSigSafe().
The offending log format message is:
Mouse autoprobe: Changing protocol to %s


The last two lines of the output below are repeated in the Xorg log file to 400+MB until I killed it.  The system was unresponsive during that time and CPU was 100%.  Also note that this command:

vidcontrol -i mode

produces no list of valid graphics devices, whereas FreeBSD 10.1 produces a giant list when running in a virtual machine created with the same options.  The original mouse problem might have been related to a possible mouse problem in the host operating system, but either way, the virtual machine should not freeze and fill the hard drive.

I installed FreeBSD-11.0-CURRENT-amd64-20150722-r285794-disc1.iso then added xorg from pkg. Note that when I ran FreeBSD-11.0-CURRENT-amd64-20150722-r285794-bootonly.iso, xorg would not load at all (after many attempts).








[    87.967] (**) sysmouse: (accel) acceleration profile 0
[    87.967] (**) sysmouse: (accel) acceleration factor: 2.000
[    87.967] (**) sysmouse: (accel) acceleration threshold: 4
[    87.968] (II) sysmouse: SetupAuto: hw.iftype is 4, hw.model is 0
[    87.968] (II) sysmouse: SetupAuto: protocol is SysMouse
[    88.003] (II) config/devd: adding input device Mouse (/dev/psm0)
[    88.003] (II) Using input driver 'mouse' for 'Mouse'
[    88.003] (**) Mouse: always reports core events
[    88.003] (**) Option "Device" "/dev/psm0"
[    88.003] (==) Mouse: Protocol: "Auto"
[    88.003] (**) Mouse: always reports core events
[    88.037] (==) Mouse: Emulate3Buttons, Emulate3Timeout: 50
[    88.037] (**) Mouse: ZAxisMapping: buttons 4 and 5
[    88.038] (**) Mouse: Buttons: 5
[    88.038] (**) Option "config_info" "devd:psm0"
[    88.038] (II) XINPUT: Adding extended input device "Mouse" (type: MOUSE, id 8)
[    88.038] (**) Mouse: (accel) keeping acceleration scheme 1
[    88.038] (**) Mouse: (accel) acceleration profile 0
[    88.038] (**) Mouse: (accel) acceleration factor: 2.000
[    88.038] (**) Mouse: (accel) acceleration threshold: 4
[    88.045] (II) Mouse: SetupAuto: hw.iftype is 3, hw.model is 10
[    88.045] (II) Mouse: SetupAuto: protocol is ExplorerPS/2
[    88.415] (II) Mouse: ps2EnableDataReporting: succeeded
(EE) BUG: triggered 'if (inSignalContext)'
(EE) BUG: log.c:599 in LogVMessageVerb()
(EE) Warning: attempting to log data in a signal unsafe manner while in signal context.
Please update to check inSignalContext and/or use LogMessageVerbSigSafe() or ErrorFSigSafe().
The offending log format message is:
Mouse autoprobe: Changing protocol to %s

(II) Mouse autoprobe: Changing protocol to ImPS/2
(EE) BUG: triggered 'if (inSignalContext)'
(EE) BUG: log.c:599 in LogVMessageVerb()
(EE) Warning: attempting to log data in a signal unsafe manner while in signal context.
Please update to check inSignalContext and/or use LogMessageVerbSigSafe() or ErrorFSigSafe().
The offending log format message is:
Mouse autoprobe: Changing protocol to %s

(II) Mouse autoprobe: Changing protocol to ExplorerPS/2
(EE) BUG: triggered 'if (inSignalContext)'
(EE) BUG: log.c:599 in LogVMessageVerb()
(EE) Warning: attempting to log data in a signal unsafe manner while in signal context.
Please update to check inSignalContext and/or use LogMessageVerbSigSafe() or ErrorFSigSafe().
The offending log format message is:
Mouse autoprobe: Changing protocol to %s

(WW) Warned 3 times about sigsafe logging. Will be quiet now.
(II) Mouse autoprobe: Changing protocol to ImPS/2
(II) Mouse autoprobe: Changing protocol to ExplorerPS/2
(II) Mouse autoprobe: Changing protocol to ImPS/2
(II) Mouse autoprobe: Changing protocol to ExplorerPS/2
Comment 1 nogcjx 2015-09-06 19:58:33 UTC
The underlying problem in the host machine was related to a USB device that disconnects, but such a problem should not cause a log message flood of hundreds of megabytes writing at full speed. my bug report is still a request to avoid a log message storm when such a hardware event happens.



The underlying problem with my host that MIGHT be the initial trigger in the FreeBSD 11 kvm/qemu vm is described by these error messgaes in the Debian 8 host:


Sep  6 15:47:06 mmm kernel: [79177.448628] bcm5974: mode switch failed
Sep  6 15:47:06 mmm kernel: [79177.497639] bcm5974 7-2:1.2: could not read from device
Sep  6 15:47:06 mmm kernel: [79177.497646] bcm5974: mode switch failed
Sep  6 15:47:06 mmm kernel: [79177.620304] usb usb7-port2: disabled by hub (EMI?), re-enabling...
Sep  6 15:47:06 mmm kernel: [79177.620324] usb 7-2: USB disconnect, device number 38
Sep  6 15:47:06 mmm kernel: [79177.944147] usb 7-2: new full-speed USB device number 39 using uhci_hcd
Sep  6 15:47:06 mmm kernel: [79178.130706] usb 7-2: New USB device found, idVendor=05ac, idProduct=0230
Sep  6 15:47:06 mmm kernel: [79178.130718] usb 7-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep  6 15:47:06 mmm kernel: [79178.130725] usb 7-2: Product: Apple Internal Keyboard / Trackpad
Sep  6 15:47:06 mmm kernel: [79178.130731] usb 7-2: Manufacturer: Apple, Inc.
Sep  6 15:47:06 mmm kernel: [79178.142760] input: Apple, Inc. Apple Internal Keyboard / Trackpad as /devices/pci0000:00/0000:00:1d.2/usb7/7-2/7-2:1.0/0003:05AC:0230.F77C/input/input63368
Sep  6 15:47:06 mmm kernel: [79178.143054] apple 0003:05AC:0230.F77C: input,hidraw1: USB HID v1.11 Keyboard [Apple, Inc. Apple Internal Keyboard / Trackpad] on usb-0000:00:1d.2-2/input0
Sep  6 15:47:07 mmm kernel: [79178.649101] apple 0003:05AC:0230.F77D: hidraw2: USB HID v1.11 Device [Apple, Inc. Apple Internal Keyboard / Trackpad] on usb-0000:00:1d.2-2/input1
Sep  6 15:47:07 mmm kernel: [79178.652296] input: bcm5974 as /devices/pci0000:00/0000:00:1d.2/usb7/7-2/7-2:1.2/input/input63369
Sep  6 15:47:07 mmm mtp-probe: checking bus 7, device 39: "/sys/devices/pci0000:00/0000:00:1d.2/usb7/7-2"
Sep  6 15:47:07 mmm mtp-probe: bus: 7, device: 39 was not an MTP device





I disabled the trackpad in my old MacBook and the errors in the host have subsided (see http://ubuntuforums.org/showthread.php?t=840040&page=28).  I just ran

rmmod bcm5974


Note that my bug report is still a request to avoid a log message storm when such a hardware event happens.

thx
Comment 2 Walter Schwarzenfeld freebsd_triage 2018-01-12 22:11:29 UTC
No maintainer feedback!
Comment 3 Walter Schwarzenfeld freebsd_triage 2018-01-12 22:11:59 UTC
Is this still relevant? If not please close the PR.
Comment 4 Niclas Zeising freebsd_committer freebsd_triage 2018-05-20 15:21:27 UTC
Freedback timeout