Hi everyone,
I have two Mini-ITX Intel mobos I am using as ntpd time servers with a Garmin LVC 18 serial port GPS that provides a PPS input.
I've had good luck with this unit and gpsd in the past, but I get a kernel call trace if I run "setserial" then the "shmpps" daemon.
Here is the info -- if anyone has comments or suggestions I'd appreciate it. I'll probably switch back to gpsd later this week if not.
Repeatable with i686 or x86_64 SL6.
1) Use Intel D945GCLF Atom 230 Mini-ITX mobo 2) Use Garmin 18x LVC gps wired for serial port w/ PPS on DCD pin 3) Install SL6 and "shmpps" EPEL package 4) Boot SL6 2.6.32-131.12.1.el6.x86_64.debug kernel into single user mode 5) Start rsyslog service 6) Note dmesg serial info :
# dmesg | grep serial serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
7) Run setserial command : /bin/setserial /dev/ttyS0 uart 16550A port 0x03f8 irq 4 baud_base 115200 spd_normal skip_test low_latency
8) Run shmpps in debug mode : /usr/sbin/shm_splc2 -d /dev/ttyS0 -s -u 0 -l DCD -D
The following depends on the setserial command being run and having the garmin plugged into the serial port. The call trace is emitted at roughly the same rate as the NMEA strings from the garmin.
BUG: sleeping function called from invalid context at kernel/mutex.c:287 in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper INFO: lockdep is turned off. irq event stamp: 827450 hardirqs last enabled at (827449): [<ffffffff812e36e1>] intel_idle+0xe1/0x170 hardirqs last disabled at (827450): [<ffffffff8100afaa>] save_args+0x6a/0x70 softirqs last enabled at (827440): [<ffffffff8107403a>] __do_softirq+0x14a/0x200 softirqs last disabled at (827415): [<ffffffff8100c38c>] call_softirq+0x1c/0x30 Pid: 0, comm: swapper Not tainted 2.6.32-131.12.1.el6.x86_64.debug #1 Call Trace: <IRQ> [<ffffffff810a7d60>] ? print_irqtrace_events+0xd0/0xe0 [<ffffffff81056027>] ? __might_sleep+0xf7/0x130 [<ffffffff8150cb2f>] ? mutex_lock_nested+0x2f/0x60 [<ffffffff8132cf80>] ? process_output+0x30/0x70 [<ffffffff8132f058>] ? n_tty_receive_buf+0x618/0x1290 [<ffffffff810aa332>] ? print_lock_contention_bug+0x22/0xf0 [<ffffffff810aa332>] ? print_lock_contention_bug+0x22/0xf0 [<ffffffff81332723>] ? flush_to_ldisc+0x43/0x1b0 [<ffffffff81332863>] ? flush_to_ldisc+0x183/0x1b0 [<ffffffff8133290c>] ? tty_flip_buffer_push+0x7c/0x90 [<ffffffff8135e0e5>] ? serial8250_handle_port+0x215/0x350 [<ffffffff8135e2ab>] ? serial8250_interrupt+0x8b/0x120 [<ffffffff810e9370>] ? handle_IRQ_event+0x50/0x160 [<ffffffff810ebaf8>] ? handle_edge_irq+0xc8/0x160 [<ffffffff8100e0d9>] ? handle_irq+0x49/0xa0 [<ffffffff8151497c>] ? do_IRQ+0x6c/0xf0 [<ffffffff8100bb13>] ? ret_from_intr+0x0/0x16 <EOI> [<ffffffff812e36e1>] ? intel_idle+0xe1/0x170 [<ffffffff812e36e8>] ? intel_idle+0xe8/0x170 [<ffffffff812e36e1>] ? intel_idle+0xe1/0x170 [<ffffffff815120a0>] ? __atomic_notifier_call_chain+0x0/0xa0 [<ffffffff81417787>] ? cpuidle_idle_call+0xa7/0x150 [<ffffffff81009e8b>] ? cpu_idle+0xbb/0x110 [<ffffffff814f298a>] ? rest_init+0x7a/0x80 [<ffffffff81b69f59>] ? start_kernel+0x44f/0x45b [<ffffffff81b6933a>] ? x86_64_start_reservations+0x125/0x129 [<ffffffff81b69438>] ? x86_64_start_kernel+0xfa/0x109 ttyS0: 1 input overrun(s)
Thanks, John