From: Greg KH <greg@kroah.com>
To: Michael Frank <mhf@linuxmail.org>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
linux-usb-devel@lists.sourceforge.net
Subject: Re: [linux-usb-devel] 2.6.0-test4 - PL2303 OOPS - see also 2.4.22: OOPS on disconnect PL2303 adapter
Date: Fri, 5 Sep 2003 22:48:13 -0700 [thread overview]
Message-ID: <20030906054813.GC20197@kroah.com> (raw)
In-Reply-To: <200309060932.47136.mhf@linuxmail.org>
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
next prev parent reply other threads:[~2003-09-06 5:48 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-01 17:39 2.6.0-test4 - PL2303 OOPS - see also 2.4.22: OOPS on disconnect PL2303 adapter Michael Frank
2003-09-01 18:53 ` Jan-Benedict Glaw
2003-09-02 16:43 ` [linux-usb-devel] " Greg KH
2003-09-02 22:13 ` Michael Frank
2003-09-02 23:52 ` Greg KH
2003-09-03 6:32 ` Michael Frank
2003-09-05 23:08 ` Greg KH
2003-09-06 2:31 ` Michael Frank
2003-09-06 5:48 ` Greg KH [this message]
2003-09-06 8:01 ` Michael Frank
2003-09-06 7:38 ` Jan-Benedict Glaw
2003-09-06 7:55 ` Michael Frank
2003-09-06 10:55 ` Jan-Benedict Glaw
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030906054813.GC20197@kroah.com \
--to=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=mhf@linuxmail.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).