[BUG] pl2303 oops in 2.4.20-pre10 (and 2.5 too)

[BUG] pl2303 oops in 2.4.20-pre10 (and 2.5 too)

[Barry K. Nathan]

On one of my systems, when minicom opens /dev/ttyUSB0 (a PL2303) and
the kernel is 2.4.20-pre10 (compiled with Mandrake 9's gcc 3.2),
minicom segfaults and the kernel oopses.

2.4.19 does not have this problem, whether compiled with gcc 2.96 from
Mandrake 8.2 or gcc 3.2 from Mandrake 9.0. The oops happens with
2.4.20-pre5 and -pre9, 2.5.41, and 2.5.41-ac1 as well.

The decoded oops (from 2.4.20-pre10), and the .config (with blank/comment
lines stripped), follow. FWIW, it's a monolithic kernel (module support
disabled). If any more info or data is needed, I'll try my best to
provide it. This bug is 100% reproducible.

ksymoops 2.4.5 on i686 2.4.19-16mdksmp.  Options used
     -v vmlinux (specified)
     -K (specified)
     -L (specified)
     -O (specified)
     -m System.map (specified)

Unable to handle kernel NULL pointer dereference at virtual address 00000010
c01d8cd8
*pde = 00000000
Oops: 0002
CPU:    0
EIP:    0010:[<c01d8cd8>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: 00000000   ebx: c1339400   ecx: 00000021   edx: c134b800
esi: c133941c   edi: 00000000   ebp: cd993e9c   esp: cd993e2c
ds: 0018   es: 0018   ss: 0018
Process minicom (pid: 110, stackpage=cd993000)
Stack: c133f600 cd993e60 00000001 00000040 00000002 00000004 00000000 00000000 
       00000064 cd936006 c0295f5c cd993e70 c017b921 cd936000 00000000 00001000 
       c02e0d20 cd993ebc c0178123 00000000 00000000 00000024 00000000 00000000 
Call Trace:    [<c017b921>] [<c0178123>] [<c01d57bb>] [<c0178e44>] [<c01413a3>]
  [<c015914a>] [<c01378aa>] [<c0136081>] [<c0135fa6>] [<c0140953>] [<c0136351>]
  [<c0107417>]
Code: 89 50 10 8b 46 20 89 04 24 e8 5a e9 fe ff 85 c0 75 76 a1 1c 


>>EIP; c01d8cd8 <pl2303_open+508/890>   <=====

>>ebx; c1339400 <END_OF_CODE+10553a8/????>
>>edx; c134b800 <END_OF_CODE+10677a8/????>
>>esi; c133941c <END_OF_CODE+10553c4/????>
>>ebp; cd993e9c <END_OF_CODE+d6afe44/????>
>>esp; cd993e2c <END_OF_CODE+d6afdd4/????>

Trace; c017b921 <n_tty_open+91/b0>
Trace; c0178123 <init_dev+a3/4d0>
Trace; c01d57bb <serial_open+fb/140>
Trace; c0178e44 <tty_open+244/3d0>
Trace; c01413a3 <link_path_walk+593/710>
Trace; c015914a <ext2_free_blocks+21a/300>
Trace; c01378aa <chrdev_open+5a/60>
Trace; c0136081 <dentry_open+d1/1e0>
Trace; c0135fa6 <filp_open+66/70>
Trace; c0140953 <getname+93/d0>
Trace; c0136351 <sys_open+51/a0>
Trace; c0107417 <system_call+33/38>

Code;  c01d8cd8 <pl2303_open+508/890>
00000000 <_EIP>:
Code;  c01d8cd8 <pl2303_open+508/890>   <=====
   0:   89 50 10                  mov    %edx,0x10(%eax)   <=====
Code;  c01d8cdb <pl2303_open+50b/890>
   3:   8b 46 20                  mov    0x20(%esi),%eax
Code;  c01d8cde <pl2303_open+50e/890>
   6:   89 04 24                  mov    %eax,(%esp,1)
Code;  c01d8ce1 <pl2303_open+511/890>
   9:   e8 5a e9 fe ff            call   fffee968 <_EIP+0xfffee968> c01c7640 <usb_submit_urb+0/50>
Code;  c01d8ce6 <pl2303_open+516/890>
   e:   85 c0                     test   %eax,%eax
Code;  c01d8ce8 <pl2303_open+518/890>
  10:   75 76                     jne    88 <_EIP+0x88> c01d8d60 <pl2303_open+590/890>
Code;  c01d8cea <pl2303_open+51a/890>
  12:   a1 1c 00 00 00            mov    0x1c,%eax

CONFIG_X86=y
CONFIG_UID16=y
CONFIG_EXPERIMENTAL=y
CONFIG_M686=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_HAS_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_PGE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_PPRO_FENCE=y
CONFIG_X86_F00F_WORKS_OK=y
CONFIG_X86_MCE=y
CONFIG_MICROCODE=y
CONFIG_NOHIGHMEM=y
CONFIG_MTRR=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
CONFIG_NET=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_ISA=y
CONFIG_PCI_NAMES=y
CONFIG_HOTPLUG=y
CONFIG_SYSVIPC=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_ELF=y
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_PACKET=y
CONFIG_NETFILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_INET_ECN=y
CONFIG_SYN_COOKIES=y
CONFIG_IP_NF_COMPAT_IPCHAINS=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_IDE_TASK_IOCTL=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_BLK_DEV_ADMA=y
CONFIG_BLK_DEV_SIS5513=y
CONFIG_IDEDMA_AUTO=y
CONFIG_BLK_DEV_IDE_MODES=y
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
CONFIG_NET_ETHERNET=y
CONFIG_NET_PCI=y
CONFIG_PCNET32=y
CONFIG_PPP=y
CONFIG_PPP_ASYNC=y
CONFIG_PPP_DEFLATE=y
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
CONFIG_RTC=y
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_MINIX_FS=y
CONFIG_PROC_FS=y
CONFIG_DEVPTS_FS=y
CONFIG_EXT2_FS=y
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_850=y
CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_15=y
CONFIG_NLS_UTF8=y
CONFIG_VGA_CONSOLE=y
CONFIG_USB=y
CONFIG_USB_DEVICEFS=y
CONFIG_USB_OHCI=y
CONFIG_USB_SERIAL=y
CONFIG_USB_SERIAL_PL2303=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y

Re: [BUG] pl2303 oops in 2.4.20-pre10 (and 2.5 too)

[Greg KH]

On Wed, Oct 09, 2002 at 04:36:24PM -0700, Barry K. Nathan wrote:
> On one of my systems, when minicom opens /dev/ttyUSB0 (a PL2303) and
> the kernel is 2.4.20-pre10 (compiled with Mandrake 9's gcc 3.2),
> minicom segfaults and the kernel oopses.

Can you enable debugging in the pl2303 driver (by loading it with
"debug=1") and send the kernel debug log for when the oops happens.

thanks,

greg k-h

Re: [BUG] pl2303 oops in 2.4.20-pre10 (and 2.5 too)

[Barry K. Nathan]

On Wed, Oct 09, 2002 at 04:53:32PM -0700, Greg KH wrote:
> Can you enable debugging in the pl2303 driver (by loading it with
> "debug=1") and send the kernel debug log for when the oops happens.

Since it's a monolithic kernel, I recompiled with
CONFIG_USB_SERIAL_DEBUG enabled. Here's the dmesg output, followed by
the decoded oops.

-Barry K. Nathan <barryn@pobox.com>

---dmesg begins here---
Linux version 2.4.20-pre10 (barryn@ip68-4-86-174.oc.oc.cox.net) (gcc version 3.2 (Mandrake Linux 9.0 3.2-1mdk)) #1 Thu Oct 10 12:19:24 PDT 2002
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000000fe00000 (usable)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
254MB LOWMEM available.
On node 0 totalpages: 65024
zone(0): 4096 pages.
zone(1): 60928 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=bzimage root=/dev/hda6 vga=0 
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
Initializing CPU#0
Detected 533.398 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1064.96 BogoMIPS
Memory: 254940k/260096k available (1223k kernel code, 4772k reserved, 418k data, 92k init, 0k highmem)
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 128K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU:     After generic, caps: 0183fbff 00000000 00000000 00000000
CPU:             Common caps: 0183fbff 00000000 00000000 00000000
CPU: Intel Celeron (Mendocino) stepping 05
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 533.4058 MHz.
..... host bus clock speed is 66.6756 MHz.
cpu: 0, clocks: 666756, slice: 333378
CPU0<T0:666752,T1:333360,D:14,S:333378,C:666756>
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfb640, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router SIS [1039/0008] at 00:01.0
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
IA-32 Microcode Update Driver: v1.11 <tigran@veritas.com>
Starting kswapd
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
Real Time Clock Driver v1.10e
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
SIS5513: IDE controller on PCI bus 00 dev 01
SIS5513: chipset revision 208
SIS5513: not 100% native mode: will probe irqs later
SiS620
    ide0: BM-DMA at 0x4000-0x4007, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0x4008-0x400f, BIOS settings: hdc:DMA, hdd:DMA
hda: SAMSUNG SV4084H, ATA DISK drive
hdd: CD-ROM Drive/F5E, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
blk: queue c02ddfa4, I/O limit 4095Mb (mask 0xffffffff)
hda: setmax LBA 79730784, native  62500000
hda: 62500000 sectors (32000 MB) w/426KiB Cache, CHS=3890/255/63, UDMA(66)
hdd: ATAPI 52X CD-ROM drive, 128kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
Partition check:
 hda: hda1 hda2 < hda5 hda6 hda7 >
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
loop: loaded (max 8 devices)
pcnet32.c:v1.27a 10.02.2002 tsbogend@alpha.franken.de
PCI: Found IRQ 11 for device 00:0b.0
pcnet32: PCnet/FAST 79C971 at 0xe000, 00 60 b0 fc 62 bb
    tx_start_pt(0x0c00):~220 bytes, BCR18(9861):BurstWrEn BurstRdEn NoUFlow 
    SRAMSIZE=0x7f00, SRAM_BND=0x3f00, assigned IRQ 11.
eth0: registered as PCnet/FAST 79C971
PCI: Found IRQ 10 for device 00:0d.0
pcnet32: PCnet/FAST 79C971 at 0xe400, 00 60 b0 fc 62 40
    tx_start_pt(0x0c00):~220 bytes, BCR18(9861):BurstWrEn BurstRdEn NoUFlow 
    SRAMSIZE=0x7f00, SRAM_BND=0x3f00, assigned IRQ 10.
eth1: registered as PCnet/FAST 79C971
pcnet32: 2 cards_found.
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-ohci.c: USB OHCI at membase 0xd0800000, IRQ 12
usb-ohci.c: usb-00:01.2, Silicon Integrated Systems [SiS] 7001
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
usb.c: registered new driver serial
usbserial.c: USB Serial Driver core v1.4
usbserial.c: USB Serial support registered for PL-2303
pl2303.c: Prolific PL2303 USB to serial adaptor driver v0.9
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
ip_conntrack version 2.1 (2032 buckets, 16256 max) - 288 bytes per conntrack
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 92k freed
hub.c: new USB device 00:01.2-2, assigned address 2
usbserial.c: descriptor matches
usbserial.c: found interrupt in
usbserial.c: PL-2303 converter detected
usbserial.c: get_free_serial 1
usbserial.c: get_free_serial - minor base = 0
usbserial.c: usb_serial_probe - setting up 1 port structures for this device
usbserial.c: PL-2303 converter now attached to ttyUSB0 (or usb/tts/0 for devfs)
usbserial.c: descriptor matches
usbserial.c: found bulk out
usbserial.c: found bulk in
usbserial.c: found interrupt in for Prolific device on separate interface
usbserial.c: PL-2303 converter detected
usbserial.c: get_free_serial 1
usbserial.c: get_free_serial - minor base = 1
usbserial.c: usb_serial_probe - setting up 1 port structures for this device
usbserial.c: PL-2303 converter now attached to ttyUSB1 (or usb/tts/1 for devfs)
Sorry: masquerading timeouts set 5DAYS/2MINS/60SECS
microcode: CPU0 updated from revision 2 to 3, date=05051999
usbserial.c: serial_open
pl2303.c: pl2303_open -  port 0
pl2303.c: 0xc0:0x1:0x8484:0x0  1 - 0
pl2303.c: 0x40:0x1:0x404:0x0  0
pl2303.c: 0xc0:0x1:0x8484:0x0  1 - 0
pl2303.c: 0xc0:0x1:0x8383:0x0  1 - 7b
pl2303.c: 0xc0:0x1:0x8484:0x0  1 - 0
pl2303.c: 0x40:0x1:0x404:0x1  0
pl2303.c: 0xc0:0x1:0x8484:0x0  1 - 0
pl2303.c: 0xc0:0x1:0x8383:0x0  1 - 6
pl2303.c: 0x40:0x1:0x0:0x1  0
pl2303.c: 0x40:0x1:0x1:0xc0  0
pl2303.c: 0x40:0x1:0x2:0x4  0
pl2303.c: pl2303_set_termios -  port 0, initialized = 0
pl2303.c: 0xa1:0x21:0:0  7 - 0 0 0 0 0 0 0
pl2303.c: 0x40:1:0:1  0
pl2303.c: pl2303_set_termios - data bits = 8
pl2303.c: pl2303_set_termios - baud = 9600
pl2303.c: pl2303_set_termios - stop bits = 1
pl2303.c: pl2303_set_termios - parity = none
pl2303.c: 0x21:0x20:0:0  7
pl2303.c: set_control_lines - value = 3, retval = 0
pl2303.c: 0xa1:0x21:0:0  7 - 80 25 0 0 0 0 8
pl2303.c: pl2303_open - submitting read urb
Unable to handle kernel NULL pointer dereference at virtual address 00000010
 printing eip:
c01d8cd8
*pde = 00000000
Oops: 0002
CPU:    0
EIP:    0010:[<c01d8cd8>]    Not tainted
EFLAGS: 00010286
eax: 00000000   ebx: c1339400   ecx: 00000001   edx: c134b800
esi: c133941c   edi: 00000001   ebp: cd8f5e9c   esp: cd8f5e2c
ds: 0018   es: 0018   ss: 0018
Process minicom (pid: 117, stackpage=cd8f5000)
Stack: c02546a0 c02556d3 00000001 00000002 00000004 00000000 00000000 00000000 
       00000064 00000006 00000282 00000001 c02bd3bc 00000246 0000001c cd8f5e9c 
       c0119dd2 0000000a 00000400 c025539b cd8f5eac 00000024 00000000 00000000 
Call Trace:    [<c0119dd2>] [<c01d57bb>] [<c0178e44>] [<c01413a3>] [<c015914a>]
  [<c01378aa>] [<c0136081>] [<c0135fa6>] [<c0140953>] [<c0136351>] [<c0107417>]

Code: 89 50 10 8b 46 20 89 04 24 e8 5a e9 fe ff 85 c0 75 76 a1 80 
---dmesg ends here---
---decoded oops begins here---
ksymoops 2.4.5 on i686 2.4.19-16mdksmp.  Options used
     -v vmlinux (specified)
     -K (specified)
     -L (specified)
     -O (specified)
     -m System.map (specified)

cpu: 0, clocks: 666756, slice: 333378
Unable to handle kernel NULL pointer dereference at virtual address 00000010
c01d8cd8
*pde = 00000000
Oops: 0002
CPU:    0
EIP:    0010:[<c01d8cd8>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: 00000000   ebx: c1339400   ecx: 00000001   edx: c134b800
esi: c133941c   edi: 00000001   ebp: cd8f5e9c   esp: cd8f5e2c
ds: 0018   es: 0018   ss: 0018
Process minicom (pid: 117, stackpage=cd8f5000)
Stack: c02546a0 c02556d3 00000001 00000002 00000004 00000000 00000000 00000000 
       00000064 00000006 00000282 00000001 c02bd3bc 00000246 0000001c cd8f5e9c 
       c0119dd2 0000000a 00000400 c025539b cd8f5eac 00000024 00000000 00000000 
Call Trace:    [<c0119dd2>] [<c01d57bb>] [<c0178e44>] [<c01413a3>] [<c015914a>]
  [<c01378aa>] [<c0136081>] [<c0135fa6>] [<c0140953>] [<c0136351>] [<c0107417>]
Code: 89 50 10 8b 46 20 89 04 24 e8 5a e9 fe ff 85 c0 75 76 a1 80 


>>EIP; c01d8cd8 <pl2303_open+508/890>   <=====

>>ebx; c1339400 <END_OF_CODE+10553a8/????>
>>edx; c134b800 <END_OF_CODE+10677a8/????>
>>esi; c133941c <END_OF_CODE+10553c4/????>
>>ebp; cd8f5e9c <END_OF_CODE+d611e44/????>
>>esp; cd8f5e2c <END_OF_CODE+d611dd4/????>

Trace; c0119dd2 <printk+112/150>
Trace; c01d57bb <serial_open+fb/140>
Trace; c0178e44 <tty_open+244/3d0>
Trace; c01413a3 <link_path_walk+593/710>
Trace; c015914a <ext2_free_blocks+21a/300>
Trace; c01378aa <chrdev_open+5a/60>
Trace; c0136081 <dentry_open+d1/1e0>
Trace; c0135fa6 <filp_open+66/70>
Trace; c0140953 <getname+93/d0>
Trace; c0136351 <sys_open+51/a0>
Trace; c0107417 <system_call+33/38>

Code;  c01d8cd8 <pl2303_open+508/890>
00000000 <_EIP>:
Code;  c01d8cd8 <pl2303_open+508/890>   <=====
   0:   89 50 10                  mov    %edx,0x10(%eax)   <=====
Code;  c01d8cdb <pl2303_open+50b/890>
   3:   8b 46 20                  mov    0x20(%esi),%eax
Code;  c01d8cde <pl2303_open+50e/890>
   6:   89 04 24                  mov    %eax,(%esp,1)
Code;  c01d8ce1 <pl2303_open+511/890>
   9:   e8 5a e9 fe ff            call   fffee968 <_EIP+0xfffee968> c01c7640 <usb_submit_urb+0/50>
Code;  c01d8ce6 <pl2303_open+516/890>
   e:   85 c0                     test   %eax,%eax
Code;  c01d8ce8 <pl2303_open+518/890>
  10:   75 76                     jne    88 <_EIP+0x88> c01d8d60 <pl2303_open+590/890>
Code;  c01d8cea <pl2303_open+51a/890>
  12:   a1 80 00 00 00            mov    0x80,%eax
---decoded oops ends here---

Re: [BUG] pl2303 oops in 2.4.20-pre10 (and 2.5 too)

[Barry K. Nathan]

On Fri, Oct 11, 2002 at 10:06:23AM -0700, Greg KH wrote:
> On Thu, Oct 10, 2002 at 07:39:26PM -0700, Barry K. Nathan wrote:
> > usbserial.c: PL-2303 converter now attached to ttyUSB0 (or usb/tts/0 for devfs)
> > usbserial.c: descriptor matches
> > usbserial.c: found bulk out
> > usbserial.c: found bulk in
> > usbserial.c: found interrupt in for Prolific device on separate interface
> > usbserial.c: PL-2303 converter detected
> > usbserial.c: get_free_serial 1
> > usbserial.c: get_free_serial - minor base = 1
> > usbserial.c: usb_serial_probe - setting up 1 port structures for this device
> 
> Ick, I've always suspected the hack I added to support older pl2303
> devices that split the endpoints across different interfaces didn't
> quite work properly, and I think your post proves this.  I _really_
> recommend going and buying a newer device that does not need this hack,
> as Prolific did realize the error of their ways and fix this on newer
> versions.

I'll consider doing this.

FWIW the hack worked fine from 2.4.13pre (and maybe a bit earlier
even) through 2.4.19, and it also works in later 2.2 (haven't tried
2.2.22 yet, but 2.2.22rc1 works).

> This device should work even differently on 2.5 (as I took out this hack
> for now), so you should get a different error, right?

I haven't bothered decoding the oops, or enabling USB serial debug,
under 2.5 at this point.

That reminds me, though, at some point in the 2.5 series my PL-2303 was
getting detected twice. (I'm not sure if this still happens.) Would that
be related? (I think it started oopsing then too, but at that point in
time I had no time to report it.)

> Sorry about this, but please try to return this device and get a
> different one.

I don't think returning it is an option (I don't think it's even under
warranty anymore). It's a couple of years too late to return it to the
place of purchase, certainly.

Of course, if you can't get the driver working again or it's not worth
the effort or whatever, don't worry about it.

> That being said, I should change the driver to not oops in such a
> situation.  Can you try the patch below and let me know if it changes
> anything?

It changes stuff but it still oopses. The dmesg and decoded oops follow.

-Barry K. Nathan <barryn@pobox.com>

---dmesg begins here---
Linux version 2.4.20-pre10 (barryn@ip68-4-86-174.oc.oc.cox.net) (gcc version 3.2 (Mandrake Linux 9.0 3.2-1mdk)) #1 Fri Oct 11 17:36:32 PDT 2002
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000000fe00000 (usable)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
254MB LOWMEM available.
On node 0 totalpages: 65024
zone(0): 4096 pages.
zone(1): 60928 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=bzimage root=/dev/hda6 vga=0 
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
Initializing CPU#0
Detected 533.391 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1064.96 BogoMIPS
Memory: 254940k/260096k available (1223k kernel code, 4772k reserved, 418k data, 92k init, 0k highmem)
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 128K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU:     After generic, caps: 0183fbff 00000000 00000000 00000000
CPU:             Common caps: 0183fbff 00000000 00000000 00000000
CPU: Intel Celeron (Mendocino) stepping 05
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 533.4035 MHz.
..... host bus clock speed is 66.6753 MHz.
cpu: 0, clocks: 666753, slice: 333376
CPU0<T0:666752,T1:333376,D:0,S:333376,C:666753>
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfb640, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router SIS [1039/0008] at 00:01.0
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
IA-32 Microcode Update Driver: v1.11 <tigran@veritas.com>
Starting kswapd
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
Real Time Clock Driver v1.10e
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
SIS5513: IDE controller on PCI bus 00 dev 01
SIS5513: chipset revision 208
SIS5513: not 100% native mode: will probe irqs later
SiS620
    ide0: BM-DMA at 0x4000-0x4007, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0x4008-0x400f, BIOS settings: hdc:DMA, hdd:DMA
hda: SAMSUNG SV4084H, ATA DISK drive
hdd: CD-ROM Drive/F5E, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
blk: queue c02ddfa4, I/O limit 4095Mb (mask 0xffffffff)
hda: setmax LBA 79730784, native  62500000
hda: 62500000 sectors (32000 MB) w/426KiB Cache, CHS=3890/255/63, UDMA(66)
hdd: ATAPI 52X CD-ROM drive, 128kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
Partition check:
 hda: hda1 hda2 < hda5 hda6 hda7 >
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
loop: loaded (max 8 devices)
pcnet32.c:v1.27a 10.02.2002 tsbogend@alpha.franken.de
PCI: Found IRQ 11 for device 00:0b.0
pcnet32: PCnet/FAST 79C971 at 0xe000, 00 60 b0 fc 62 bb
    tx_start_pt(0x0c00):~220 bytes, BCR18(9861):BurstWrEn BurstRdEn NoUFlow 
    SRAMSIZE=0x7f00, SRAM_BND=0x3f00, assigned IRQ 11.
eth0: registered as PCnet/FAST 79C971
PCI: Found IRQ 10 for device 00:0d.0
pcnet32: PCnet/FAST 79C971 at 0xe400, 00 60 b0 fc 62 40
    tx_start_pt(0x0c00):~220 bytes, BCR18(9861):BurstWrEn BurstRdEn NoUFlow 
    SRAMSIZE=0x7f00, SRAM_BND=0x3f00, assigned IRQ 10.
eth1: registered as PCnet/FAST 79C971
pcnet32: 2 cards_found.
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-ohci.c: USB OHCI at membase 0xd0800000, IRQ 12
usb-ohci.c: usb-00:01.2, Silicon Integrated Systems [SiS] 7001
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
usb.c: registered new driver serial
usbserial.c: USB Serial Driver core v1.4
usbserial.c: USB Serial support registered for PL-2303
pl2303.c: Prolific PL2303 USB to serial adaptor driver v0.9
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
ip_conntrack version 2.1 (2032 buckets, 16256 max) - 288 bytes per conntrack
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 92k freed
hub.c: new USB device 00:01.2-2, assigned address 2
usbserial.c: descriptor matches
usbserial.c: found interrupt in
usbserial.c: PL-2303 converter detected
usbserial.c: get_free_serial 1
usbserial.c: get_free_serial - minor base = 0
usbserial.c: usb_serial_probe - setting up 1 port structures for this device
usbserial.c: PL-2303 converter now attached to ttyUSB0 (or usb/tts/0 for devfs)
usbserial.c: descriptor matches
usbserial.c: found bulk out
usbserial.c: found bulk in
usbserial.c: found interrupt in for Prolific device on separate interface
usbserial.c: PL-2303 converter detected
usbserial.c: get_free_serial 1
usbserial.c: get_free_serial - minor base = 1
usbserial.c: usb_serial_probe - setting up 1 port structures for this device
usbserial.c: PL-2303 converter now attached to ttyUSB1 (or usb/tts/1 for devfs)
Sorry: masquerading timeouts set 5DAYS/2MINS/60SECS
microcode: CPU0 updated from revision 2 to 3, date=05051999
usbserial.c: serial_open
pl2303.c: pl2303_open -  port 0
pl2303.c: 0xc0:0x1:0x8484:0x0  1 - 0
pl2303.c: 0x40:0x1:0x404:0x0  0
pl2303.c: 0xc0:0x1:0x8484:0x0  1 - 0
pl2303.c: 0xc0:0x1:0x8383:0x0  1 - 7b
pl2303.c: 0xc0:0x1:0x8484:0x0  1 - 0
pl2303.c: 0x40:0x1:0x404:0x1  0
pl2303.c: 0xc0:0x1:0x8484:0x0  1 - 0
pl2303.c: 0xc0:0x1:0x8383:0x0  1 - 6
pl2303.c: 0x40:0x1:0x0:0x1  0
pl2303.c: 0x40:0x1:0x1:0xc0  0
pl2303.c: 0x40:0x1:0x2:0x4  0
pl2303.c: pl2303_set_termios -  port 0, initialized = 0
pl2303.c: 0xa1:0x21:0:0  7 - 0 0 0 0 0 0 0
pl2303.c: 0x40:1:0:1  0
pl2303.c: pl2303_set_termios - data bits = 8
pl2303.c: pl2303_set_termios - baud = 9600
pl2303.c: pl2303_set_termios - stop bits = 1
pl2303.c: pl2303_set_termios - parity = none
pl2303.c: 0x21:0x20:0:0  7
pl2303.c: set_control_lines - value = 3, retval = 0
pl2303.c: 0xa1:0x21:0:0  7 - 80 25 0 0 0 0 8
pl2303.c: pl2303_open - submitting interrupt urb
usbserial.c: serial_ioctl - port 0, cmd 0x5401
pl2303.c: pl2303_ioctl (0) cmd = 0x5401
pl2303.c: pl2303_ioctl not supported = 0x5401
usbserial.c: serial_ioctl - port 0, cmd 0x5415
pl2303.c: pl2303_ioctl (0) cmd = 0x5415
pl2303.c: pl2303_ioctl (0) TIOCMGET
pl2303.c: get_modem_info - result = 6
usbserial.c: serial_ioctl - port 0, cmd 0x5401
pl2303.c: pl2303_ioctl (0) cmd = 0x5401
pl2303.c: pl2303_ioctl not supported = 0x5401
usbserial.c: serial_ioctl - port 0, cmd 0x5402
pl2303.c: pl2303_ioctl (0) cmd = 0x5402
pl2303.c: pl2303_ioctl not supported = 0x5402
usbserial.c: serial_set_termios - port 0
pl2303.c: pl2303_set_termios -  port 0, initialized = 1
pl2303.c: 0xa1:0x21:0:0  7 - 80 25 0 0 0 0 8
pl2303.c: pl2303_read_int_callback - length = 10, data = a1 20 00 00 00 00 02 00 82 00 
pl2303.c: 0x40:1:0:1  0
pl2303.c: pl2303_set_termios - data bits = 8
pl2303.c: pl2303_set_termios - baud = 230400
pl2303.c: pl2303_set_termios - stop bits = 1
pl2303.c: pl2303_set_termios - parity = none
pl2303.c: 0x21:0x20:0:0  7
pl2303.c: set_control_lines - value = 3, retval = 0
pl2303.c: 0xa1:0x21:0:0  7 - 0 84 3 0 0 0 8
usbserial.c: serial_ioctl - port 0, cmd 0x5401
pl2303.c: pl2303_ioctl (0) cmd = 0x5401
pl2303.c: pl2303_ioctl not supported = 0x5401
usbserial.c: serial_ioctl - port 0, cmd 0x5415
pl2303.c: pl2303_ioctl (0) cmd = 0x5415
pl2303.c: pl2303_ioctl (0) TIOCMGET
pl2303.c: get_modem_info - result = 6
usbserial.c: serial_ioctl - port 0, cmd 0x5418
pl2303.c: pl2303_ioctl (0) cmd = 0x5418
pl2303.c: pl2303_ioctl (0) TIOCMSET/TIOCMBIC/TIOCMSET
pl2303.c: set_control_lines - value = 3, retval = 0
usbserial.c: serial_ioctl - port 0, cmd 0x5401
pl2303.c: pl2303_ioctl (0) cmd = 0x5401
pl2303.c: pl2303_ioctl not supported = 0x5401
usbserial.c: serial_ioctl - port 0, cmd 0x5402
pl2303.c: pl2303_ioctl (0) cmd = 0x5402
pl2303.c: pl2303_ioctl not supported = 0x5402
usbserial.c: serial_set_termios - port 0
pl2303.c: pl2303_set_termios -  port 0, initialized = 1
pl2303.c: 0xa1:0x21:0:0  7 - 0 84 3 0 0 0 8
pl2303.c: 0x40:1:0:1  0
pl2303.c: pl2303_set_termios - data bits = 8
pl2303.c: pl2303_set_termios - baud = 230400
pl2303.c: pl2303_set_termios - stop bits = 1
pl2303.c: pl2303_set_termios - parity = none
pl2303.c: 0x21:0x20:0:0  7
pl2303.c: set_control_lines - value = 3, retval = 0
pl2303.c: 0xa1:0x21:0:0  7 - 0 84 3 0 0 0 8
pl2303.c: 0x40:0x1:0x0:0x41  -32
usbserial.c: serial_ioctl - port 0, cmd 0x5401
pl2303.c: pl2303_ioctl (0) cmd = 0x5401
pl2303.c: pl2303_ioctl not supported = 0x5401
usbserial.c: serial_ioctl - port 0, cmd 0x5401
pl2303.c: pl2303_ioctl (0) cmd = 0x5401
pl2303.c: pl2303_ioctl not supported = 0x5401
usbserial.c: serial_ioctl - port 0, cmd 0x5402
pl2303.c: pl2303_ioctl (0) cmd = 0x5402
pl2303.c: pl2303_ioctl not supported = 0x5402
usbserial.c: serial_set_termios - port 0
pl2303.c: pl2303_set_termios -  port 0, initialized = 1
pl2303.c: pl2303_set_termios - nothing to change...
usbserial.c: serial_ioctl - port 0, cmd 0x5401
pl2303.c: pl2303_ioctl (0) cmd = 0x5401
pl2303.c: pl2303_ioctl not supported = 0x5401
usbserial.c: serial_ioctl - port 0, cmd 0x5401
pl2303.c: pl2303_ioctl (0) cmd = 0x5401
pl2303.c: pl2303_ioctl not supported = 0x5401
usbserial.c: serial_ioctl - port 0, cmd 0x5402
pl2303.c: pl2303_ioctl (0) cmd = 0x5402
pl2303.c: pl2303_ioctl not supported = 0x5402
usbserial.c: serial_set_termios - port 0
pl2303.c: pl2303_set_termios -  port 0, initialized = 1
pl2303.c: pl2303_set_termios - nothing to change...
usbserial.c: serial_ioctl - port 0, cmd 0x5401
pl2303.c: pl2303_ioctl (0) cmd = 0x5401
pl2303.c: pl2303_ioctl not supported = 0x5401
usbserial.c: serial_ioctl - port 0, cmd 0x540b
pl2303.c: pl2303_ioctl (0) cmd = 0x540b
pl2303.c: pl2303_ioctl not supported = 0x540b
usbserial.c: serial_ioctl - port 0, cmd 0x5401
pl2303.c: pl2303_ioctl (0) cmd = 0x5401
pl2303.c: pl2303_ioctl not supported = 0x5401
usbserial.c: serial_ioctl - port 0, cmd 0x5401
pl2303.c: pl2303_ioctl (0) cmd = 0x5401
pl2303.c: pl2303_ioctl not supported = 0x5401
usbserial.c: serial_ioctl - port 0, cmd 0x5402
pl2303.c: pl2303_ioctl (0) cmd = 0x5402
pl2303.c: pl2303_ioctl not supported = 0x5402
usbserial.c: serial_set_termios - port 0
pl2303.c: pl2303_set_termios -  port 0, initialized = 1
pl2303.c: 0xa1:0x21:0:0  7 - 0 84 3 0 0 0 8
pl2303.c: 0x40:1:0:1  0
pl2303.c: pl2303_set_termios - data bits = 8
pl2303.c: pl2303_set_termios - baud = 0
pl2303.c: pl2303_set_termios - stop bits = 1
pl2303.c: pl2303_set_termios - parity = none
pl2303.c: 0x21:0x20:0:0  7
pl2303.c: set_control_lines - value = 3, retval = 0
pl2303.c: 0xa1:0x21:0:0  7 - 0 84 3 0 0 0 8
pl2303.c: 0x40:0x1:0x0:0x41  -32
usbserial.c: serial_ioctl - port 0, cmd 0x5401
pl2303.c: pl2303_ioctl (0) cmd = 0x5401
pl2303.c: pl2303_ioctl not supported = 0x5401
usbserial.c: serial_ioctl - port 0, cmd 0x5402
pl2303.c: pl2303_ioctl (0) cmd = 0x5402
pl2303.c: pl2303_ioctl not supported = 0x5402
usbserial.c: serial_set_termios - port 0
pl2303.c: pl2303_set_termios -  port 0, initialized = 1
pl2303.c: 0xa1:0x21:0:0  7 - 0 84 3 0 0 0 8
pl2303.c: 0x40:1:0:1  0
pl2303.c: pl2303_set_termios - data bits = 8
pl2303.c: pl2303_set_termios - baud = 230400
pl2303.c: pl2303_set_termios - stop bits = 1
pl2303.c: pl2303_set_termios - parity = none
pl2303.c: 0x21:0x20:0:0  7
pl2303.c: set_control_lines - value = 3, retval = 0
pl2303.c: 0xa1:0x21:0:0  7 - 0 84 3 0 0 0 8
pl2303.c: 0x40:0x1:0x0:0x41  -32
usbserial.c: serial_ioctl - port 0, cmd 0x5401
pl2303.c: pl2303_ioctl (0) cmd = 0x5401
pl2303.c: pl2303_ioctl not supported = 0x5401
usbserial.c: serial_write - port 0, 1 byte(s)
pl2303.c: pl2303_write - port 0, 1 bytes
Unable to handle kernel NULL pointer dereference at virtual address 00000018
 printing eip:
c01d7eb3
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c01d7eb3>]    Not tainted
EFLAGS: 00010282
eax: 0000002c   ebx: 00000001   ecx: c133941c   edx: 00000000
esi: bffff5ab   edi: 00000001   ebp: cd94bec8   esp: cd94beac
ds: 0018   es: 0018   ss: 0018
Process minicom (pid: 111, stackpage=cd94b000)
Stack: c0254240 c0255670 00000000 00000001 c133941c c1339474 c1339400 cd94bef0 
       c01d5a4c c133941c 00000001 bffff5ab 00000001 ffffffea 00000001 bffff5ab 
       cd8cf000 cd94bf40 c017c138 cd8cf000 00000001 bffff5ab 00000001 cd94a000 
Call Trace:    [<c01d5a4c>] [<c017c138>] [<c017a732>] [<c017800d>] [<c017bf50>]
  [<c0136f5c>] [<c0107417>]

Code: 83 7a 18 8d 0f 84 18 01 00 00 8b 4d 08 8b 41 2c 8b 4d 0c 39 
---dmesg ends here---
---decoded oops begins here---
ksymoops 2.4.5 on i686 2.4.19-16mdksmp.  Options used
     -v vmlinux (specified)
     -K (specified)
     -L (specified)
     -O (specified)
     -m System.map (specified)

cpu: 0, clocks: 666753, slice: 333376
Unable to handle kernel NULL pointer dereference at virtual address 00000018
c01d7eb3
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c01d7eb3>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax: 0000002c   ebx: 00000001   ecx: c133941c   edx: 00000000
esi: bffff5ab   edi: 00000001   ebp: cd94bec8   esp: cd94beac
ds: 0018   es: 0018   ss: 0018
Process minicom (pid: 111, stackpage=cd94b000)
Stack: c0254240 c0255670 00000000 00000001 c133941c c1339474 c1339400 cd94bef0 
       c01d5a4c c133941c 00000001 bffff5ab 00000001 ffffffea 00000001 bffff5ab 
       cd8cf000 cd94bf40 c017c138 cd8cf000 00000001 bffff5ab 00000001 cd94a000 
Call Trace:    [<c01d5a4c>] [<c017c138>] [<c017a732>] [<c017800d>] [<c017bf50>]
  [<c0136f5c>] [<c0107417>]
Code: 83 7a 18 8d 0f 84 18 01 00 00 8b 4d 08 8b 41 2c 8b 4d 0c 39 


>>EIP; c01d7eb3 <pl2303_write+23/1a0>   <=====

>>ecx; c133941c <END_OF_CODE+10553c4/????>
>>esi; bffff5ab Before first symbol
>>ebp; cd94bec8 <END_OF_CODE+d667e70/????>
>>esp; cd94beac <END_OF_CODE+d667e54/????>

Trace; c01d5a4c <serial_write+dc/140>
Trace; c017c138 <write_chan+1e8/210>
Trace; c017a732 <do_tty_write+d2/125>
Trace; c017800d <tty_write+ed/120>
Trace; c017bf50 <write_chan+0/210>
Trace; c0136f5c <sys_write+9c/130>
Trace; c0107417 <system_call+33/38>

Code;  c01d7eb3 <pl2303_write+23/1a0>
00000000 <_EIP>:
Code;  c01d7eb3 <pl2303_write+23/1a0>   <=====
   0:   83 7a 18 8d               cmpl   $0xffffff8d,0x18(%edx)   <=====
Code;  c01d7eb7 <pl2303_write+27/1a0>
   4:   0f 84 18 01 00 00         je     122 <_EIP+0x122> c01d7fd5 <pl2303_write+145/1a0>
Code;  c01d7ebd <pl2303_write+2d/1a0>
   a:   8b 4d 08                  mov    0x8(%ebp),%ecx
Code;  c01d7ec0 <pl2303_write+30/1a0>
   d:   8b 41 2c                  mov    0x2c(%ecx),%eax
Code;  c01d7ec3 <pl2303_write+33/1a0>
  10:   8b 4d 0c                  mov    0xc(%ebp),%ecx
Code;  c01d7ec6 <pl2303_write+36/1a0>
  13:   39 00                     cmp    %eax,(%eax)
---decoded oops ends here---

Re: [BUG] pl2303 oops in 2.4.20-pre10 (and 2.5 too)

[Barry K. Nathan]

The following patch (which reverts part of 2.4.20-pre2) seems to fix my
pl2303 oopsing (and let me use the device properly again) in 2.4.20-pre2
through -pre5. This patch doesn't work with -pre6 or up though (due to
white space differences and, more importantly, the removal of all 6
variables referenced in the if-statement).

Anyway, I'm posting this in case it provides another clue as to what's
not working.

-Barry K. Nathan <barryn@pobox.com>

--- linux-2.4.20-pre2/drivers/usb/serial/usbserial.c	2002-10-12 00:09:35.000000000 -0700
+++ linux-2.4.20-pre1/drivers/usb/serial/usbserial.c	2002-01-22 13:22:58.000000000 -0800
@@ -1161,6 +1161,15 @@
 	/* END HORRIBLE HACK FOR PL2303 */
 #endif
 	
+	/* verify that we found all of the endpoints that we need */
+	if (!((interrupt_pipe & type->needs_interrupt_in) &&
+	      (bulk_in_pipe & type->needs_bulk_in) &&
+	      (bulk_out_pipe & type->needs_bulk_out))) {
+		/* nope, they don't match what we expected */
+		info("descriptors matched, but endpoints did not");
+		return NULL;
+	}
+
 	/* found all that we need */
 	info("%s converter detected", type->name);
 

[PATCH] 2.4.20-pre10: make PL-2303 hack work again

[Barry K. Nathan]

The following patch allows the PL-2303 hack to work again. It applies
to and has been tested with 2.4.20-pre10. Testing included using an ISDN
"modem" connected to the PL-2303 to do some web browsing and some
downloads (including a gzipped Linux 2.5.42 tarball).

The patch resurrects a sanity check (or so it appears to me) which was
removed in 2.4.20-pre2. However, the new version of the check is
contained within the PL-2303 hack #ifdef's, and it no longer relies on
variables like interrupt_pipe which have been removed from the USB
serial code.

Given that 2.4.19 works with my PL-2303 and 2.4 is supposed to be a
"stable" series, I'd appreciate if this patch (or another which fixes my
problem) could be merged. If this patch needs improvements first, please
let me know.

-Barry K. Nathan <barryn@pobox.com>

diff -ru linux-2.4.20-pre10/drivers/usb/serial/usbserial.c linux-2.4.20-pre10-bkn4/drivers/usb/serial/usbserial.c
--- linux-2.4.20-pre10/drivers/usb/serial/usbserial.c	2002-09-26 02:23:00.000000000 -0700
+++ linux-2.4.20-pre10-bkn4/drivers/usb/serial/usbserial.c	2002-10-12 17:21:00.000000000 -0700
@@ -1182,11 +1182,11 @@
 #if defined(CONFIG_USB_SERIAL_PL2303) || defined(CONFIG_USB_SERIAL_PL2303_MODULE)
 	/* BEGIN HORRIBLE HACK FOR PL2303 */ 
 	/* this is needed due to the looney way its endpoints are set up */
-	if (ifnum == 1) {
-		if (((dev->descriptor.idVendor == PL2303_VENDOR_ID) &&
-		     (dev->descriptor.idProduct == PL2303_PRODUCT_ID)) ||
-		    ((dev->descriptor.idVendor == ATEN_VENDOR_ID) &&
-		     (dev->descriptor.idProduct == ATEN_PRODUCT_ID))) {
+	if (((dev->descriptor.idVendor == PL2303_VENDOR_ID) &&
+	     (dev->descriptor.idProduct == PL2303_PRODUCT_ID)) ||
+	    ((dev->descriptor.idVendor == ATEN_VENDOR_ID) &&
+	     (dev->descriptor.idProduct == ATEN_PRODUCT_ID))) {
+		if (ifnum == 1) {
 			/* check out the endpoints of the other interface*/
 			interface = &dev->actconfig->interface[ifnum ^ 1];
 			iface_desc = &interface->altsetting[0];
@@ -1201,6 +1201,15 @@
 				}
 			}
 		}
+
+		/* Now make sure the PL-2303 is configured correctly.
+		 * If not, give up now and hope this hack will work
+		 * properly during a later invocation of usb_serial_probe
+		 */
+		if (num_bulk_in == 0 || num_bulk_out == 0) {
+			info("PL-2303 hack: descriptors matched but endpoints did not");
+			return NULL;
+		}
 	}
 	/* END HORRIBLE HACK FOR PL2303 */
 #endif
Only in linux-2.4.20-pre10-bkn4/drivers/usb/serial: usbserial.c~

Re: [PATCH] 2.4.20-pre10: make PL-2303 hack work again

[Greg KH]

On Sat, Oct 12, 2002 at 05:42:49PM -0700, Barry K. Nathan wrote:
> The following patch allows the PL-2303 hack to work again. It applies
> to and has been tested with 2.4.20-pre10. Testing included using an ISDN
> "modem" connected to the PL-2303 to do some web browsing and some
> downloads (including a gzipped Linux 2.5.42 tarball).
> 
> The patch resurrects a sanity check (or so it appears to me) which was
> removed in 2.4.20-pre2. However, the new version of the check is
> contained within the PL-2303 hack #ifdef's, and it no longer relies on
> variables like interrupt_pipe which have been removed from the USB
> serial code.
> 
> Given that 2.4.19 works with my PL-2303 and 2.4 is supposed to be a
> "stable" series, I'd appreciate if this patch (or another which fixes my
> problem) could be merged. If this patch needs improvements first, please
> let me know.

Sweet, nice job, I like it.  I'll go add this to my kernel trees and
send it to Marcelo.

Thanks for finding and fixing this.

Now, would you mind taking a look at 2.5, and fixing this there too? :)

thanks,

greg k-h

Re: [PATCH] 2.4.20-pre10: make PL-2303 hack work again

[Barry K. Nathan]

On Sat, Oct 12, 2002 at 06:16:44PM -0700, Greg KH wrote:
> Sweet, nice job, I like it.  I'll go add this to my kernel trees and
> send it to Marcelo.
> 
> Thanks for finding and fixing this.

You're welcome.

> Now, would you mind taking a look at 2.5, and fixing this there too? :)

I'm taking a look now...

-Barry K. Nathan <barryn@pobox.com>

[PATCH/RFC] 2.5.42 partial fix for older pl2303

[Barry K. Nathan]

On Sat, Oct 12, 2002 at 06:16:44PM -0700, Greg KH wrote:
[snip stuff regarding pl2303 on 2.4.20-pre]
> Now, would you mind taking a look at 2.5, and fixing this there too? :)

Here's a half-successful attempt. With this patch, the device no longer
appears twice, and it always works on the first open (at least, so I've
observed up to this point). The open following a successful open usually
fails (roughly speaking, it appears to play dead), and the open following
a failed open usually (always?) succeeds.

So, on my PL-2303, it's not perfect but it's certainly livable.

This patch is based on the one I did for 2.4, and in fact, this code
functions when it's plugged into 2.4.20-pre10 instead of 2.5.42. In that
scenario, the opens work 100% of the time.

I'd be interested in suggestions or comments regarding this patch.
Anyone who has a PL-2303 working under 2.5 might want to try this patch
just to make sure it doesn't kill their working setup.

-Barry K. Nathan <barryn@pobox.com>

diff -ur linux-2.5.42/drivers/usb/serial/usb-serial.c linux-2.5.42-bkn1/drivers/usb/serial/usb-serial.c
--- linux-2.5.42/drivers/usb/serial/usb-serial.c	2002-10-12 20:13:30.000000000 -0700
+++ linux-2.5.42-bkn1/drivers/usb/serial/usb-serial.c	2002-10-12 20:22:02.000000000 -0700
@@ -1237,16 +1237,18 @@
 	}
 
 #if defined(CONFIG_USB_SERIAL_PL2303) || defined(CONFIG_USB_SERIAL_PL2303_MODULE)
-#if 0
+#if 1
 	/* BEGIN HORRIBLE HACK FOR PL2303 */ 
 	/* this is needed due to the looney way its endpoints are set up */
-	if (ifnum == 1) {
-		if (((dev->descriptor.idVendor == PL2303_VENDOR_ID) &&
-		     (dev->descriptor.idProduct == PL2303_PRODUCT_ID)) ||
-		    ((dev->descriptor.idVendor == ATEN_VENDOR_ID) &&
-		     (dev->descriptor.idProduct == ATEN_PRODUCT_ID))) {
+	if (((dev->descriptor.idVendor == PL2303_VENDOR_ID) &&
+	     (dev->descriptor.idProduct == PL2303_PRODUCT_ID)) ||
+	    ((dev->descriptor.idVendor == ATEN_VENDOR_ID) &&
+	     (dev->descriptor.idProduct == ATEN_PRODUCT_ID))) {
+		//if (ifnum == 1) {
+		if (interface != &dev->actconfig->interface[0]) {
 			/* check out the endpoints of the other interface*/
-			interface = &dev->actconfig->interface[ifnum ^ 1];
+			//interface = &dev->actconfig->interface[ifnum ^ 1];
+			interface = &dev->actconfig->interface[0];
 			iface_desc = &interface->altsetting[0];
 			for (i = 0; i < iface_desc->bNumEndpoints; ++i) {
 				endpoint = &iface_desc->endpoint[i];
@@ -1259,6 +1261,15 @@
 				}
 			}
 		}
+
+		/* Now make sure the PL-2303 is configured correctly.
+		 * If not, give up now and hope this hack will work
+		 * properly during a later invocation of usb_serial_probe
+		 */
+		if (num_bulk_in == 0 || num_bulk_out == 0) {
+			info("PL-2303 hack: descriptors matched but endpoints did not");
+			return NULL;
+		}
 	}
 	/* END HORRIBLE HACK FOR PL2303 */
 #endif
Only in linux-2.5.42-bkn1/drivers/usb/serial: usb-serial.c~

Re: [PATCH/RFC] 2.5.42 partial fix for older pl2303

[Greg KH]

On Sat, Oct 12, 2002 at 09:30:08PM -0700, Barry K. Nathan wrote:
> On Sat, Oct 12, 2002 at 06:16:44PM -0700, Greg KH wrote:
> [snip stuff regarding pl2303 on 2.4.20-pre]
> > Now, would you mind taking a look at 2.5, and fixing this there too? :)
> 
> Here's a half-successful attempt. With this patch, the device no longer
> appears twice, and it always works on the first open (at least, so I've
> observed up to this point). The open following a successful open usually
> fails (roughly speaking, it appears to play dead), and the open following
> a failed open usually (always?) succeeds.
> 
> So, on my PL-2303, it's not perfect but it's certainly livable.
> 
> This patch is based on the one I did for 2.4, and in fact, this code
> functions when it's plugged into 2.4.20-pre10 instead of 2.5.42. In that
> scenario, the opens work 100% of the time.
> 
> I'd be interested in suggestions or comments regarding this patch.
> Anyone who has a PL-2303 working under 2.5 might want to try this patch
> just to make sure it doesn't kill their working setup.

Nice, I've added this to my tree.  I also made the following patch, to
fix up the proper return value for the probe() call, and fix a memory
leak.

Let me know if this patch causes any problems for you.

thanks,

greg k-h


diff -Nru a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
--- a/drivers/usb/serial/usb-serial.c	Sun Oct 13 13:35:48 2002
+++ b/drivers/usb/serial/usb-serial.c	Sun Oct 13 13:35:48 2002
@@ -1249,7 +1249,6 @@
 	}
 
 #if defined(CONFIG_USB_SERIAL_PL2303) || defined(CONFIG_USB_SERIAL_PL2303_MODULE)
-#if 1
 	/* BEGIN HORRIBLE HACK FOR PL2303 */ 
 	/* this is needed due to the looney way its endpoints are set up */
 	if (((dev->descriptor.idVendor == PL2303_VENDOR_ID) &&
@@ -1280,11 +1279,11 @@
 		 */
 		if (num_bulk_in == 0 || num_bulk_out == 0) {
 			info("PL-2303 hack: descriptors matched but endpoints did not");
-			return NULL;
+			kfree (serial);
+			return -ENODEV;
 		}
 	}
 	/* END HORRIBLE HACK FOR PL2303 */
-#endif
 #endif
 
 	/* found all that we need */

Re: [PATCH/RFC] 2.5.42 partial fix for older pl2303

[Barry K. Nathan]

On Sun, Oct 13, 2002 at 01:25:04PM -0700, Greg KH wrote:
> Nice, I've added this to my tree.  I also made the following patch, to
> fix up the proper return value for the probe() call, and fix a memory
> leak.
> 
> Let me know if this patch causes any problems for you.

On the contrary, the percentage of non-working PL-2303 opens has now
gone from 50% to somewhere in the 5-15% range (rough guess). IOW, it's
working better than my previous patch.

FWIW, I'm seeing some "sleeping function called from illegal context"
oopses, but I didn't see if those were happening with my old patch. I'll
test with your latest batch of USB changes later (after they get merged
by Linus, most likely).

-Barry K. Nathan <barryn@pobox.com>

Re: [PATCH/RFC] 2.5.42 partial fix for older pl2303

[Barry K. Nathan]

On Sun, Oct 13, 2002 at 07:49:30PM -0700, Barry K. Nathan wrote:
> On the contrary, the percentage of non-working PL-2303 opens has now
> gone from 50% to somewhere in the 5-15% range (rough guess). IOW, it's
> working better than my previous patch.
> 
> FWIW, I'm seeing some "sleeping function called from illegal context"
> oopses, but I didn't see if those were happening with my old patch. I'll
> test with your latest batch of USB changes later (after they get merged
> by Linus, most likely).

After applying the cset-1.782-to-1.850.txt.gz from
kernel.org/pub/linux/kernel/people/dwmw2/bk-2.5/ I'm still having the
intermittent problems with the PL-2303 playing dead, and I got this
message once after boot (I think I had two times after boot that the
device seemed dead, FWIW):
drivers/usb/host/ohci-q.c: 00:01.2 bad entry  fb041c0

followed by tons of these oopses (I think it's one per LCP echo
request/reply pair on my PPP connection but I'm not sure):

Debug: sleeping function called from illegal context at
include/asm/semaphore.h:119
Call Trace:
 [<c02095f7>] serial_write+0x77/0x170
 [<c01da4e8>] ppp_async_push+0x138/0x1c0
 [<c01da3a5>] ppp_async_send+0x45/0x50
 [<c01d674e>] ppp_channel_push+0x7e/0x1a0
 [<c01d548d>] ppp_write+0xfd/0x130
 [<c013d67d>] vfs_write+0xcd/0x140
 [<c013d78c>] sys_write+0x3c/0x60
 [<c01075cb>] syscall_call+0x7/0xb

Also, I just tried unplugging and replugging my PL-2303. It gets changed
to ttyUSB1, ttyUSB2, etc. each time. (The removal of the PL-2303 seems
to be detected each time, judging by what I could figure out from the
logs, though.) Attempts to use it at the new device node work.

Attempts to use it at the old device node result in the user program
hanging or waiting for a response (I didn't look at things too closely
so I'm not exactly sure what's going on), and another ...ohci-q.c...bad
entry message (but no oops) is emitted when the program in question is
killed.

Under 2.4.20-pre10 + my 2.4 fix, the device always gets ttyUSB0, and
always works there.

All of this was with USB serial verbose debug disabled. I can try again
with it enabled, or try again with any other patches/suggestions, if it
would help figure out what's going on.

-Barry K. Nathan <barryn@pobox.com>

Re: [PATCH/RFC] 2.5.42 partial fix for older pl2303

[Greg KH]

On Sun, Oct 13, 2002 at 09:17:56PM -0700, Barry K. Nathan wrote:
> 
> followed by tons of these oopses (I think it's one per LCP echo
> request/reply pair on my PPP connection but I'm not sure):
> 
> Debug: sleeping function called from illegal context at
> include/asm/semaphore.h:119
> Call Trace:
>  [<c02095f7>] serial_write+0x77/0x170
>  [<c01da4e8>] ppp_async_push+0x138/0x1c0
>  [<c01da3a5>] ppp_async_send+0x45/0x50
>  [<c01d674e>] ppp_channel_push+0x7e/0x1a0
>  [<c01d548d>] ppp_write+0xfd/0x130
>  [<c013d67d>] vfs_write+0xcd/0x140
>  [<c013d78c>] sys_write+0x3c/0x60
>  [<c01075cb>] syscall_call+0x7/0xb

Heh, I didn't think that serial_write() would sleep, but I know the
pl2303 driver could have this problem.  But it's just a warning, I know
the usb-serial drivers have some issues regarding PPP.  Check the lkml
archives for a discussion about this only a week or so ago.

> Under 2.4.20-pre10 + my 2.4 fix, the device always gets ttyUSB0, and
> always works there.

Glad this is working.

thanks,

greg k-h

Re: [BUG] pl2303 oops in 2.4.20-pre10 (and 2.5 too)

[Greg KH]

On Sat, Oct 12, 2002 at 01:56:04PM -0700, Barry K. Nathan wrote:
> The following patch (which reverts part of 2.4.20-pre2) seems to fix my
> pl2303 oopsing (and let me use the device properly again) in 2.4.20-pre2
> through -pre5. This patch doesn't work with -pre6 or up though (due to
> white space differences and, more importantly, the removal of all 6
> variables referenced in the if-statement).
> 
> Anyway, I'm posting this in case it provides another clue as to what's
> not working.

Ah, thanks for finding this.  Yes this does help, a bit.  Hm.  What /dev
device are you trying to write to, ttyUSB0 or ttyUSB1?  Yeah, I think we
need this kind of check back in to fix this problem, but I don't see off
the top of my head how to add it back...

And yes, the problem in 2.5 where you see the device register itself
twice is a known bug (to me at least), it goes away if you disable
CONFIG_USB_SERIAL_GENERIC.  It's on my TODO list, which seems to be
getting longer every day...

Any suggestions on how to fix this are appreciated.  Basically we don't
want to claim the interface that only has the interrupt endpoint on it
for this device, as we kinda already did in the section entitled END
HORRIBLE HACK FOR PL2303.  I guess we could just mark that interface as
claimed already, and then probe() would not get called again.  Want to
throw a call to usb_driver_claim_interface() into that section, grabbing
that interface, and see if that works?

thanks,

greg k-h

Re: [BUG] pl2303 oops in 2.4.20-pre10 (and 2.5 too)

[Barry K. Nathan]

(I didn't see this e-mail when I sent my [PATCH] that seems to work.)

On Sat, Oct 12, 2002 at 05:49:39PM -0700, Greg KH wrote:
> On Sat, Oct 12, 2002 at 01:56:04PM -0700, Barry K. Nathan wrote:
> Ah, thanks for finding this.  Yes this does help, a bit.  Hm.  What /dev
> device are you trying to write to, ttyUSB0 or ttyUSB1?  Yeah, I think we
> need this kind of check back in to fix this problem, but I don't see off
> the top of my head how to add it back...

/dev/ttyUSB0

> And yes, the problem in 2.5 where you see the device register itself
> twice is a known bug (to me at least), it goes away if you disable
> CONFIG_USB_SERIAL_GENERIC.  It's on my TODO list, which seems to be
> getting longer every day...

No, it doesn't go away in 2.5 if I disable CONFIG_USB_SERIAL_GENERIC (I
just checked).

> Any suggestions on how to fix this are appreciated.  Basically we don't
> want to claim the interface that only has the interrupt endpoint on it
> for this device, as we kinda already did in the section entitled END
> HORRIBLE HACK FOR PL2303.  I guess we could just mark that interface as
> claimed already, and then probe() would not get called again.  Want to
> throw a call to usb_driver_claim_interface() into that section, grabbing
> that interface, and see if that works?

If I have time today I'll try that.

-Barry K. Nathan <barryn@pobox.com>