SL6 epel garmin 18 lvc serial port pps kernel trace

[Skunk Worx]

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