On Tuesday 05 October 2004 4:54 pm, Andrew Morton wrote:
>
> USB deadlock in Greg's current -bk. (scroll right to the end)
There's a bug in PCI driver registration, fix available, which probably
explains this whole thing. It mis-initialized UHCI, which caused a series
of problems with deadlock
USB deadlock in Greg's current -bk. (scroll right to the end)
Begin forwarded message:
Date: Tue, 5 Oct 2004 19:13:00 -0400
From: Ed Tomlinson <[EMAIL PROTECTED]>
To: Andrew Morton <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: 2.6.9-rc3-mm2 ip_conntrack problems
On Monday 04 October
This patch adds the Delorme Earthmate usb gps and the Cypress hid->com rs232 adapter
to hid-core's device blacklist. This is done to make way for the cypress_m8 driver
being released 9/30/04.
Signed-off-by: Lonnie Mendez <[EMAIL PROTECTED]>
--- a/drivers/usb/input/hid-core.c 2004-09-30 16:18:4
This patch adds the cypress_m8 usb-serial driver for the Delorme Earthmate usb gps and
the Cypress hid->com rs232 adapter to the kernel tree.
Signed-off-by: Lonnie Mendez <[EMAIL PROTECTED]>
--- a/MAINTAINERS 2004-10-05 08:36:10.540212400 -0500
+++ b/MAINTAINERS 2004-10-05 08:37:52.973640152 -05
This patch adds equal support for interrupt out transfers to the usb-serial core to
match the current interrupt in support. It also improves a few debug messages,
nothing major. This is necessary for the cypress_m8 driver being released 9/30/04.
Signed-off-by: Lonnie Mendez <[EMAIL PROTECTED]>
For those interested, here are the changes:
-call to set_ldisc in cypress_set_termios removed
-kept TCSETS/TCGETS in cypress_ioctl as they were indeed necessary
-set up proper flagging of parity errors on packets sent to tty layer
-added missing return to cypress_interrupt_write_callback
David Brownell a écrit :
>
> On Monday 04 October 2004 5:05 pm, Gaël Roualland wrote:
> >
> > I first noticed the problem on 2.6.8.1, and could reproduce it on
> > 2.6.9-rc3. Detailled information gathered with kdb at the time of the
> > oops follows.
>
> This looks like a known bug, fixed in bk-
Am Montag, 27. September 2004 10:56 schrieb Georg C. F. Greve:
> FYI:
>
> To make tracking things easier, I filed this as
>
> http://bugme.osdl.org/show_bug.cgi?id=3470
>
> on the kernel bugzilla.
Does it hang if you have removed the card, too?
Regards
Oliver
---
On Tue, Oct 05, 2004 at 03:46:09PM -0400, Alan Stern wrote:
> > > > 90% of the time, I can
> > > > work around by re-issuing the request (once). But the other 10% of the
> > > > time, *both* requests succeed--even the original one that returned
> > > > -EPIPE.
> > >
> > > How do you know the req
On Tuesday 05 October 2004 12:32 pm, Pavel Machek wrote:
> Hi!
>
> > One significant example involves USB mice. If they were to be
> > suspended (usb_suspend_device) after a few seconds of inactivity,
> > that change could often spread up the device tree and let the
> > USB host controller stop D
On Tue, 5 Oct 2004, Geoff Oakham wrote:
> > > It's not an endpoint stall (clear_halt() fails).
> >
> > What do you mean by that? I don't think there's any way to get -EPIPE
> > other than by receiving a STALL token. And what do you mean, clear_halt()
> > fails? In what way does it fail? (No
Hi!
> One significant example involves USB mice. If they were to be
> suspended (usb_suspend_device) after a few seconds of inactivity,
> that change could often spread up the device tree and let the
> USB host controller stop DMA access. Some x86 CPUs could
> then enter C3 and save a couple Wat
On Tue, 5 Oct 2004, martin f krafft wrote:
> also sprach Alan Stern <[EMAIL PROTECTED]> [2004.10.05.2016 +0200]:
> > See if you can find out exactly what happens during the USB phase when you
> > stop hotplug,
>
> As in, strace?
That's one way. If the programs are simply shell scripts, you can
also sprach Alan Stern <[EMAIL PROTECTED]> [2004.10.05.2016 +0200]:
> See if you can find out exactly what happens during the USB phase when you
> stop hotplug,
As in, strace?
> Also, post the system log for that time period. And make sure you
> have turned on the USB debugging option in the ker
On Tue, 5 Oct 2004, martin f krafft wrote:
> also sprach Alan Stern <[EMAIL PROTECTED]> [2004.10.05.1754 +0200]:
> > The most important thing as far as I'm concerned is to learn what
> > sequence of operations caused the oops you got before.
>
> Okay, I think I can definitely say that the kernel
also sprach Alan Stern <[EMAIL PROTECTED]> [2004.10.05.1754 +0200]:
> The most important thing as far as I'm concerned is to learn what
> sequence of operations caused the oops you got before.
Okay, I think I can definitely say that the kernel oops only happens
when I stop hotplug. Doing so causes
On Mon, Oct 04, 2004 at 11:29:52PM -0700, Pete Zaitcev wrote:
> Hi, Guys:
>
> Does anyone know a reason other than memory consumption to fetch string
> descriptors from a live device? That Dell semaphore continues to bug me.
> Why don't just read those descriptors once. Are they changing often?
T
On Tuesday 05 October 2004 16:56, David Brownell wrote:
> > Date: Tue, 5 Oct 2004 11:25:04 +0200
> > From: Dominik Karall <[EMAIL PROTECTED]>
> > To: Andrew Morton <[EMAIL PROTECTED]>
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: 2.6.9-rc3-mm2
> >
> > ...
> > i get a lot of usb errors on boot. they ap
On Tue, Oct 05, 2004 at 11:16:06AM -0400, Alan Stern wrote:
> > One of my control messages is returning 'EPIPE' when my system is under
> > heavy load. I'm stumped; does anyone have any suggestions?
>
> You're working on a kernel driver for this device, right? What does the
> device do?
The dr
also sprach Alan Stern <[EMAIL PROTECTED]> [2004.10.05.1754 +0200]:
> Which messages exactly are you seeing?
As stated in my original post:
usb 4-6: new high speed USB device using address 5
usb 4-6: control timeout on ep0in
usb 4-6: device not accepting address 5, error -71
However, it seems th
On Tue, 5 Oct 2004, martin f krafft wrote:
> Okay, I rebooted and am seeing these messages again...
Which messages exactly are you seeing?
> So now I want to try what you are proposing, but I cannot seem to
> unload hci_usb:
>
> ERROR: Module hci_usb is in use
I said to unload uhci-hcd, not
On Mon, 4 Oct 2004, Geoff Oakham wrote:
> Hi there,
>
> One of my control messages is returning 'EPIPE' when my system is under
> heavy load. I'm stumped; does anyone have any suggestions?
You're working on a kernel driver for this device, right? What does the
device do?
> It's not an endpoi
On Tue, 5 Oct 2004, luzt wrote:
> hi,everyone:
> i have some question when reading kernel 2.6.8 uhci_start.
<...>
> i get the follow table from the above code.
> ==
> frame skelqh
>
> 0 skel_intr1_qh
> 1 skel_intr2_qh
> 2 skel_intr4_qh
> 3 skel_intr2_qh
> 4 skel_intr8_qh
> Date: Tue, 5 Oct 2004 11:25:04 +0200
> From: Dominik Karall <[EMAIL PROTECTED]>
> To: Andrew Morton <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: 2.6.9-rc3-mm2
>
> ...
> i get a lot of usb errors on boot. they appear since -rc2-mm1.
> below the relevant part of dmesg output.
It's s
On Mon, 4 Oct 2004, Pete Zaitcev wrote:
> Hi, Guys:
>
> Does anyone know a reason other than memory consumption to fetch string
> descriptors from a live device? That Dell semaphore continues to bug me.
> Why don't just read those descriptors once. Are they changing often?
As far as I know, ther
Hi Ian,
Ian Campbell writes:
> Early in September you were working on a driver for the isp1362 based
> upon your work with the ohci-emu/sl811 stuff. I'm just wondering what
> the current status of this is. Do you have a webpage with patches or
> anything like that?
>
Yes. You can find the current
On Tuesday 05 October 2004 6:29 am, Colleen Przybyla wrote:
> Hello,
>
> I recently used the GadgetFS sample code as a template to create a USB wheel
> mouse.
I'm glad to hear that ... folk haven't talked much about using
GadgetFS. I think that's because it's not a drop-in solution;
someone has
Hello,
I recently used the GadgetFS sample code as a template to create a USB wheel
mouse. I am now looking in to adding force feedback capabilities to this
simulation - when a certain place is triggered on the host computer, the
Linux 'gadget' should vibrate (like a cell phone vibrator). I have
Hi:
There is a long-standing devfs_unregister oops in hid/hiddev. It's
caused by hid calling hiddev_exit before unregistering itself which
in turn calls hiddev_disconnect.
hiddev_exit removes the directory which contains the hiddev devices.
Therefore it needs to be called after the hiddev device
hi,everyone:
i have some question when reading kernel 2.6.8 uhci_start.
kernel2.6.8 uhci-hcd.c uhci_start():
code from uhci_start
uhci->skel_int128_qh->link =
uhci->skel_int64_qh->link =
uhci->skel_int32_q
Begin forwarded message:
Date: Tue, 5 Oct 2004 11:25:04 +0200
From: Dominik Karall <[EMAIL PROTECTED]>
To: Andrew Morton <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: 2.6.9-rc3-mm2
On Monday 04 October 2004 11:02, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akp
> The configuration C: should change to show change in active configuration.
> The interface I: changes whenever a device is plugged/unplugged and a
> driver grabs the device. [...]
You misunderstood my question. Bother pieces of information you mentioned
are already kept in the core. We do not a
also sprach Alan Stern <[EMAIL PROTECTED]> [2004.10.04.2325 +0200]:
> Is this reproducible? What happens if you do "rmmod uhci-hcd"
> yourself by hand, without involving the hotplug programs?
Okay, I rebooted and am seeing these messages again...
So now I want to try what you are proposing, but
Hi Pete,
The configuration C: should change to show change in active configuration.
The interface I: changes whenever a device is plugged/unplugged and a
driver grabs the device. So a single read would not do for these.
It is a inconvenient to obtain this information, but sometimes useful.
Rega
34 matches
Mail list logo
