On Wednesday 27 April 2005 11:02 pm, grant.kang wrote:
> Any suggestion ???
2.6.12-rc3 ... :)
---
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a
On Thu, Apr 28, 2005 at 02:02:04PM +0800, grant.kang wrote:
> Hi:
> I use linux-2.4.18 with pl2303 usb converter supported. I connect the USB
> Serial converter with DCE Device (like modem).
> When I type stty -F /dev/usb/tts/0 and display the device baudrate / termio
> setting.
> But , When I
Hi:
I use linux-2.4.18 with pl2303 usb converter supported. I connect the USB
Serial converter with DCE Device (like modem).
When I type stty -F /dev/usb/tts/0 and display the device baudrate / termio
setting.
But , When I connect to one 4-port prolific HUB, and connect to the Host
controller(O
On Thu, Apr 28, 2005 at 02:47:23AM +0200, Kay Sievers wrote:
> On Wed, Apr 27, 2005 at 04:14:08PM -0700, Patrick Mansfield wrote:
> > On Wed, Apr 27, 2005 at 05:21:10PM -0400, Alan Stern wrote:
> >
> > > David's right. Why did kobject_hotplug() move out of kobject_add() and
> > > into its callers
The keyboard gets properly recognized in BIOS.And even I could select
the kernel at bootloader options using the keyboard . But after the
kernel boots the key stroks and mouse movements are not recognized.
Thanks,
Shiju
On 4/28/05, Shiju Mathew <[EMAIL PROTECTED]> wrote:
> Hi Alan,
> I stop hald
Hi Alan,
I stop hald deamon and plugged in the usb cable and then started the
deamon. But with the same result as before. The same error messages
and the keystrocks and mouse movements are not recognized. I also
booted the system with the usb cable plugged in with the same result
as above.
Thanks,
On Wed, Apr 27, 2005 at 04:14:08PM -0700, Patrick Mansfield wrote:
> On Wed, Apr 27, 2005 at 05:21:10PM -0400, Alan Stern wrote:
>
> > David's right. Why did kobject_hotplug() move out of kobject_add() and
> > into its callers sometime after 2.6.11? In particular the invocation in
> > device_ad
On Wednesday 27 April 2005 2:32 pm, Alan Stern wrote:
>
> That's not in question. The issue is: Out of all the drivers floating
> around, which one should decide when a particular device can be suspended
> for lack of activity?
Erm, not just _one_ can do it. Certainly any interface's driver c
On Wed, Apr 27, 2005 at 05:21:10PM -0400, Alan Stern wrote:
> David's right. Why did kobject_hotplug() move out of kobject_add() and
> into its callers sometime after 2.6.11? In particular the invocation in
> device_add() is in the wrong place; it needs to come before
> bus_add_device() starts
On Wed, 27 Apr 2005, David Brownell wrote:
> I see your point, but do you see mine? Namely, that any hub
> will _only_ autosuspend. It's in reaction to something else
> happening, to be sure, but any notion that software directly
> tells any hub to suspend itself is purely an illusion that must
On Wed, 27 Apr 2005, David Zeuthen wrote:
> Hi,
>
> it seems that recent kernels (I'm using the Fedora 2.6.11-1.1268_FC4
> kernel which I believe is based off 2.6.12-rc3 and AFAIK it doesn't have
> any invasive patches in that area) has changed behavior wrt hotplug
> event ordering. In [1], I've
(please keep me Cc'ed, I'm not subscribed to linux-usb-devel)
Hi,
it seems that recent kernels (I'm using the Fedora 2.6.11-1.1268_FC4
kernel which I believe is based off 2.6.12-rc3 and AFAIK it doesn't have
any invasive patches in that area) has changed behavior wrt hotplug
event ordering. In [
On Wednesday 27 April 2005 12:14 pm, Alan Stern wrote:
> On Wed, 27 Apr 2005, David Brownell wrote:
>
> > The root hub autosuspend is different though; it turns off
> > the flow of SOF packets, just like setting the suspend bit
> > on the parent port of an external hub.
>
> Right again. And sett
> > I used the define 'USE_32BIT' to 0.
> > Isn't the ISP1362 16-bit only? You can do 32-bit accesses on
> > the 16-bit bus, but then you violate the (fussy) timing for
> > sure!
> >
> That depends on the capabilities of the processors memory
> interface. At least on PXA you can program the me
On Wed, 27 Apr 2005, David Brownell wrote:
> It should be the only EHCI patch in Greg's latest quilt set.
>
> http://marc.theaimsgroup.com/?l=linux-usb-devel&m=111281753127281&w=2
>
> ... I'd rather see 2.6.12 have that than the experimental usbnet
> patch that does seem to have been merged! :)
On Wednesday 27 April 2005 12:16 pm, Alan Stern wrote:
> On Wed, 27 Apr 2005, David Brownell wrote:
>
> > > > Note that both EHCI and OHCI already _have_ such logic in the hub_status
> > > > code ... but it wasn't sufficient before. There are a LOT of paths
> > > > through
> > > > usbcore and H
On Wed, 27 Apr 2005, David Brownell wrote:
> > > Calling remove() and probe() ought to work just fine, and after all
> > > those methods will always be well debugged. There was just a little
> > > bitty self-deadlock problem in the PM core to fix ...
> >
> > Has that been fixed yet? Didn't Paul
On Wed, 27 Apr 2005, David Brownell wrote:
> Hmm, but external hubs DO autosuspend: as soon as SOFs stop flowing
> from the parent, they suspend themselves (and their children).
> That's analagous to what a root hub does when the HC itself gets
> suspended.
Right.
> The root hub autosuspend is
Hi,
> The bigger problem, is that traffic stops after the first Class IN
> request, where I expect to get IN/OUT transactions. I also get a
> bunch of "irq24: nobody cared" messages throughout the
> above-mentioned behavior.
> What exactly does this mean? When does this happen? IRQ24 should
>
A
On first time, the card reader work.
After restart system. it stop.
If i disconnect usb and reconnect, folow message is displayed on
log/message:
Apr 26 23:12:27 helber kernel: usb 2-2.2: new full speed USB device
using uhci_hcd and address 4
Apr 26 23:12:27 helber kernel: usb 2-2.2: device descr
Hi,
> I needed to modify the drivers/usb/Makefile before it would compile
> in:
>
> diff -dbBurN linux-2.6.11-mm2/drivers/usb/Makefile
> linux-2.6.11-mm2-oscar4_usb/drivers/usb/Makefile
> --- linux-2.6.11-mm2/drivers/usb/Makefile 2005-04-25
> 15:29:50.0 -0500
> +++ linux-2.6.11-mm2-
Hello again. I'm having trouble with the isp1362-hcd driver, and
any insights (or tips on how to debug) would be greatly
appreciated.
I have an 'ellisys USB Tracker', so I can take a look at the
traffic on the bus. With the isp1362-hcd driver the way I have it
right now, a bunch of the GetDescri
On Wednesday 27 April 2005 8:17 am, Alan Stern wrote:
> On Wed, 27 Apr 2005, David Brownell wrote:
>
> > > Why should USB core's auto-suspend depend on CONFIG_PM? In
> > > particular, if this results in (at least partial)
> > > duplication of the auto-suspend functionality in HCDs.
> >
> > It
On Wednesday 27 April 2005 8:09 am, Alan Stern wrote:
> On Wed, 27 Apr 2005, David Brownell wrote:
>
> > Calling remove() and probe() ought to work just fine, and after all
> > those methods will always be well debugged. There was just a little
> > bitty self-deadlock problem in the PM core to fi
Hey. I nearly have this driver working (I hope), and I wanted to
give you some feedback so far on what I needed to do to get it into
my kernel.
I'm using a Sharp LH7A40x SoC, on my own custom board. This is
using the Philips ISP1362 USB-OTG controller, but I'm only using it
for host capability.
> To follow up on my findings, I just noticed that the call to
> usb_unlink_urb() returns -EINPROGRESS.
With this extra info everything seems clear. I will try to
do something about it tomorrow.
Ciao,
Duncan.
---
SF.Net email is sponsored b
Hi:
I'd like to write a driver for the following USB Serial device:
T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=ff(vend.) Sub=ff Prot=ff MxPS= 8 #Cfgs= 1
P: Vendor=067b ProdID=2313 Rev= 0.04
S: Manufacturer=Prolific Technology Inc.
S: Product=USB-Dual S
Peter Urbanec wrote:
>usb_start_wait_urb: wait_for_completion() enter
>timeout_kill(urb=802c0ec0)
>timeout_kill: usb_unlink_urb(urb=802c0ec0) enter
>timeout_kill: usb_unlink_urb(urb=802c0ec0) return
>
>
To follow up on my findings, I just noticed that the call to
usb_unlink_urb() returns -EINPR
Duncan Sands wrote:
>please do sysctl-t (or whatever it is on your platform) to get a process
>backtrace.
>
>
OK, I've instrumented bits and pieces of the kernel in order to get a
better understanding of what is going on. I don't have the exact source
of the problem yet, but I am closing in. Th
On Wednesday 27 April 2005 8:18 am, Alan Stern wrote:
> On Wed, 27 Apr 2005, David Brownell wrote:
>
> > > > > This morning I tried testing an EHCI controller. Its behavior was
> > > > > even
> > > > > more puzzling. ...
> > >
> > > Tried again with an unpatched 2.6.12-rc3 kernel under Fedora
On Wed, 27 Apr 2005, Shiju Mathew wrote:
> Hi,
> When I connect a duo usb keyboard/mouse to the linux system, neither
> the key stroks nor the mouse movements are recognised. The duo has a
> RF cradle with usb cable connected to the system. The keyboard and
> mouse are wireless. I get the followi
On Wed, 27 Apr 2005, David Brownell wrote:
> On Tuesday 26 April 2005 10:08 am, Alan Stern wrote:
> > On Tue, 26 Apr 2005, Olav Kongas wrote:
> >
> > > Also, remote wakeups can result in resuming of root hub only
> > > if device is not suspended. Was that correct?
>
> No; remote wakeup wakes up
Hello people, I am from Argentina and don´t speak and write Eglish so well,
therefore... sorry about my mistakes.
My problem is that I have to wirte a program under linux, to read
magnetics cards. The device is a USB Hardware HID compatible.
I have read a lot of documents and according to t
On Wednesday 27 April 2005 8:03 am, Olav Kongas wrote:
>
> On Wed, 27 Apr 2005, David Brownell wrote:
>
> > On Tuesday 26 April 2005 10:08 am, Alan Stern wrote:
> > > On Tue, 26 Apr 2005, Olav Kongas wrote:
> > >
> > > > Also, remote wakeups can result in resuming of root hub only
> > > > if dev
On Wed, 27 Apr 2005, David Brownell wrote:
> > > > This morning I tried testing an EHCI controller. Its behavior was even
> > > > more puzzling. ...
> >
> > Tried again with an unpatched 2.6.12-rc3 kernel under Fedora Core 3.
> > Here's a captured serial-console log, edited only to remove typ
On Wed, 27 Apr 2005, David Brownell wrote:
> > Why should USB core's auto-suspend depend on CONFIG_PM? In
> > particular, if this results in (at least partial)
> > duplication of the auto-suspend functionality in HCDs.
>
> It could be argued two different ways: that "hub autosuspend"
> should
On Wed, 27 Apr 2005, David Brownell wrote:
> > > If it can be guaranteed that the root hub is already suspended,
> > > including all the root hub timer wierdness, that's OK. But last
> > > I checked, that wasn't particularly straightforward. It may well
> > > be getting easier to do now with you
On Wed, 27 Apr 2005, David Brownell wrote:
> On Tuesday 26 April 2005 10:08 am, Alan Stern wrote:
> > On Tue, 26 Apr 2005, Olav Kongas wrote:
> >
> > > Also, remote wakeups can result in resuming of root hub only
> > > if device is not suspended. Was that correct?
>
> No; remote wakeup wakes u
On Wed, 27 Apr 2005, David Brownell wrote:
> > > Right, but if usbcore says "activate the root hub" then port change IRQs
> > > can come immediately. And then how can the HCD tell usbcore to collect
> > > that status, if hasn't registeed the root hub?
> >
> > It can't. Or with patch as478b, it
On Tuesday 26 April 2005 11:55 pm, Olav Kongas wrote:
>
> On Tue, 26 Apr 2005, Alan Stern wrote:
> > Actually it probably will. That might be a good reason to keep a minimal
> > auto-suspend capability in the HCDs, for use when CONFIG_PM is off.
>
> Why should USB core's auto-suspend depend on
On Tuesday 26 April 2005 10:08 am, Alan Stern wrote:
> On Mon, 25 Apr 2005, David Brownell wrote:
>
> > On Sunday 24 April 2005 9:21 am, Alan Stern wrote:
> > >
> > > There's no recursion. When the PCI device is suspended or
> > > resumed, the code does _not_ suspend or resume the root hub
>
On Tuesday 26 April 2005 12:32 pm, Alan Stern wrote:
> On Mon, 25 Apr 2005, David Brownell wrote:
> > On Monday 25 April 2005 8:36 am, Alan Stern wrote:
>
> > > This morning I tried testing an EHCI controller. Its behavior was even
> > > more puzzling. ...
>
> Tried again with an unpatched 2.6.
Hi,
The log message got truncated. Here is the remaining log message.
Apr 27 10:52:36 localhost kernel: Keyboard.00cb
Apr 27 10:52:36 localhost kernel: Keyboard.00cc
Apr 27 10:52:36 localhost kernel: Keyboard.00cd
Apr 27 10:52:36 localhost kernel: Keyboard.00ce
Apr
On Tuesday 26 April 2005 10:08 am, Alan Stern wrote:
> On Tue, 26 Apr 2005, Olav Kongas wrote:
>
> > Also, remote wakeups can result in resuming of root hub only
> > if device is not suspended. Was that correct?
No; remote wakeup wakes up the device that was suspended plus any
parent devices that
On Tuesday 26 April 2005 11:33 am, Alan Stern wrote:
> On Mon, 25 Apr 2005, David Brownell wrote:
>
> > On Friday 22 April 2005 8:23 pm, Alan Stern wrote:
> >
> > > In theory an HCD shouldn't care one way or another about whether the root
> > > hub has been registered. As Oliver likes to say, i
Hi,
When I connect a duo usb keyboard/mouse to the linux system, neither
the key stroks nor the mouse movements are recognised. The duo has a
RF cradle with usb cable connected to the system. The keyboard and
mouse are wireless. I get the following errors on connecting the usb
cable;
drivers/usb/
Новый мини-отель «Кристофф» (открыт в 2004 г.)
идеально расположен в самом центре Санкт-Петербурга, на Пяти Углах, в нескольких минутах пешей
прогулки
от Невского проспекта
=15 уютных 1-2-местных номеров=
в каждом номере:
• приточно-вытяжная вентиляция
• кондиционеры Daikin
• мини-бары
•
47 matches
Mail list logo
