On Fri, 26 Nov 2004 09:00:20 -0800, David Brownell <[EMAIL PROTECTED]> wrote:
> (Where you've got a hub at period 256 ms,
> and the MCT wants both 1msec and 2msec periods ... there's
> no way to pack a schedule according to that shortcut.)
You're right, of course. Using an old 1.1 hub instead of
I'm sure the bug requestor misidentified a changeset. The one which I posted
and which dealt with BTC keyboards actually came from Mosberger-Tang and it
was an obviously missing pointer advancement. It had nothing to do with any
report setting in the HID.
This is something Vojtech has to look into
您好！
三实总部可为您的项目提供融资服务，项目条件如下：
基本方式：按照中国法律规定，双方向当地政府申请成立"中外合资、合作公司"，资金打到合作公司帐上后，外方不参与合作、合资公司的经营。合作公司的一切经营风险，法律责任及税收均由中方承担，外方只是每年收取固定的利润。如合作期间不能按时付固定利润，外方有权接手管理或拍卖合资企业回收资金。
合作类别：适合于中方的基础建设、高新技术产业开发、农副产品深加工、养殖业、企业扩建、缺乏流动资金等的项目。
合作形式引资：
境外引资：用中方项目及财产担保，以合作的方式
On Wednesday 24 November 2004 22:15, Pete Zaitcev wrote:
> Hi, guys:
>
> I found that any attempt to connect an MCT U232 serial converter (mct_u232
> driver) to EHCI causes failures of usb_submit_urb with ENOSPC. This happens
> at the very first interrupt URB submission. Anyone got any ideas how t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello everyone,
I was just thinking about using an USB printer interface cable
as a cheap interface for some homebrewn hardware. However, it
would be truly convenient to be able to use all the output lines
that the standard parallel port offers: Sele
On Wed, 24 Nov 2004, Pete Zaitcev wrote:
> Hi, guys:
>
> I found that any attempt to connect an MCT U232 serial converter (mct_u232
> driver) to EHCI causes failures of usb_submit_urb with ENOSPC. This happens
> at the very first interrupt URB submission. Anyone got any ideas how to
> figure what
> Hi Michael,
>
> Michael wrote:
> > Hi. Here's some more data dumps:
> >
[...]
> >
> > I'm not sure that I'm using virtual addresses for any of these.
> > I didn't change that aspect, at any rate.
> >
> So your architecture has virtual == real addresses for main
> memory?
>
I don't know, but
On Friday 26 November 2004 13:10, Alan Stern wrote:
> David:
>
> Attached are two patches. The first contains a number of cleanups and
> some small bug fixes for the hub driver, things I will submit
> separately (along with additional cleanups) in the near future. .
Cool, I'll take a look and ma
> If you got the "IRQ INTR_SF lossage" diagnostic, there's clearly
> some problem with IRQ handling after the resume ... is the iBook
> firmware (or hardware) doing wierd stuff so that the normal PCI
> IRQ calls stopped working?
The iBook hardware isn't doing anything special, the controller is j
Hello
On Thu, 25 Nov 2004, Guennadi Liakhovetski wrote:
> On Wed, 24 Nov 2004, Greg KH wrote:
> > On Wed, Nov 24, 2004 at 11:57:15PM +0100, Guennadi Liakhovetski wrote:
> > > 2-way running 2.6.9 the onboard UHCI device is configured to IRQ 9 via
> > > XT-PIC???
> > >
> > >CPU0
> I adding printing out of the td_flags, and it seems that every
> time
> that it gets the condition code of 0xA (which is reserved in the
> OHCI spec, but is defined as TD_BUSY in ohci-isp1362-emu.c), it
> gets stuck in this loop.
>
> So it seems that it doesn't handle the busy condition. It lo
On Fri, 2004-11-26 at 09:57 -0800, David Brownell wrote:
> On Friday 26 November 2004 09:37, Colin Leroy wrote:
> > On 26 Nov 2004 at 09h11, David Brownell wrote:
> > > This isn't a good patch either... maybe your best
> > > bet would be to find out why the IRQs stopped getting
> > > delivered.
> >
On Friday 26 November 2004 13:01, Alan Stern wrote:
>
> Okay, fine. My original point still stands: If wakeup_enabled isn't set
> then the generic hub autosuspend code won't suspend a hub. A root hub can
> do whatever the HCD likes under such circumstances, but I still think it
> should do its be
David:
Attached are two patches. The first contains a number of cleanups and
some small bug fixes for the hub driver, things I will submit
separately (along with additional cleanups) in the near future. The
only aspect of interest here is that it adds code to set
udev->dev.power.power_state when
On Wed, 24 Nov 2004, David Brownell wrote:
> On Wednesday 24 November 2004 13:25, Alan Stern wrote:
> > On Wed, 24 Nov 2004, David Brownell wrote:
> >
> > > On Tuesday 23 November 2004 14:15, Alan Stern wrote:
> > > > It's not a question of using timers or anything else. If wakeup_enabled
> > >
On Thu, 25 Nov 2004, DMR wrote:
> Thanks for your respon.
>
> I'm a newbie in linux USB device driver development.
> My detailed problem is described below.
> --
> My Problem in device driver is urb device pointer from usb core driver is
> NULL.
> Case 1(Normal):
> After resett
> Actually, I had applied your patch to be on the safe side, (that
> is, the change in hub.c from msleep(10) to msleep(20) before
> getting all of this to it's current state. I didn't test it before
> this change, so I'm not sure how much it affects it.
Try to increase the msleep(20) further if
On Friday 26 November 2004 08:47, Greg KH wrote:
> On Thu, Nov 25, 2004 at 02:56:59PM +0530, Mohan V wrote:
> > >On Wed, Nov 24, 2004 at 11:16:18AM +0530, Mohan V wrote:
> > >>
> > >>I am using a usb-char driver of linux-2.4.19-rmk7-pxa1 kernel for PPP.
> > >
> > I got the pointer. ftp://source.mv
On Friday 26 November 2004 08:54, Colin Leroy wrote:
> On 26 Nov 2004 at 08h11, David Brownell wrote:
>
> Hi,
>
> > The infinite loop means that something trashed the stack, yes?
> >
> > The "limit-- < -1000" test below should never be able to succeed
> > unless the previous "limit-- == 0" test
On Friday 26 November 2004 09:37, Colin Leroy wrote:
> On 26 Nov 2004 at 09h11, David Brownell wrote:
> > This isn't a good patch either... maybe your best
> > bet would be to find out why the IRQs stopped getting
> > delivered.
>
> It's probably a linux-wlan-ng issue...
I suspect PPC resume iss
Hi Michael,
Michael wrote:
> Hi. Here's some more data dumps:
>
> (gdb) p /x *td
> $3 = {hwINFO = 0xa2cc, hwCBP = 0xc51f3200,
> hwNextTD = 0xc115e0c0, hwBE = 0xc51f3fff, hwPSW = {0x0},
> index = 0x0, ed = 0xffc0d040, td_hash = 0x0, next_dl_td =
> 0x0,
> urb = 0xc51eb8a0, t
On Friday 26 November 2004 02:30, Colin Leroy wrote:
> @@ -375,6 +375,11 @@
> spin_unlock_irqrestore (&ohci->lock, flags);
> set_current_state (TASK_UNINTERRUPTIBLE);
> schedule_timeout (1);
> + if (limit < 1000) {
> + ohci_w
Hello again.
> On Thu, 25 Nov 2004, Michael wrote:
> >
> > Sorry, a quick correction. The DPRINTK line in there wasn't
> > used for the output I included. In fact, with that debug line
> > there, it doesn't enumerate or send any USB traffic at all!
>
> Can you get rid of the enumeration problem
On 26 Nov 2004 at 09h11, David Brownell wrote:
Hi,
> So instead of waiting a moment for the ED to finish
> its normal processing and move from state ED_UNLINK
> into ED_IDLE, you want to always clobber the whole
> USB device tree attached to that bus? That'd happen
> quite routinely.
Yeah. Sor
Colin reported off-line that he's using 2.6.9
rather than 2.6.10-rc2 or newer ... so it's
actually expected that his kernel misbehave
with USB PM. The workaround, for all 2.6
kernels until very recently, is to rmmod the
HCDs before entering a system sleep state.
I think that starting in 2.6.10 it
On 26 Nov 2004 at 08h11, David Brownell wrote:
Hi,
> The infinite loop means that something trashed the stack, yes?
>
> The "limit-- < -1000" test below should never be able to succeed
> unless the previous "limit-- == 0" test got trashed by having
> something obliterate the stack.
Sure? the
On Thu, Nov 25, 2004 at 02:56:59PM +0530, Mohan V wrote:
> Greg KH wrote:
>
> >On Wed, Nov 24, 2004 at 11:16:18AM +0530, Mohan V wrote:
> >
> >
> >>Hello All,
> >>
> >>I am using a usb-char driver of linux-2.4.19-rmk7-pxa1 kernel for PPP.
> >>
> >>
> >
> >Do you have a pointer to the source c
On Thursday 25 November 2004 10:17, Colin Leroy wrote:
> Hi,
>
> Following patch fixes an endless loop that happens after having
> slept and resumed my iBook with a linux-wlan-ng controller plugged in,
> removed the stick and plugged it back (getting "IRQ lossage" message).
The infinite loop mea
--- Lothar Wassmann <[EMAIL PROTECTED]> wrote:
> Hi,
> > However, I'm running into a bug when I try to write to it.
> > I'm still trying to decipher it all, but if you have any ideas,
> > they are welcome.
> >
> > Thanks!
> > Mike
> >
[...]
> What's the value of td->hwNextTD? Since you are ovi
Hi,
Following patch fixes an endless loop that happens after having
slept and resumed my iBook with a linux-wlan-ng controller plugged in,
removed the stick and plugged it back (getting "IRQ lossage" message).
It supercedes the previous one where
.I hadn't noticed limit was unsigned,
.Decrement
On Thursday 25 November 2004 12:20, Sara Fonseca wrote:
> Hi,
>
> my USB device needs to present itself as a mass storage device, but
> needs also to be controled by our own driver that manages other
> functions(not storage).
> Do I need to simulate a hub?
No, you just need to implement a "compos
On Thu, 25 Nov 2004, Michael wrote:
>
> Sorry, a quick correction. The DPRINTK line in there wasn't used
> for the output I included. In fact, with that debug line there, it
> doesn't enumerate or send any USB traffic at all!
Can you get rid of the enumeration problem when you apply
the same f
Hi,
> However, I'm running into a bug when I try to write to it.
> I'm still trying to decipher it all, but if you have any ideas,
> they are welcome.
>
> Thanks!
> Mike
>
[...]
> while (td != NULL && ED_TAILP(ed) != td->td_dma) {
> u32 td_flags = get_hwinfo(td);
> DPRINTK("MWMDEBUG: td_flags
33 matches
Mail list logo
