From: "Greg KH" <[EMAIL PROTECTED]>
> On Thu, Jan 10, 2002 at 04:47:28PM +0100, Lars Doelle wrote:
> > as USB is out to replace legacy devices, most notably serial and
parallel
> > ports of the PC, i was assuming that a proper subclass definition exists
on
> > usb.org for these.
>
> There is no US
I'll have to have a look at this, but I don't know when. Is there a
deadline for this to be done by?
..Stu
- Original Message -
From: "Oliver Neukum" <[EMAIL PROTECTED]>
To: "Greg KH" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]
From: "David Brownell" <[EMAIL PROTECTED]>
> ... is still not informative. "-100" means "-ENETDOWN" on my system,
> but no HCD returns that code. What architecture?
Not sure what you mean "what architecture". This happens on both uhci
and ohci as demonstrated by the more complete messages attac
From: "David Brownell" <[EMAIL PROTECTED]>
> I meant among other things "what CPU". The text you sent by originally
Ah.
Sep 17 12:14:33 moll kernel: CPU0: Intel 00/07 stepping 03
/proc/cpuinfo attached below. PII 500 I think.
> included "-100", not "-110", which isn't an error code USB return
From: "Greg KH" <[EMAIL PROTECTED]>
> No, the problem was that HZ changed in 5.25, and I wasn't using it in
> the call to usb_control_msg(). Here's the patch that fixes the problem,
> and now my whiteheat device works just fine.
Sheesh, that was simple. I probably shoulda noticed that when I loo
From: "Greg KH" <[EMAIL PROTECTED]>
> Please do a 2.5.36 version, as I just modified every USB driver in that
> release.
Crap! I even downloaded it this morning, and still forgot. Will do.
..Stu
---
This SF.NET email is sponsored by: AMD -
Below you will find the log of a recent 2.5.43 test of the whiteheat driver;
stock kernel, using the driver that's included.
Some automatic checks have been triggered, and I'm wondering where
the error lies.
I don't think I'm calling usb_clear_halt in a an illegal manner (cases
1, 2 and 3), but a
o struct urb.
..Stu
- Original Message -
From: "Stuart MacDonald" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: November 18, 2002 10:55 a
Subject: struct urb's urb_list
> struct urb contains a list_head urb_list. According to the 2.5.43
> headers this is for th
From: "David Brownell" <[EMAIL PROTECTED]>
> Stuart MacDonald wrote:
> > The problem boils down to the fact that I can't use urb_list to keep a
> > list of urbs for later unlinking. I'm thinking the best solution is to
> > add a second list_head to
Oops attached below.
The scenario: I've got a WhiteHEAT plugged in, and # cu -l /dev/ttyUSB0. The far side
is sending a small text file across, which cu is displaying as it arrives. During the
transfer I
unplug the WhiteHEAT.
Sometimes I get this oops, sometimes I don't. It's always identical, t
Here's the sequence:
- serial_disconnect in
- serial_disconnect acquires per-port semaphore
- serial_write in
- serial_write sleeps on semaphore
- serial_disconnect sets driver_data = NULL (but _write is already in!)
- serial_disconnect releases semaphore
***
- serial_disconnect frees memory conta
From: "Randy.Dunlap" <[EMAIL PROTECTED]>
> It _looks_ to me like it's having a problem with this loop in
> copy_files, but I could be a bit off:
>
> for (i = open_files; i != 0; i--) {
> struct file *f = *old_fds++;
> if (f)
> get_file(f);
> *new_fds++ = f;
> }
>
> and that in "if (f)" is -1. Eve
Attached is a patch that changes the 2.5.x disconnect to be similar to
2.4.x disconnect. This doesn't fix the race, but does shrink the
window such that I've never seen it trigger, even under testing
designed to do that.
There doesn't seem to be a good way to fix the race. The fix should be
to hav
From: "David Brownell" <[EMAIL PROTECTED]>
> > What happens when a semaphore is freed from under a sleeping holder?
> Bad Stuff. It's not legal. Oopses could happen ...
Including the sleeping holder never waking up? 'Cause I saw that too.
> Basically you need to decouple some "disconnect" proce
From: "Greg KH" <[EMAIL PROTECTED]>
> But David's right, this needs to be fixed differently, and I'll work on
> adding proper disconnect logic. I'm already starting to work on a
> number of cleanups that these drivers need (proper device model changes,
> code splitup, etc.)
But I could use it fix
From: "Jochen Friedrich" <[EMAIL PROTECTED]>
> For now, i fixed the problem by disabling the tty_wait_until_sent stuff:
Teach me to read the whole thread first. :-)
..Stu
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition
From: "Jochen Friedrich" <[EMAIL PROTECTED]>
> serial_close downs &port->sem, then calls digi_close.
> digi_close calls tty_wait_until_sent.
> tty_wait_until_sent calls serial_chars_in_buffer.
> serial_chars_in_buffer tries to down &port->sem again, and here it hangs.
I reported this one a while a
From: "Greg KH" <[EMAIL PROTECTED]>
> Hm, no I don't. Have you tried emailing [EMAIL PROTECTED] with
> this info? He's the current maintainer of the driver.
Not to my knowledge, although I haven't yet gotten to my inbox. Please
resend to myself directly, [EMAIL PROTECTED] or repost.
..Stu
-
Attached patch fixes spurious errors during firmware load. Please
apply to 2.6.16.20 and 2.6.17.
Signed-off-by: Stuart MacDonald <[EMAIL PROTECTED]>
..Stu
--- linux-2.6.16/drivers/usb/serial/whiteheat.c 2006-03-20 00:53:29.0
-0500
+++ linux-2.6.16-wh/drivers/usb/serial/white
Take two; hopefully not wrapped this time.
Attached patch fixes spurious errors during firmware load. Please
apply to 2.6.16.20 and 2.6.17.
Signed-off-by: Stuart MacDonald <[EMAIL PROTECTED]>
..Stu
--- linux-2.6.16/drivers/usb/serial/whiteheat.c 2006-03-20 00:53:29.0
-0500
+++
From: "Greg KH" <[EMAIL PROTECTED]>
> On Wed, Apr 18, 2001 at 03:48:09AM -0700, Adam J. Richter wrote:
> > ftp://ftp.yggdrasil.com/private/adam/ezusb/nofirmware-linux-2.4.3.patch
> > contains my first effort at removing the ezusb firmware from the kernel
> > and removal of code that is no longer u
From: "Greg KH" <[EMAIL PROTECTED]>
> On Thu, Apr 19, 2001 at 08:41:52AM -0700, Adam J. Richter wrote:
> > Anyhow, I am quite convinced that including the firmware in
> > a GPL'ed kernel module is copyright infringement. In the case of USB
> > kernel modules, I believe it actually infringes Yggdr
From: Richard Knutsson [mailto:[EMAIL PROTECTED]
Okay by me. Thanks Richard.
Signed-off-by: Stuart MacDonald <[EMAIL PROTECTED]>
..Stu
> Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
> ---
> Compile-tested with "allyes", "allmod" & "alln
From: Oliver Neukum [mailto:[EMAIL PROTECTED]
> this driver was long known to be unclean. This should fix all issues.
> However, I have no hardware to test, so I'd appreciate any comment.
We sent hardware to Greg KH. Can he get it to you?
Patch looks okay just reading it, but I currently don't h
There's a problem with multiple White Heats in one system; the
firmware fake devices each suck up a minor number, and when the real
devices start enumerating they start at the first free number. The
user-visible symptom is that sometimes (on a warm reboot the firmware
is already running, and the fa
From: Greg KH [mailto:[EMAIL PROTECTED]
> Heh, the whiteheat device doesn't even work on 2.6 right now due to a
> sysfs bug. This prevents all firmware-download devices from
> running, so
> I can't test this. Pat Mochel said he would look into that
> bug sometime
> next week.
Hm. I wasn't awa
From: Matterazzo Giorgio
> I've tried recompiling the whiteheat module with your
> suggestion without solving the problem.
The first problem was solved, this is a different issue.
> kernel: Debug: sleeping function called from invalid context at
> mm/slab.c:2093
Functions that sleep aren't allo
From: Pete Zaitcev [mailto:[EMAIL PROTECTED]
> On Wed, 20 Apr 2005 11:28:39 -0700, Greg KH <[EMAIL PROTECTED]> wrote:
> > On Wed, Apr 20, 2005 at 08:26:29PM +0200, Oliver Neukum wrote:
> > > /* shutdown our bulk reads and writes */
> > > spin_lock_irqsave(&info->lock, flags);
> > > list_for_
I've been having problems with the WhiteHEAT driver update and getting
bulk queueing to work. Then I noticed that not one of the other serial
drivers does bulk queueing on the read side. I changed my driver to
also not do queueing on the read (IN) side, and everything works.
I've searched the list
From: Alan Stern [mailto:[EMAIL PROTECTED]
> I can't answer your questions directly. However you should
> note that 2.4
> has _two_ UHCI drivers: uhci.c and usb-uhci.c. Maybe one of
> them works
> with bulk queuing and the other doesn't.
I suppose I should have specified that I'm using uhci
I'm updating our WhiteHEAT driver, and would like to have URB queueing
working. I'm using drivers/usb/host/uhci.c. After some time of
submitting queued OUT URBS, the system stops. uhci_interrupt() stops
being entered, ie, the hardware stops generating interrupts. My
machine is still fine in all oth
From: On Behalf Of David Brownell
> My advice continues to be to strongly avoid using bulk queueing
> on 2.4 kernels ... on 2.6 it's even in the regression test suite,
> but it took some time for it to be reliable even there. On 2.4,
> having it work is more luck than anything else. On 2.6, havin
The serial sub-drivers (whiteheat.c is one) have to call
tty_flip_buffer_push() somehow. Queueing the task means it runs from
(timer) interrupt context. Calling it directly means a) low_latency is
set; runs from sub-driver rx-side interrupt context or b) low_latency
is *not* set and it's queued, se
From: On Behalf Of Greg KH
> In 2.6, throttle can be called in interrupt context too. See
> the recent
> visor fix that was required for this.
patch-2.6.11 and patch-2.6.10 don't contain the fix you are refering
to. Where am I looking?
> > So it seems to me that usbserial is fundamentally broke
From: On Behalf Of Pete Zaitcev
> On Thu, 2 Jun 2005 21:43:46 -0400, "Stuart MacDonald"
> <[EMAIL PROTECTED]> wrote:
>
> > So, flush_to_ldisc() is running in interrupt context. It
> can call back
> > into usbserial.c in a number of ways, specifically ser
From: On Behalf Of Ian Abbott
> The URB queueing stuff in ftdi_sio was implemented some time
> before the
> the problems with the uhci driver were known. I guessed I
> lived in hope
> that it would get fixed one day. (I even tried debugging it with
> printk's, but got horribly lost. I would
From: Pete Zaitcev [mailto:[EMAIL PROTECTED]
> On Fri, 3 Jun 2005 11:35:01 -0400, "Stuart MacDonald"
> <[EMAIL PROTECTED]> wrote:
> http://marc.theaimsgroup.com/?l=linux-usb-devel&m=109646810201898&w=2
>
> Yes, that's the
From: Greg KH [mailto:[EMAIL PROTECTED]
> On Fri, Jun 03, 2005 at 11:30:01AM -0400, Stuart MacDonald wrote:
> > From: On Behalf Of Greg KH
> > > In 2.6, throttle can be called in interrupt context too. See
> > > the recent
> > > visor fix that was required
From: Alan Stern [mailto:[EMAIL PROTECTED]
> If there's anything in particular you need to know or are
> interested in, I
> might be able to help. Bear in mind that the 2.4 drivers are
> much more
> complicated and much less reliable than the 2.6 driver.
Thanks, I appreciate it. So...
Why d
From: Greg KH [mailto:[EMAIL PROTECTED]
> On Fri, Jun 03, 2005 at 11:30:01AM -0400, Stuart MacDonald wrote:
> > From: On Behalf Of Greg KH
> > > In 2.6, throttle can be called in interrupt context too. See
> > > the recent
> > > visor fix that was required
From: Alan Stern [mailto:[EMAIL PROTECTED]
> However, there is one possibility... Older Intel UHCI
> hardware (the PIIX3
> Neptune chipset) has an erratum that causes the controller
> sometimes to
> update a completed TD's status but not update the QH's
> element pointer.
> As a result the c
From: [EMAIL PROTECTED]
> Its a design decision for the tty layer. You should choose
> whatever is
> best there and the drivers will have to adapt.
I agree.
..Stu
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
42 matches
Mail list logo
