Bug #1643
closed
Accessing usb serial adapter HL-340 panics system
0%
Description
when accessing my usb serial adapter (HL-340 is printed on the
connector) with minicom or cu I get a reproducable panic:
atom# kgdb kern.3 vmcore.3
GNU gdb (GDB) 7.0
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-dragonfly".
For bug reporting instructions, please see:
<http://bugs.dragonflybsd.org/>...
Reading symbols from /var/crash/kern.3...done.
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
mp_lock = 00000003; cpuid = 3; lapic.id = 03000000
fault virtual address = 0x60
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc08a02e9
stack pointer = 0x10:0xe0fa49ec
frame pointer = 0x10:0xe0fa49f4
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 1056 (cu)
current thread = pri 38 (CRIT)
<- SMP: XXX
trap number = 12
panic: page fault
mp_lock = 00000003; cpuid = 3
Trace beginning at frame 0xe0fa48b4
panic(c0652aae,3,c0627b5e,e0fa48e8,e0fa48e8) at panic+0x172
panic(c0627b5e,c065324a,e0242f9c,1,1) at panic+0x172
trap_fatal(e04b8630,0,1,0,60) at trap_fatal+0x384
trap_pfault(db3a1df4,db3a1df4,e05bc9b0,0,26) at trap_pfault+0x14e
trap(e0fa49a4) at trap+0x7d1
calltrap() at calltrap+0xd
--- trap 0, eip = 0, esp = 0xe0fa49e8, ebp = 0xe0fa4a34 ---
(null)(4b00,4b444719,28c457e,4b444719,28c457e) at 0
boot() called on cpu#3
Uptime: 6m50s
Physical memory: 2030 MB
Dumping 201 MB: 186 170 154 138 122 106 90 74 58 42 26 10
Reading symbols from /boot/modules/uchcom.ko...done.
Loaded symbols for /boot/modules/uchcom.ko
Reading symbols from /boot/modules/ucom.ko...done.
Loaded symbols for /boot/modules/ucom.ko
Reading symbols from /boot/modules/acpi.ko...done.
Loaded symbols for /boot/modules/acpi.ko
get_mycpu (di=0xc073e280) at ./machine/thread.h:83
83 __asm ("movl %%fs:globaldata,%0" : "=r" (gd) :
"m"(_mycpu__dummy));
(kgdb) trace
Tracepoint 1 at 0xc05bd908: file ./machine/thread.h, line 83.
(kgdb) backtrace
#0 _get_mycpu (di=0xc073e280) at ./machine/thread.h:83
#1 md_dumpsys (di=0xc073e280) at
/home/lentferj/repo/src/sys/platform/pc32/i386/dump_machdep.c:264
#2 0xc0365092 in dumpsys () at
/home/lentferj/repo/src/sys/kern/kern_shutdown.c:838
#3 0xc0365708 in boot (howto=260) at
/home/lentferj/repo/src/sys/kern/kern_shutdown.c:387
#4 0xc0365d02 in panic (fmt=0xc0627b5e "%s") at
/home/lentferj/repo/src/sys/kern/kern_shutdown.c:744
#5 0xc05d2904 in trap_fatal (frame=0xe0fa49a4, eva=<value optimized
out>) at /home/lentferj/repo/src/sys/platform/pc32/i386/trap.c:1127
#6 0xc05d2a66 in trap_pfault (frame=0xe0fa49a4, usermode=0, eva=96) at
/home/lentferj/repo/src/sys/platform/pc32/i386/trap.c:1028
#7 0xc05d388d in trap (frame=0xe0fa49a4) at
/home/lentferj/repo/src/sys/platform/pc32/i386/trap.c:707
#8 0xc05be077 in calltrap () at
/home/lentferj/repo/src/sys/platform/pc32/i386/exception.s:785
#9 0xc08a02e9 in uchcom_param (arg=0x0, portno=-1, t=0xe0fa4a34) at
/home/lentferj/repo/src/sys/dev/usbmisc/uchcom/uchcom.c:946
#10 0xc08a452f in ucomparam (tp=0xdb45ac70, t=0xe0fa4a34) at
/home/lentferj/repo/src/sys/dev/usbmisc/ucom/ucom.c:812
#11 0xc08a527a in ucomopen (ap=0xe0fa4a78) at
/home/lentferj/repo/src/sys/dev/usbmisc/ucom/ucom.c:297
#12 0xc0346cc1 in dev_dopen (dev=0xc46a2ec0, oflags=3, devtype=8192,
cred=0xd7d8fac8) at /home/lentferj/repo/src/sys/kern/kern_device.c:115
#13 0xc050a3af in devfs_spec_open (ap=0xe0fa4aec) at
/home/lentferj/repo/src/sys/vfs/devfs/devfs_vnops.c:833
#14 0xc03d92fb in vop_open (ops=0xdb45d970, vp=0xe04c23e8, mode=3,
cred=0xd7d8fac8, fp=0xe0445208)
at /home/lentferj/repo/src/sys/kern/vfs_vopops.c:289
#15 0xc03d6da4 in vn_open (nd=0xe0fa4c70, fp=0xe0445208, fmode=3,
cmode=0) at /home/lentferj/repo/src/sys/kern/vfs_vnops.c:270
#16 0xc03cf44d in kern_open (nd=0xe0fa4c70, oflags=2, mode=0,
res=0xe0fa4cf0) at /home/lentferj/repo/src/sys/kern/vfs_syscalls.c:1812
---Type <return> to continue, or q <return> to quit---
---Type <return> to continue, or q <return> to quit---#17 0xc03d0126 in
sys_open (uap=0xe0fa4cf0) at
/home/lentferj/repo/src/sys/kern/vfs_syscalls.c:1926
#18 0xc05d41ef in syscall2 (frame=0xe0fa4d40) at
/home/lentferj/repo/src/sys/platform/pc32/i386/trap.c:1361
#19 0xc05be126 in Xint0x80_syscall () at
/home/lentferj/repo/src/sys/platform/pc32/i386/exception.s:876
#20 0x0000001f in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(kgdb)
on linux this adapter workd with the ch341 driver.
further info:
dmesg:
ucom0: <vendor 0x4348 USB-SER!, class 255/0, rev 1.10/2.50, addr 2> on uhub0
ucom0: CH340
atom# usbdevs -v
Controller /dev/usb0:
addr 1: full speed, self powered, config 1, UHCI root hub(0x0000),
Intel(0x0000), rev 1.00
port 1 addr 2: full speed, power 78 mA, config 1, USB-SER!(0x5523),
vendor 0x4348(0x4348), rev 2.50
port 2 powered
Updated by TGEN almost 15 years ago
Jan Lentfer wrote:
when accessing my usb serial adapter (HL-340 is printed on the
connector) with minicom or cu I get a reproducable panic:#9 0xc08a02e9 in uchcom_param (arg=0x0, portno=-1, t=0xe0fa4a34) at
/home/lentferj/repo/src/sys/dev/usbmisc/uchcom/uchcom.c:946
Looks like a null pointer dereference of arg in that function.
--
Thomas E. Spanjaard
tgen@netphreax.net
tgen@deepbone.net
Updated by lentferj almost 15 years ago
This patch fixes the panic according to my tests:
diff --git a/sys/dev/usbmisc/uchcom/uchcom.c
b/sys/dev/usbmisc/uchcom/uchcom.c
index 353552e..d925d9c 100644
--- a/sys/dev/usbmisc/uchcom/uchcom.c
+++ b/sys/dev/usbmisc/uchcom/uchcom.c@ -276,6 +276,7 @ uchcom_attach(device_t self)
sc->sc_intr_size = endpoints.ep_intr_size;
/* setup ucom layer */
+ ucom->sc_parent = sc;
ucom->sc_portno = UCOM_UNK_PORTNO;
ucom->sc_bulkin_no = endpoints.ep_bulkin;
ucom->sc_bulkout_no = endpoints.ep_bulkout;Now I can use tip and cu and minicom on /dev/ucom0 without panicing the
system. But still it won't really work. I get such messages in dmesg:
ucom0: ucomreadcb: IOERROR
ucom0: ucomreadcb: IOERROR
ucom0: ucomreadcb: IOERROR
ucom0: ucomreadcb: CANCELLED
ucom0: cannot reset: IOERROR
and
putc to a clist with no reserved cblocks
I found an error description for FBSD and another driver that seems
match otherwise:
http://groups.google.com/group/mailing.freebsd.stable/browse_thread/thread/27b3ebcdd9cf1e00
But I am not really getting much out of that. Maybe someone could read
through that and evaluate if this helps in my case?
Thanks a lot in advance
Jan
Updated by lentferj almost 15 years ago
Problem is solved by the patch. The IOERROR where misleading and due to a "not
so well" working usb port.