PL2303 is used to connect the serial console on a classic serial port
of a test machine. HW nandshaking is used
The test machine reboots once a minute and dumps lots of messages
Frequently:
- driver hangs
- userspace (cu) can't be stopped
- pl2303 and/or usbserial can't be unloaded
- USB interrupts stop
- problems result in requiring a reboot.
- None of these problems seen before fixes such as "send break"
(which works) were made
- Feels like buffer heads get out of synch at times
- Changing Baudrates from 115200 to 38400 or 9600 has no effect
- It seems to be worse than ever even with oopses _now_ as it
has been used for many months and none were seen
- 2.4.21,22 behave essentially the same
Regards
Michael
Aug 31 11:39:40 mhfl2 kernel: Linux version 2.6.0-test4-mhf60 (mhf@mhfl4) (gcc version 2.95.3 20010315 (release)) #5 Sun Aug 31 09:37:06 HKT 2003
[]
Sep 1 18:24:01 mhfl2 kernel: drivers/usb/core/usb.c: registered new driver usbfs
Sep 1 18:24:01 mhfl2 kernel: drivers/usb/core/usb.c: registered new driver hub
Sep 1 18:24:02 mhfl2 kernel: ohci-hcd 0000:00:14.0: OHCI Host Controller
Sep 1 18:24:02 mhfl2 kernel: ohci-hcd 0000:00:14.0: irq 11, pci mem cf8a4000
Sep 1 18:24:02 mhfl2 kernel: ohci-hcd 0000:00:14.0: new USB bus registered, assigned bus number 1
Sep 1 18:24:02 mhfl2 kernel: usb usb1: Product: OHCI Host Controller
Sep 1 18:24:02 mhfl2 kernel: usb usb1: Manufacturer: Linux 2.6.0-test4-mhf60 ohci-hcd
Sep 1 18:24:02 mhfl2 kernel: usb usb1: SerialNumber: 0000:00:14.0
Sep 1 18:24:02 mhfl2 kernel: hub 1-0:0: USB hub found
Sep 1 18:24:02 mhfl2 kernel: hub 1-0:0: 2 ports detected
Sep 1 18:24:03 mhfl2 kernel: SCSI subsystem initialized
Sep 1 18:24:03 mhfl2 kernel: hub 1-0:0: debounce: port 2: delay 100ms stable 4 status 0x101
Sep 1 18:24:03 mhfl2 kernel: hub 1-0:0: new USB device on port 2, assigned address 2
Sep 1 18:24:03 mhfl2 kernel: Initializing USB Mass Storage driver...
Sep 1 18:24:03 mhfl2 kernel: drivers/usb/core/usb.c: registered new driver usb-storage
Sep 1 18:24:03 mhfl2 kernel: USB Mass Storage support registered.
Sep 1 18:24:03 mhfl2 kernel: drivers/usb/serial/usb-serial.c: USB Serial support registered for Generic
Sep 1 18:24:03 mhfl2 kernel: drivers/usb/core/usb.c: registered new driver usbserial
Sep 1 18:24:03 mhfl2 kernel: drivers/usb/serial/usb-serial.c: USB Serial Driver core v2.0
Sep 1 18:24:03 mhfl2 kernel: drivers/usb/serial/usb-serial.c: USB Serial support registered for PL-2303
Sep 1 18:24:03 mhfl2 kernel: pl2303 1-2:0: PL-2303 converter detected
Sep 1 18:24:03 mhfl2 kernel: usb 1-2: PL-2303 converter now attached to ttyUSB0 (or usb/tts/0 for devfs)
Sep 1 18:24:03 mhfl2 kernel: drivers/usb/core/usb.c: registered new driver pl2303
Sep 1 18:24:03 mhfl2 kernel: drivers/usb/serial/pl2303.c: Prolific PL2303 USB to serial adaptor driver v0.10
Sep 1 18:24:04 mhfl2 kernel: lp: driver loaded but no devices found
Sep 1 18:24:21 mhfl2 rpc.mountd: authenticated unmount request from mhfl4:997 for / (/)
Sep 1 18:27:43 mhfl2 httpd: httpd startup succeeded
Sep 1 10:39:48 mhfl2 named[446]: no longer listening on 203.151.225.157#53
Sep 1 18:42:46 mhfl2 kernel: usb 1-2: USB disconnect, address 2
Sep 1 18:42:46 mhfl2 kernel: usb 1-2: pl2303_write_bulk_callback - failed resubmitting write urb, error -19
Sep 1 18:42:46 mhfl2 kernel: pl2303 1-2:0: device disconnected
Sep 1 18:42:50 mhfl2 kernel: drivers/usb/core/usb.c: deregistering driver usb-storage
Sep 1 18:42:50 mhfl2 kernel: ohci-hcd 0000:00:14.0: remove, state 3
Sep 1 18:42:50 mhfl2 kernel: usb usb1: USB disconnect, address 1
Sep 1 18:42:50 mhfl2 kernel: ohci-hcd 0000:00:14.0: USB bus 1 deregistered
Sep 1 18:43:06 mhfl2 kernel: PL-2303 ttyUSB0: PL-2303 converter now disconnected from ttyUSB0
Sep 1 18:43:06 mhfl2 kernel: Unable to handle kernel paging request at virtual address cf8b61a8
Sep 1 18:43:06 mhfl2 kernel: printing eip:
Sep 1 18:43:06 mhfl2 kernel: cf890d94
Sep 1 18:43:06 mhfl2 kernel: *pde = 012b4067
Sep 1 18:43:06 mhfl2 kernel: *pte = 00000000
Sep 1 18:43:06 mhfl2 kernel: Oops: 0000 [#1]
Sep 1 18:43:06 mhfl2 kernel: CPU: 0
Sep 1 18:43:06 mhfl2 kernel: EIP: 0060:[<cf890d94>] Not tainted
Sep 1 18:43:06 mhfl2 kernel: EFLAGS: 00010282
Sep 1 18:43:06 mhfl2 kernel: EIP is at hcd_pci_release+0x14/0x20 [usbcore]
Sep 1 18:43:06 mhfl2 kernel: eax: cf8b6180 ebx: c0396ec0 ecx: cf8a0240 edx: c8d0e634
Sep 1 18:43:06 mhfl2 kernel: esi: 00000001 edi: cb3abf00 ebp: cb667de4 esp: cb667de0
Sep 1 18:43:06 mhfl2 kernel: ds: 007b es: 007b ss: 0068
Sep 1 18:43:06 mhfl2 kernel: Process cu (pid: 6269, threadinfo=cb666000 task=c7e39900)
Sep 1 18:43:06 mhfl2 kernel: Stack: c8d0e634 cb667df0 cf88d3c6 c8d0e634 cb667dfc c0233360 c8d0e67c cb667e0c
Sep 1 18:43:06 mhfl2 kernel: c01d2498 c8d0e684 ca0a7400 cb667e18 c01d24ca c8d0e684 cb667e24 c02336cf
Sep 1 18:43:06 mhfl2 kernel: c8d0e684 cb667e30 cf88d3ab c8d0e67c cb667e44 cf8897ee c8d0e634 ca0a7400
Sep 1 18:43:06 mhfl2 kernel: Call Trace:
Sep 1 18:43:06 mhfl2 kernel: [<cf88d3c6>] usb_host_release+0x16/0x1c [usbcore]
Sep 1 18:43:06 mhfl2 kernel: [<c0233360>] class_dev_release+0x18/0x50
Sep 1 18:43:06 mhfl2 kernel: [<c01d2498>] kobject_cleanup+0x28/0x44
Sep 1 18:43:06 mhfl2 kernel: [<c01d24ca>] kobject_put+0x16/0x1c
Sep 1 18:43:06 mhfl2 kernel: [<c02336cf>] class_device_put+0xf/0x14
Sep 1 18:43:06 mhfl2 kernel: [<cf88d3ab>] usb_bus_put+0x13/0x18 [usbcore]
Sep 1 18:43:06 mhfl2 kernel: [<cf8897ee>] usb_release_dev+0x3a/0x48 [usbcore]
Sep 1 18:43:06 mhfl2 kernel: [<c0231b0a>] device_release+0x16/0x50
Sep 1 18:43:06 mhfl2 kernel: [<c01d2498>] kobject_cleanup+0x28/0x44
Sep 1 18:43:06 mhfl2 kernel: [<c01d24ca>] kobject_put+0x16/0x1c
Sep 1 18:43:06 mhfl2 kernel: [<c0231ddb>] put_device+0xf/0x14
Sep 1 18:43:06 mhfl2 kernel: [<cf889931>] usb_put_dev+0x15/0x1c [usbcore]
Sep 1 18:43:06 mhfl2 kernel: [<cf9100b6>] destroy_serial+0x16e/0x180 [usbserial]
Sep 1 18:43:06 mhfl2 kernel: [<c01d2498>] kobject_cleanup+0x28/0x44
Sep 1 18:43:06 mhfl2 kernel: [<c01d24ca>] kobject_put+0x16/0x1c
Sep 1 18:43:06 mhfl2 kernel: [<cf90f31c>] __serial_close+0x84/0x8c [usbserial]
Sep 1 18:43:06 mhfl2 kernel: [<cf90f3b7>] serial_close+0x93/0xb0 [usbserial]
Sep 1 18:43:06 mhfl2 kernel: [<c02199ac>] release_dev+0x23c/0x5c8
Sep 1 18:43:06 mhfl2 kernel: [<c0121258>] update_process_times+0x2c/0x38
Sep 1 18:43:06 mhfl2 kernel: [<c0121136>] update_wall_time+0xe/0x38
Sep 1 18:43:06 mhfl2 kernel: [<c021a058>] tty_release+0xc/0x14
Sep 1 18:43:06 mhfl2 kernel: [<c014705f>] __fput+0x43/0xd8
Sep 1 18:43:06 mhfl2 kernel: [<c0147016>] fput+0x16/0x1c
Sep 1 18:43:06 mhfl2 kernel: [<c0145daf>] filp_close+0x97/0xa4
Sep 1 18:43:06 mhfl2 kernel: [<c0145e07>] sys_close+0x4b/0x60
Sep 1 18:43:06 mhfl2 kernel: [<c010adc7>] syscall_call+0x7/0xb
Sep 1 18:43:06 mhfl2 kernel:
Sep 1 18:43:06 mhfl2 kernel: Code: 8b 40 28 ff d0 89 ec 5d c3 8d 76 00 55 89 e5 83 ec 20 8d 45
Sep 1 18:43:42 mhfl2 kernel: <6>drivers/usb/core/usb.c: deregistering driver pl2303
Sep 1 18:43:42 mhfl2 kernel: drivers/usb/serial/usb-serial.c: USB Serial deregistering driver PL-2303
Sep 1 18:44:08 mhfl2 kernel: drivers/usb/serial/usb-serial.c: USB Serial support registered for PL-2303
Sep 1 18:44:08 mhfl2 kernel: drivers/usb/core/usb.c: registered new driver pl2303
Sep 1 18:44:08 mhfl2 kernel: drivers/usb/serial/pl2303.c: Prolific PL2303 USB to serial adaptor driver v0.10
Sep 1 18:45:24 mhfl2 kernel: drivers/usb/core/usb.c: deregistering driver pl2303
Sep 1 18:45:24 mhfl2 kernel: drivers/usb/serial/usb-serial.c: USB Serial deregistering driver PL-2303
Sep 1 18:45:50 mhfl2 kernel: drivers/usb/serial/usb-serial.c: USB Serial deregistering driver Generic
Sep 1 18:45:50 mhfl2 kernel: drivers/usb/core/usb.c: deregistering driver usbserial
Sep 1 18:46:02 mhfl2 kernel: drivers/usb/core/usb.c: deregistering driver usbfs
Sep 1 18:46:02 mhfl2 kernel: drivers/usb/core/usb.c: deregistering driver hub
Sep 1 18:46:07 mhfl2 kernel: drivers/usb/core/usb.c: registered new driver usbfs
Sep 1 18:46:07 mhfl2 kernel: drivers/usb/core/usb.c: registered new driver hub
Sep 1 18:46:07 mhfl2 kernel: ohci-hcd 0000:00:14.0: OHCI Host Controller
Sep 1 18:46:07 mhfl2 kernel: ohci-hcd 0000:00:14.0: irq 11, pci mem cf8a4000
Sep 1 18:46:07 mhfl2 kernel: ohci-hcd 0000:00:14.0: new USB bus registered, assigned bus number 1
Sep 1 18:46:08 mhfl2 kernel: usb usb1: Product: OHCI Host Controller
Sep 1 18:46:08 mhfl2 kernel: usb usb1: Manufacturer: Linux 2.6.0-test4-mhf60 ohci-hcd
Sep 1 18:46:08 mhfl2 kernel: usb usb1: SerialNumber: 0000:00:14.0
Sep 1 18:46:08 mhfl2 kernel: hub 1-0:0: USB hub found
Sep 1 18:46:08 mhfl2 kernel: hub 1-0:0: 2 ports detected
Sep 1 18:46:08 mhfl2 kernel: SCSI subsystem initialized
Sep 1 18:46:08 mhfl2 kernel: Initializing USB Mass Storage driver...
Sep 1 18:46:08 mhfl2 kernel: drivers/usb/core/usb.c: registered new driver usb-storage
Sep 1 18:46:08 mhfl2 kernel: USB Mass Storage support registered.
Sep 1 18:46:08 mhfl2 kernel: drivers/usb/serial/usb-serial.c: USB Serial support registered for Generic
Sep 1 18:46:08 mhfl2 kernel: drivers/usb/serial/usb-serial.c: usb_serial_init - tty_register_driver failed
Sep 1 18:46:08 mhfl2 kernel: drivers/usb/serial/usb-serial.c: USB Serial deregistering driver Generic
Sep 1 18:46:08 mhfl2 kernel: drivers/usb/serial/usb-serial.c: usb_serial_init - returning with error -16
Sep 1 18:46:08 mhfl2 kernel: pl2303: Unknown symbol usb_serial_disconnect
Sep 1 18:46:08 mhfl2 kernel: pl2303: Unknown symbol usb_serial_probe
Sep 1 18:46:08 mhfl2 kernel: pl2303: Unknown symbol usb_serial_register
Sep 1 18:46:08 mhfl2 kernel: pl2303: Unknown symbol usb_serial_deregister
Sep 1 18:46:08 mhfl2 kernel: lp: driver loaded but no devices found
On Tue, 2003-09-02 01:39:08 +0800, Michael Frank <[email protected]>
wrote in message <[email protected]>:
> PL2303 is used to connect the serial console on a classic serial port
> of a test machine. HW nandshaking is used
> The test machine reboots once a minute and dumps lots of messages
Do you use serial (USB) console to access the box or to capture some
(unrelated) Oops? If you try to to the later, you're most probably off
because USB needs a lot of infrastructure to work (think interrupts!)
which may not be available at Oops time...
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));
On Tue, Sep 02, 2003 at 01:39:08AM +0800, Michael Frank wrote:
> PL2303 is used to connect the serial console on a classic serial port
> of a test machine. HW nandshaking is used
> The test machine reboots once a minute and dumps lots of messages
>
> Frequently:
> - driver hangs
> - userspace (cu) can't be stopped
> - pl2303 and/or usbserial can't be unloaded
> - USB interrupts stop
> - problems result in requiring a reboot.
Hm, it looks like you physically removed the device, is that correct?
Or were you just unloading the pl2303 and other USB drivers and then
reloading them?
What exactly were you doing in this log?
Oh, and can you send a copy of /proc/bus/usb/devices with your pl2303
device plugged in?
thanks,
greg k-h
On Wednesday 03 September 2003 00:43, Greg KH wrote:
> On Tue, Sep 02, 2003 at 01:39:08AM +0800, Michael Frank wrote:
> > PL2303 is used to connect the serial console on a classic serial port
> > of a test machine. HW nandshaking is used
> > The test machine reboots once a minute and dumps lots of messages
> >
> > Frequently:
> > - driver hangs
> > - userspace (cu) can't be stopped
> > - pl2303 and/or usbserial can't be unloaded
> > - USB interrupts stop
> > - problems result in requiring a reboot.
>
> Hm, it looks like you physically removed the device, is that correct?
> Or were you just unloading the pl2303 and other USB drivers and then
> reloading them?
>
> What exactly were you doing in this log?
>
> Oh, and can you send a copy of /proc/bus/usb/devices with your pl2303
> device plugged in?
>
Whenever it stops working I follow this sequence, which you can match
to the logs.
1) Exit cu by ~.
- if this does not work
try \r~.
- if this does not work
Send SIGHUP, (which so far always worked)
2) Start cu again
- if it prints leftover characters
exit cu again by ~. and continue from step 2)
3) If it still not works and hangs again
- for a few tries
unplug PL2303, wait a second replug and goto step 2)
4) If it still does not work
- Remove PL2303, unload and reload usb (all) and
plug PL2303 again
- If module unloading fails, or interrupts died
(no response to plugging) > reboot
Regards
Michael
On Wed, Sep 03, 2003 at 06:13:19AM +0800, Michael Frank wrote:
> On Wednesday 03 September 2003 00:43, Greg KH wrote:
> > On Tue, Sep 02, 2003 at 01:39:08AM +0800, Michael Frank wrote:
> > > PL2303 is used to connect the serial console on a classic serial port
> > > of a test machine. HW nandshaking is used
> > > The test machine reboots once a minute and dumps lots of messages
> > >
> > > Frequently:
> > > - driver hangs
> > > - userspace (cu) can't be stopped
> > > - pl2303 and/or usbserial can't be unloaded
> > > - USB interrupts stop
> > > - problems result in requiring a reboot.
> >
> > Hm, it looks like you physically removed the device, is that correct?
> > Or were you just unloading the pl2303 and other USB drivers and then
> > reloading them?
> >
> > What exactly were you doing in this log?
> >
> > Oh, and can you send a copy of /proc/bus/usb/devices with your pl2303
> > device plugged in?
> >
>
> Whenever it stops working I follow this sequence, which you can match
> to the logs.
>
> 1) Exit cu by ~.
> - if this does not work
> try \r~.
> - if this does not work
> Send SIGHUP, (which so far always worked)
>
> 2) Start cu again
> - if it prints leftover characters
> exit cu again by ~. and continue from step 2)
Ah, I think I just found this problem.
Try the patch below and let me know if this solves it for you or not.
Oh, and where is the copy of /proc/bus/usb/devices with your device
plugged in? :)
thanks,
greg k-h
# USB: fix data toggle problem for pl2303 driver.
diff -Nru a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
--- a/drivers/usb/serial/pl2303.c Tue Sep 2 16:49:31 2003
+++ b/drivers/usb/serial/pl2303.c Tue Sep 2 16:49:31 2003
@@ -404,6 +404,9 @@
dbg("%s - port %d", __FUNCTION__, port->number);
+ usb_clear_halt(serial->dev, port->write_urb->pipe);
+ usb_clear_halt(serial->dev, port->read_urb->pipe);
+
#define FISH(a,b,c,d) \
result=usb_control_msg(serial->dev, usb_rcvctrlpipe(serial->dev,0), \
b, a, c, d, buf, 1, 100); \
On Wednesday 03 September 2003 07:52, Greg KH wrote:
>
> Try the patch below and let me know if this solves it for you or not.
If it is meant to reset the buffers, it has _no_ effect.
Some more observations:
Besides it just stopping without obvious reason:
1) It does not like when something is typed on cu and not received by the serial port side
connected to PL2303 (CTS low). It tends to hang and the trouble starts....
Sep 3 12:52:15 mhfl2 kernel: ttyUSB0: 1 input overrun(s)
Sep 3 12:54:30 mhfl2 last message repeated 2 times
Sep 3 12:55:17 mhfl2 kernel: usb 1-2: USB disconnect, address 2
Sep 3 12:55:17 mhfl2 kernel: usb 1-2: pl2303_write_bulk_callback - failed resubmitting write urb, error -19
cu hang - exit cu _first_, _then_ pull out from hub
Sep 3 12:55:17 mhfl2 kernel: pl2303 1-2:0: device disconnected
Sep 3 12:55:30 mhfl2 kernel: PL-2303 ttyUSB0: PL-2303 converter now disconnected from ttyUSB0
2) When serial port of PL2303 is connected (to a serial port ready to send data)
and PL2303 is plugged into hub, it does not init:
plug in
Sep 3 12:55:47 mhfl2 kernel: hub 1-0:0: debounce: port 2: delay 100ms stable 4 status 0x101
Sep 3 12:55:48 mhfl2 kernel: hub 1-0:0: new USB device on port 2, assigned address 3
Sep 3 12:55:48 mhfl2 kernel: usb 1-2: device not accepting address 3, error -110
pull out, plug in
Sep 3 12:55:48 mhfl2 kernel: hub 1-0:0: new USB device on port 2, assigned address 4
Sep 3 12:55:49 mhfl2 kernel: usb 1-2: device not accepting address 4, error -110
Sep 3 12:56:06 mhfl2 kernel: hub 1-0:0: debounce: port 2: delay 100ms stable 4 status 0x101
pull out, plug in
Sep 3 12:56:06 mhfl2 kernel: hub 1-0:0: new USB device on port 2, assigned address 5
Sep 3 12:56:06 mhfl2 kernel: usb 1-2: device not accepting address 5, error -110
Sep 3 12:56:07 mhfl2 kernel: hub 1-0:0: new USB device on port 2, assigned address 6
pull out
_disconnect_ serial port side of PL2303
plug in - OK
Sep 3 12:56:07 mhfl2 kernel: usbserial 1-2:0: PL-2303 converter detected
Sep 3 12:56:07 mhfl2 kernel: usb 1-2: PL-2303 converter now attached to ttyUSB0 (or usb/tts/0 for devfs)
After a while it hang again, this time unloaded USB _without_ exit cu
Sep 3 14:03:42 mhfl2 kernel: usb 1-2: USB disconnect, address 2
Sep 3 14:03:42 mhfl2 kernel: usbserial 1-2:0: device disconnected
Sep 3 14:03:47 mhfl2 kernel: drivers/usb/core/usb.c: deregistering driver usb-storage
Sep 3 14:03:47 mhfl2 kernel: ohci-hcd 0000:00:14.0: remove, state 3
Sep 3 14:03:47 mhfl2 kernel: usb usb1: USB disconnect, address 1
Sep 3 14:03:48 mhfl2 kernel: ohci-hcd 0000:00:14.0: USB bus 1 deregistered
Sep 3 14:03:53 mhfl2 kernel: PL-2303 ttyUSB0: pl2303_write - failed submitting write urb, error -19
Sep 3 14:03:53 mhfl2 kernel: PL-2303 ttyUSB0: PL-2303 converter now disconnected from ttyUSB0
Sep 3 14:03:53 mhfl2 kernel: Unable to handle kernel paging request at virtual address cf8981a8
Sep 3 14:03:53 mhfl2 kernel: printing eip:
Sep 3 14:03:53 mhfl2 kernel: cf87bd94
Sep 3 14:03:53 mhfl2 kernel: *pde = 012b4067
Sep 3 14:03:53 mhfl2 kernel: *pte = 00000000
Sep 3 14:03:53 mhfl2 kernel: Oops: 0000 [#1]
Sep 3 14:03:53 mhfl2 kernel: CPU: 0
Sep 3 14:03:53 mhfl2 kernel: EIP: 0060:[<cf87bd94>] Not tainted
Sep 3 14:03:53 mhfl2 kernel: EFLAGS: 00010282
Sep 3 14:03:53 mhfl2 kernel: EIP is at hcd_pci_release+0x14/0x20 [usbcore]
Sep 3 14:03:53 mhfl2 kernel: eax: cf898180 ebx: c03978c0 ecx: cf88b240 edx: c6513234
Sep 3 14:03:53 mhfl2 kernel: esi: 00000001 edi: ccb0c300 ebp: c5aa9de4 esp: c5aa9de0
Sep 3 14:03:53 mhfl2 kernel: ds: 007b es: 007b ss: 0068
Sep 3 14:03:53 mhfl2 kernel: Process cu (pid: 6763, threadinfo=c5aa8000 task=c61f72e0)
Sep 3 14:03:53 mhfl2 kernel: Stack: c6513234 c5aa9df0 cf8783c6 c6513234 c5aa9dfc c0233360 c651327c c5aa9e0c
Sep 3 14:03:53 mhfl2 kernel: c01d2498 c6513284 cd6c1600 c5aa9e18 c01d24ca c6513284 c5aa9e24 c02336cf
Sep 3 14:03:53 mhfl2 kernel: c6513284 c5aa9e30 cf8783ab c651327c c5aa9e44 cf8747ee c6513234 cd6c1600
Sep 3 14:03:53 mhfl2 kernel: Call Trace:
Sep 3 14:03:53 mhfl2 kernel: [<cf8783c6>] usb_host_release+0x16/0x1c [usbcore]
Sep 3 14:03:53 mhfl2 kernel: [<c0233360>] class_dev_release+0x18/0x50
Sep 3 14:03:53 mhfl2 kernel: [<c01d2498>] kobject_cleanup+0x28/0x44
Sep 3 14:03:53 mhfl2 kernel: [<c01d24ca>] kobject_put+0x16/0x1c
Sep 3 14:03:53 mhfl2 kernel: [<c02336cf>] class_device_put+0xf/0x14
Sep 3 14:03:53 mhfl2 kernel: [<cf8783ab>] usb_bus_put+0x13/0x18 [usbcore]
Sep 3 14:03:53 mhfl2 kernel: [<cf8747ee>] usb_release_dev+0x3a/0x48 [usbcore]
Sep 3 14:03:53 mhfl2 kernel: [<c0231b0a>] device_release+0x16/0x50
Sep 3 14:03:53 mhfl2 kernel: [<c01d2498>] kobject_cleanup+0x28/0x44
Sep 3 14:03:53 mhfl2 kernel: [<c01d24ca>] kobject_put+0x16/0x1c
Sep 3 14:03:53 mhfl2 kernel: [<c0231ddb>] put_device+0xf/0x14
Sep 3 14:03:53 mhfl2 kernel: [<cf874931>] usb_put_dev+0x15/0x1c [usbcore]
Sep 3 14:03:53 mhfl2 kernel: [<cf92b0b6>] destroy_serial+0x16e/0x180 [usbserial]
Sep 3 14:03:53 mhfl2 kernel: [<c01d2498>] kobject_cleanup+0x28/0x44
Sep 3 14:03:53 mhfl2 kernel: [<c01d24ca>] kobject_put+0x16/0x1c
Sep 3 14:03:53 mhfl2 kernel: [<cf92a31c>] __serial_close+0x84/0x8c [usbserial]
Sep 3 14:03:53 mhfl2 kernel: [<cf92a3b7>] serial_close+0x93/0xb0 [usbserial]
Sep 3 14:03:53 mhfl2 kernel: [<c02199ac>] release_dev+0x23c/0x5c8
Sep 3 14:03:53 mhfl2 kernel: [<c021a058>] tty_release+0xc/0x14
Sep 3 14:03:53 mhfl2 kernel: [<c014705f>] __fput+0x43/0xd8
Sep 3 14:03:53 mhfl2 kernel: [<c0147016>] fput+0x16/0x1c
Sep 3 14:03:53 mhfl2 kernel: [<c0145daf>] filp_close+0x97/0xa4
Sep 3 14:03:53 mhfl2 kernel: [<c0145e07>] sys_close+0x4b/0x60
Sep 3 14:03:53 mhfl2 kernel: [<c010adc7>] syscall_call+0x7/0xb
Sep 3 14:03:53 mhfl2 kernel:
Sep 3 14:03:53 mhfl2 kernel: Code: 8b 40 28 ff d0 89 ec 5d c3 8d 76 00 55 89 e5 83 ec 20 8d 45
>
> Oh, and where is the copy of /proc/bus/usb/devices with your device
> plugged in? :)
>
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 18/900 us ( 2%), #Int= 1, #Iso= 0
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 2.06
S: Manufacturer=Linux 2.6.0-test4-mhf60 ohci-hcd
S: Product=OHCI Host Controller
S: SerialNumber=0000:00:14.0
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms
T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=067b ProdID=2303 Rev= 2.00
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=pl2303
E: Ad=81(I) Atr=03(Int.) MxPS= 10 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=83(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
Thank you
Regards
Michael
On Wed, Sep 03, 2003 at 02:32:16PM +0800, Michael Frank wrote:
> On Wednesday 03 September 2003 07:52, Greg KH wrote:
> >
> > Try the patch below and let me know if this solves it for you or not.
>
> If it is meant to reset the buffers, it has _no_ effect.
>
> Some more observations:
>
> Besides it just stopping without obvious reason:
>
> 1) It does not like when something is typed on cu and not received by the serial port side
> connected to PL2303 (CTS low). It tends to hang and the trouble starts....
>
> Sep 3 12:52:15 mhfl2 kernel: ttyUSB0: 1 input overrun(s)
> Sep 3 12:54:30 mhfl2 last message repeated 2 times
Hm, what is causing this?
That is probably why cu is getting confused, right?
> Sep 3 12:55:17 mhfl2 kernel: usb 1-2: USB disconnect, address 2
> Sep 3 12:55:17 mhfl2 kernel: usb 1-2: pl2303_write_bulk_callback - failed resubmitting write urb, error -19
>
> cu hang - exit cu _first_, _then_ pull out from hub
>
> Sep 3 12:55:17 mhfl2 kernel: pl2303 1-2:0: device disconnected
> Sep 3 12:55:30 mhfl2 kernel: PL-2303 ttyUSB0: PL-2303 converter now disconnected from ttyUSB0
Ok, but the ttyUSB0 port is still open as the tty core still has a
reference to it. Does it still show up in /sys/class/tty?
> 2) When serial port of PL2303 is connected (to a serial port ready to send data)
> and PL2303 is plugged into hub, it does not init:
>
> plug in
> Sep 3 12:55:47 mhfl2 kernel: hub 1-0:0: debounce: port 2: delay 100ms stable 4 status 0x101
> Sep 3 12:55:48 mhfl2 kernel: hub 1-0:0: new USB device on port 2, assigned address 3
> Sep 3 12:55:48 mhfl2 kernel: usb 1-2: device not accepting address 3, error -110
That's showing either you don't have good pci interrupt routing going
on, or a messed up device.
> pull out, plug in
> Sep 3 12:55:48 mhfl2 kernel: hub 1-0:0: new USB device on port 2, assigned address 4
> Sep 3 12:55:49 mhfl2 kernel: usb 1-2: device not accepting address 4, error -110
> Sep 3 12:56:06 mhfl2 kernel: hub 1-0:0: debounce: port 2: delay 100ms stable 4 status 0x101
> pull out, plug in
> Sep 3 12:56:06 mhfl2 kernel: hub 1-0:0: new USB device on port 2, assigned address 5
> Sep 3 12:56:06 mhfl2 kernel: usb 1-2: device not accepting address 5, error -110
> Sep 3 12:56:07 mhfl2 kernel: hub 1-0:0: new USB device on port 2, assigned address 6
> pull out
>
> _disconnect_ serial port side of PL2303
>
> plug in - OK
> Sep 3 12:56:07 mhfl2 kernel: usbserial 1-2:0: PL-2303 converter detected
> Sep 3 12:56:07 mhfl2 kernel: usb 1-2: PL-2303 converter now attached to ttyUSB0 (or usb/tts/0 for devfs)
Heh, ok, it looks like you have a wierd device.
> After a while it hang again, this time unloaded USB _without_ exit cu
Hm, how can you do this? There should be a reference on the pl2303
driver as you have the port open. Or are you just removing the host
controller driver here?
> Sep 3 14:03:42 mhfl2 kernel: usb 1-2: USB disconnect, address 2
> Sep 3 14:03:42 mhfl2 kernel: usbserial 1-2:0: device disconnected
> Sep 3 14:03:47 mhfl2 kernel: drivers/usb/core/usb.c: deregistering driver usb-storage
> Sep 3 14:03:47 mhfl2 kernel: ohci-hcd 0000:00:14.0: remove, state 3
> Sep 3 14:03:47 mhfl2 kernel: usb usb1: USB disconnect, address 1
> Sep 3 14:03:48 mhfl2 kernel: ohci-hcd 0000:00:14.0: USB bus 1 deregistered
> Sep 3 14:03:53 mhfl2 kernel: PL-2303 ttyUSB0: pl2303_write - failed submitting write urb, error -19
> Sep 3 14:03:53 mhfl2 kernel: PL-2303 ttyUSB0: PL-2303 converter now disconnected from ttyUSB0
> Sep 3 14:03:53 mhfl2 kernel: Unable to handle kernel paging request at virtual address cf8981a8
> Sep 3 14:03:53 mhfl2 kernel: printing eip:
> Sep 3 14:03:53 mhfl2 kernel: cf87bd94
> Sep 3 14:03:53 mhfl2 kernel: *pde = 012b4067
> Sep 3 14:03:53 mhfl2 kernel: *pte = 00000000
> Sep 3 14:03:53 mhfl2 kernel: Oops: 0000 [#1]
> Sep 3 14:03:53 mhfl2 kernel: CPU: 0
> Sep 3 14:03:53 mhfl2 kernel: EIP: 0060:[<cf87bd94>] Not tainted
> Sep 3 14:03:53 mhfl2 kernel: EFLAGS: 00010282
> Sep 3 14:03:53 mhfl2 kernel: EIP is at hcd_pci_release+0x14/0x20 [usbcore]
> Sep 3 14:03:53 mhfl2 kernel: eax: cf898180 ebx: c03978c0 ecx: cf88b240 edx: c6513234
> Sep 3 14:03:53 mhfl2 kernel: esi: 00000001 edi: ccb0c300 ebp: c5aa9de4 esp: c5aa9de0
> Sep 3 14:03:53 mhfl2 kernel: ds: 007b es: 007b ss: 0068
> Sep 3 14:03:53 mhfl2 kernel: Process cu (pid: 6763, threadinfo=c5aa8000 task=c61f72e0)
> Sep 3 14:03:53 mhfl2 kernel: Stack: c6513234 c5aa9df0 cf8783c6 c6513234 c5aa9dfc c0233360 c651327c c5aa9e0c
> Sep 3 14:03:53 mhfl2 kernel: c01d2498 c6513284 cd6c1600 c5aa9e18 c01d24ca c6513284 c5aa9e24 c02336cf
> Sep 3 14:03:53 mhfl2 kernel: c6513284 c5aa9e30 cf8783ab c651327c c5aa9e44 cf8747ee c6513234 cd6c1600
> Sep 3 14:03:53 mhfl2 kernel: Call Trace:
> Sep 3 14:03:53 mhfl2 kernel: [<cf8783c6>] usb_host_release+0x16/0x1c [usbcore]
> Sep 3 14:03:53 mhfl2 kernel: [<c0233360>] class_dev_release+0x18/0x50
> Sep 3 14:03:53 mhfl2 kernel: [<c01d2498>] kobject_cleanup+0x28/0x44
> Sep 3 14:03:53 mhfl2 kernel: [<c01d24ca>] kobject_put+0x16/0x1c
> Sep 3 14:03:53 mhfl2 kernel: [<c02336cf>] class_device_put+0xf/0x14
> Sep 3 14:03:53 mhfl2 kernel: [<cf8783ab>] usb_bus_put+0x13/0x18 [usbcore]
> Sep 3 14:03:53 mhfl2 kernel: [<cf8747ee>] usb_release_dev+0x3a/0x48 [usbcore]
> Sep 3 14:03:53 mhfl2 kernel: [<c0231b0a>] device_release+0x16/0x50
> Sep 3 14:03:53 mhfl2 kernel: [<c01d2498>] kobject_cleanup+0x28/0x44
> Sep 3 14:03:53 mhfl2 kernel: [<c01d24ca>] kobject_put+0x16/0x1c
> Sep 3 14:03:53 mhfl2 kernel: [<c0231ddb>] put_device+0xf/0x14
> Sep 3 14:03:53 mhfl2 kernel: [<cf874931>] usb_put_dev+0x15/0x1c [usbcore]
> Sep 3 14:03:53 mhfl2 kernel: [<cf92b0b6>] destroy_serial+0x16e/0x180 [usbserial]
> Sep 3 14:03:53 mhfl2 kernel: [<c01d2498>] kobject_cleanup+0x28/0x44
> Sep 3 14:03:53 mhfl2 kernel: [<c01d24ca>] kobject_put+0x16/0x1c
> Sep 3 14:03:53 mhfl2 kernel: [<cf92a31c>] __serial_close+0x84/0x8c [usbserial]
> Sep 3 14:03:53 mhfl2 kernel: [<cf92a3b7>] serial_close+0x93/0xb0 [usbserial]
> Sep 3 14:03:53 mhfl2 kernel: [<c02199ac>] release_dev+0x23c/0x5c8
> Sep 3 14:03:53 mhfl2 kernel: [<c021a058>] tty_release+0xc/0x14
> Sep 3 14:03:53 mhfl2 kernel: [<c014705f>] __fput+0x43/0xd8
> Sep 3 14:03:53 mhfl2 kernel: [<c0147016>] fput+0x16/0x1c
> Sep 3 14:03:53 mhfl2 kernel: [<c0145daf>] filp_close+0x97/0xa4
> Sep 3 14:03:53 mhfl2 kernel: [<c0145e07>] sys_close+0x4b/0x60
> Sep 3 14:03:53 mhfl2 kernel: [<c010adc7>] syscall_call+0x7/0xb
> Sep 3 14:03:53 mhfl2 kernel:
> Sep 3 14:03:53 mhfl2 kernel: Code: 8b 40 28 ff d0 89 ec 5d c3 8d 76 00 55 89 e5 83 ec 20 8d 45
Ick, that's not nice, can you put this in a bug at bugzilla.kernel.org
so I don't forget to track it down properly?
> > Oh, and where is the copy of /proc/bus/usb/devices with your device
> > plugged in? :)
> >
>
> T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
> B: Alloc= 18/900 us ( 2%), #Int= 1, #Iso= 0
> D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
> P: Vendor=0000 ProdID=0000 Rev= 2.06
> S: Manufacturer=Linux 2.6.0-test4-mhf60 ohci-hcd
> S: Product=OHCI Host Controller
> S: SerialNumber=0000:00:14.0
> C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA
> I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
> E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms
>
> T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
> D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
> P: Vendor=067b ProdID=2303 Rev= 2.00
> C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
> I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=pl2303
> E: Ad=81(I) Atr=03(Int.) MxPS= 10 Ivl=1ms
> E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=83(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
Hm, ok, I was worried you had one of the older pl2303 devices that were
really messed up. This looks like a relativly sane device.
thanks,
greg k-h
On Saturday 06 September 2003 07:08, Greg KH wrote:
> On Wed, Sep 03, 2003 at 02:32:16PM +0800, Michael Frank wrote:
> > On Wednesday 03 September 2003 07:52, Greg KH wrote:
> > > Try the patch below and let me know if this solves it for you or not.
> >
> > If it is meant to reset the buffers, it has _no_ effect.
> >
> > Some more observations:
> >
> > Besides it just stopping without obvious reason:
> >
> > 1) It does not like when something is typed on cu and not received by the
> > serial port side connected to PL2303 (CTS low). It tends to hang and the
> > trouble starts....
> >
> > Sep 3 12:52:15 mhfl2 kernel: ttyUSB0: 1 input overrun(s)
> > Sep 3 12:54:30 mhfl2 last message repeated 2 times
>
> Hm, what is causing this?
>
I don't understand why it get's Input overruns when it sends a single key.
"Input" seems not to have any problem.
Could there be an event meant for output misrouted to input - messing things
up?
> That is probably why cu is getting confused, right?
I think so. Once this message shows up, it is essentially unusable.
> > plug in
> > Sep 3 12:55:47 mhfl2 kernel: hub 1-0:0: debounce: port 2: delay 100ms stable 4 status 0x101
> > Sep 3 12:55:48 mhfl2 kernel: hub 1-0:0: new USB device on port 2, assigned address 3
> > Sep 3 12:55:48 mhfl2 kernel: usb 1-2: device not accepting address 3, error -110
> That's showing either you don't have good pci interrupt routing going
> on, or a messed up device.
Interrupts - no, I copied gigabytes to/from USB hard disk,
eth0 and yenta on PCI are fine too.
Device - how to verify?
Could it be a "misunderstanding" between device and driver?
- driver (seing new device) want's to assign address to device
- device (plugged in, reset), sees a line status changed and
want's to send respective event to driver
> > _disconnect_ serial port side of PL2303
> >
> > plug in - OK
> > Sep 3 12:56:07 mhfl2 kernel: usbserial 1-2:0: PL-2303 converter detected
> > Sep 3 12:56:07 mhfl2 kernel: usb 1-2: PL-2303 converter now attached to
> > ttyUSB0 (or usb/tts/0 for devfs)
>
> Heh, ok, it looks like you have a wierd device.
Could it be that - device (plugged in, reset), sees _no_ line status changed
and has nothing to send.
Perhaps there is a sequencing problem somewhere, and it works by chance.
>> After a while it hang again, this time unloaded USB _without_ exit cu
> Hm, how can you do this? There should be a reference on the pl2303
> driver as you have the port open. Or are you just removing the host
> controller driver here?
It's not loaded on boot, but only when needed. The scripts:
usb1)
if [ ! -e /proc/bus/usb ]; then
echo Loading USB
modprobe usbcore
mount -t usbdevfs usbdevfs /proc/bus/usb
modprobe ohci_hcd
modprobe sd_mod
modprobe pl2303
modprobe lp
fi
;;
usb0)
echo Unloading USB
rmmod usb-storage sd_mod scsi-mod
rmmod pl2303 usbserial
rmmod lp parport
rmmod ohci_hcd
umount usbdevfs
rmmod usbcore
;;
Perhaps this is too dumb and I should do some checking along the way,
however joe user should be unable to oops things up...
Regards
Michael
On Sat, Sep 06, 2003 at 10:31:19AM +0800, Michael Frank wrote:
> On Saturday 06 September 2003 07:08, Greg KH wrote:
> > On Wed, Sep 03, 2003 at 02:32:16PM +0800, Michael Frank wrote:
> > > On Wednesday 03 September 2003 07:52, Greg KH wrote:
> > > > Try the patch below and let me know if this solves it for you or not.
> > >
> > > If it is meant to reset the buffers, it has _no_ effect.
> > >
> > > Some more observations:
> > >
> > > Besides it just stopping without obvious reason:
> > >
> > > 1) It does not like when something is typed on cu and not received by the
> > > serial port side connected to PL2303 (CTS low). It tends to hang and the
> > > trouble starts....
> > >
> > > Sep 3 12:52:15 mhfl2 kernel: ttyUSB0: 1 input overrun(s)
> > > Sep 3 12:54:30 mhfl2 last message repeated 2 times
> >
> > Hm, what is causing this?
> >
>
> I don't understand why it get's Input overruns when it sends a single key.
> "Input" seems not to have any problem.
>
> Could there be an event meant for output misrouted to input - messing things
> up?
In the tty core? possibly, but I doubt it.
> > That is probably why cu is getting confused, right?
>
> I think so. Once this message shows up, it is essentially unusable.
Hm, not nice.
> > > plug in
> > > Sep 3 12:55:47 mhfl2 kernel: hub 1-0:0: debounce: port 2: delay 100ms stable 4 status 0x101
> > > Sep 3 12:55:48 mhfl2 kernel: hub 1-0:0: new USB device on port 2, assigned address 3
> > > Sep 3 12:55:48 mhfl2 kernel: usb 1-2: device not accepting address 3, error -110
>
> > That's showing either you don't have good pci interrupt routing going
> > on, or a messed up device.
>
> Interrupts - no, I copied gigabytes to/from USB hard disk,
> eth0 and yenta on PCI are fine too.
>
> Device - how to verify?
You said if you disconnect the serial cable from the device it works,
right? That's a device issue :)
> Could it be a "misunderstanding" between device and driver?
> - driver (seing new device) want's to assign address to device
> - device (plugged in, reset), sees a line status changed and
> want's to send respective event to driver
Possibly, but again, that's a messed up device if it does that.
The pl2303 devices are usually quite cheap, so I would believe yours has
such a problem.
> > > _disconnect_ serial port side of PL2303
> > >
> > > plug in - OK
> > > Sep 3 12:56:07 mhfl2 kernel: usbserial 1-2:0: PL-2303 converter detected
> > > Sep 3 12:56:07 mhfl2 kernel: usb 1-2: PL-2303 converter now attached to
> > > ttyUSB0 (or usb/tts/0 for devfs)
> >
> > Heh, ok, it looks like you have a wierd device.
>
> Could it be that - device (plugged in, reset), sees _no_ line status changed
> and has nothing to send.
>
> Perhaps there is a sequencing problem somewhere, and it works by chance.
>
> >> After a while it hang again, this time unloaded USB _without_ exit cu
>
> > Hm, how can you do this? There should be a reference on the pl2303
> > driver as you have the port open. Or are you just removing the host
> > controller driver here?
>
> It's not loaded on boot, but only when needed. The scripts:
>
> usb1)
> if [ ! -e /proc/bus/usb ]; then
> echo Loading USB
> modprobe usbcore
> mount -t usbdevfs usbdevfs /proc/bus/usb
> modprobe ohci_hcd
> modprobe sd_mod
> modprobe pl2303
> modprobe lp
> fi
> ;;
>
> usb0)
> echo Unloading USB
> rmmod usb-storage sd_mod scsi-mod
> rmmod pl2303 usbserial
> rmmod lp parport
> rmmod ohci_hcd
> umount usbdevfs
> rmmod usbcore
> ;;
>
> Perhaps this is too dumb and I should do some checking along the way,
> however joe user should be unable to oops things up...
I agree. Can you add that oops to a new bug at bugzilla.kernel.org?
thanks,
greg k-h
On Fri, 2003-09-05 16:08:52 -0700, Greg KH <[email protected]>
wrote in message <[email protected]>:
> On Wed, Sep 03, 2003 at 02:32:16PM +0800, Michael Frank wrote:
> > On Wednesday 03 September 2003 07:52, Greg KH wrote:
> > Besides it just stopping without obvious reason:
> >
> > 1) It does not like when something is typed on cu and not received by the serial port side
> > connected to PL2303 (CTS low). It tends to hang and the trouble starts....
> >
> > Sep 3 12:52:15 mhfl2 kernel: ttyUSB0: 1 input overrun(s)
> > Sep 3 12:54:30 mhfl2 last message repeated 2 times
>
> Hm, what is causing this?
> That is probably why cu is getting confused, right?
I've seen the input overrun message also (with the vanilla driver, not
patched). It's effect is that the first bytes (maybe up to 100..300
bytes) are scrambled. It's like accessing a serial link with a horribly
wrong baud rate.
After a split-second, however, everything is okay and I start receiving
valid NMEA data from my GPS receiver. For me, that's not much of a
problem because nmea is checksum'ed and the bad bytes are ignored...
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));
On Saturday 06 September 2003 13:48, Greg KH wrote:
> On Sat, Sep 06, 2003 at 10:31:19AM +0800, Michael Frank wrote:
> > It's not loaded on boot, but only when needed. The scripts:
> >
> > usb1)
> > if [ ! -e /proc/bus/usb ]; then
> > echo Loading USB
> > modprobe usbcore
> > mount -t usbdevfs usbdevfs /proc/bus/usb
> > modprobe ohci_hcd
> > modprobe sd_mod
> > modprobe pl2303
> > modprobe lp
> > fi
> > ;;
> >
> > usb0)
> > echo Unloading USB
> > rmmod usb-storage sd_mod scsi-mod
> > rmmod pl2303 usbserial
> > rmmod lp parport
> > rmmod ohci_hcd
> > umount usbdevfs
> > rmmod usbcore
> > ;;
> >
> > Perhaps this is too dumb and I should do some checking along the way,
> > however joe user should be unable to oops things up...
>
> I agree. Can you add that oops to a new bug at bugzilla.kernel.org?
>
Yes, will do, and more testing as well.
Regards
Michael
On Saturday 06 September 2003 15:38, Jan-Benedict Glaw wrote:
> On Fri, 2003-09-05 16:08:52 -0700, Greg KH <[email protected]>
> wrote in message <[email protected]>:
> > On Wed, Sep 03, 2003 at 02:32:16PM +0800, Michael Frank wrote:
> > > On Wednesday 03 September 2003 07:52, Greg KH wrote:
> > > Besides it just stopping without obvious reason:
> > >
> > > 1) It does not like when something is typed on cu and not received by the serial port side
> > > connected to PL2303 (CTS low). It tends to hang and the trouble starts....
> > >
> > > Sep 3 12:52:15 mhfl2 kernel: ttyUSB0: 1 input overrun(s)
> > > Sep 3 12:54:30 mhfl2 last message repeated 2 times
> >
> > Hm, what is causing this?
> > That is probably why cu is getting confused, right?
>
> I've seen the input overrun message also (with the vanilla driver, not
> patched).
> It's effect is that the first bytes (maybe up to 100..300
> bytes) are scrambled. It's like accessing a serial link with a horribly
> wrong baud rate.
I have seen that too, but rarely. Most the time it hangs after the first
few hundred bytes.
>
> After a split-second, however, everything is okay and I start receiving
> valid NMEA data from my GPS receiver. For me, that's not much of a
> problem because nmea is checksum'ed and the bad bytes are ignored...
>
I have used PL2303 so far to grab serial console messages and did not
get in synch with cu after the overrun popped up.
Regards
Michael
On Sat, 2003-09-06 15:55:46 +0800, Michael Frank <[email protected]>
wrote in message <[email protected]>:
> On Saturday 06 September 2003 15:38, Jan-Benedict Glaw wrote:
> > On Fri, 2003-09-05 16:08:52 -0700, Greg KH <[email protected]>
> > wrote in message <[email protected]>:
> > > On Wed, Sep 03, 2003 at 02:32:16PM +0800, Michael Frank wrote:
> > > > On Wednesday 03 September 2003 07:52, Greg KH wrote:
> > > > Sep 3 12:52:15 mhfl2 kernel: ttyUSB0: 1 input overrun(s)
> > > > Sep 3 12:54:30 mhfl2 last message repeated 2 times
> > >
> > > Hm, what is causing this?
> > > That is probably why cu is getting confused, right?
> >
> > I've seen the input overrun message also (with the vanilla driver, not
> > patched).
> > It's effect is that the first bytes (maybe up to 100..300
> > bytes) are scrambled. It's like accessing a serial link with a horribly
> > wrong baud rate.
>
> I have seen that too, but rarely. Most the time it hangs after the first
> few hundred bytes.
I've never seen that. My impression is that this (only?) happens if
there are some bytes received from serial, but not read out from
userspace. For NMEA, this is mostly always the case because the GPS
receiver is sending data all the time:)
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));