David Brownell wrote:
> On Thursday 28 April 2005 11:59 pm, Phil Dibowitz wrote:
>
>>David Brownell wrote:
>>
>>>As always, it's great to see hardware vendors supporting Linux!
>>
>>I can only hope their drivers are better than their software
>
>
> That may be so, but it's still much better whe
Hi,
My patch adding PM support for zd1201 didn't check for the device on
resume, which can oops if the device has been removed.
This patch fixes it.
Thanks,
Signed-off-by: Colin Leroy <[EMAIL PROTECTED]>
--- a/drivers/usb/net/zd1201.c 2005-05-01 11:25:54.0 +0200
+++ b/drivers/usb/net/z
Hello,
I've found a very rewarding career -- built on a part-time basis,
and I thought you might be interested.
Our system is AUTOMATED so you don't have to worry about personal
rejection. And, when you do find someone who's really serious
aboutimproving their finances, our automated system
Hub driver is using SIGKILL to terminate khubd. Unfortunately on a number of
distributions switching init levels implicitly does "killall -9", killing
khubd. The only way to restart it is to reload USB subsystem.
Is signal usage in this case really needed? What about replacing it with
simple fl
Hi!
I've been playing quite a bit with the gnuradio[1] project's USRP[2]
recently. One of the key issues with the USRP is to get the highes
possible USB2.0 throughput (since the ADC and DAC's actually outperform
the slow USB2.0 bus). Another key issue is that for digital signal
processing you ne
On Sun, May 01, 2005 at 09:29:41PM +0200, Harald Welte wrote:
> Hi!
>
> I've been playing quite a bit with the gnuradio[1] project's USRP[2]
> recently. One of the key issues with the USRP is to get the highes
> possible USB2.0 throughput (since the ADC and DAC's actually outperform
> the slow US
We're hitting the "connect-debounce failed" message on a remote system,
in 2.6.12-rc3 (no changes).
There are two root hubs. One has a simple USB I/O board attached, which
we access directly with usbfs. (It shows up as an HID, but hid.o is not
loaded.) The other has a bus-powered hub attached.
On Sat, 30 Apr 2005, Zoont Foomby wrote:
> Hello All You Wise Developer Types,
>
> I would like to implement a simple kernel hack which Involves the USB
> drivers. I would like to identify a USB device by VendorID and
> ProductID and have linux treat it as a device for which it does not
> have an
On Sun, 1 May 2005, Andrey Borzenkov wrote:
> Hub driver is using SIGKILL to terminate khubd. Unfortunately on a number of
> distributions switching init levels implicitly does "killall -9", killing
> khubd. The only way to restart it is to reload USB subsystem.
>
> Is signal usage in this case
Am Sonntag, 1. Mai 2005 21:29 schrieb Harald Welte:
> A quick browse through the EHCI specification and the ehci linux hcd
> driver revealed that it should be technically possible to:
>
> 0) open an usbdevfs file like usual
> 1) set up a mmap()ed buffer between kernel and userspace
> 2) create one
On Sun, 2005-05-01 at 17:01 -0400, Alan Stern wrote:
> On Sun, 1 May 2005, Andrey Borzenkov wrote:
>
> > Hub driver is using SIGKILL to terminate khubd. Unfortunately on a number
> > of
> > distributions switching init levels implicitly does "killall -9", killing
> > khubd. The only way to rest
On Sun, 1 May 2005 16:43:30 -0400, Glenn Maynard <[EMAIL PROTECTED]> wrote:
> There are two root hubs. One has a simple USB I/O board attached, which
> we access directly with usbfs. [] The other has a bus-powered hub attached.
> The problem only happens when that hub is attached (even with nothi
Alan Stern <[EMAIL PROTECTED]> wrote:
>
> On Sun, 1 May 2005, Andrey Borzenkov wrote:
>
> > Hub driver is using SIGKILL to terminate khubd. Unfortunately on a number
> > of
> > distributions switching init levels implicitly does "killall -9", killing
> > khubd. The only way to restart it is to
On 5/1/05, Andrew Morton <[EMAIL PROTECTED]> wrote:
> Alan Stern <[EMAIL PROTECTED]> wrote:
> >
> > On Sun, 1 May 2005, Andrey Borzenkov wrote:
> >
> > > Hub driver is using SIGKILL to terminate khubd. Unfortunately on a number
> > > of
> > > distributions switching init levels implicitly does "ki
Nish Aravamudan <[EMAIL PROTECTED]> wrote:
>
> > - /* Send me a signal to get me die (for debugging) */
> > do {
> > hub_events();
> > - wait_event_interruptible(khubd_wait,
> > !list_empty(&hub_event_list));
> > + wait_event_interruptible(
I'm using the ISP1362 HCd recently posted to this mailing list, and have
it detecting the chip correctly, and passing the CHIP_BUFFER_TEST, but
it doesn't appear to be sending any interrupts. At this stage I cannot
be sure it isn't a hardware problem, but I was wondering if there were
any settings
On Sunday 01 May 2005 17:46, Nish Aravamudan wrote:
> On 5/1/05, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > Alan Stern <[EMAIL PROTECTED]> wrote:
> > >
> > > On Sun, 1 May 2005, Andrey Borzenkov wrote:
> > >
> > > > Hub driver is using SIGKILL to terminate khubd. Unfortunately on a
> > > > numbe
On 5/1/05, Andrew Morton <[EMAIL PROTECTED]> wrote:
> Nish Aravamudan <[EMAIL PROTECTED]> wrote:
> >
> > > - /* Send me a signal to get me die (for debugging) */
> > > do {
> > > hub_events();
> > > - wait_event_interruptible(khubd_wait,
> > > !list_empt
On Sun, May 01, 2005 at 02:52:41PM -0700, Pete Zaitcev wrote:
> If I were you, I would make very sure that khubd is not holding any
> locks while poking at bus #1 which prevent I/O at bus #2. SysRq is your
> friend. You can do it remotely with "echo t > /proc/sysrq-trigger".
I've attached the log
Hello from Gregg C Levine
In going over the LinkSys website I see three USB Network devices. All three
naturally do not mention Linux on their portion of the site regarding
operating systems.
Is the USB stack's networking driver vendor nuetral?
Here's the thing, I've got an Epson printer plugged
David:
I found part of the source for the trouble I've had with root-hub
suspend/resume on OHCI. It's these two lines near the end of
ohci-hub.c:ohci_hub_suspend():
if (status == 0)
hcd->state = HC_STATE_SUSPENDED;
That gets executed even if the root hub was already su
On Sunday 01 May 2005 1:37 pm, Eric Blossom wrote:
>
> I think the biggest benefit would be in giving us potentially lower
> latency. Right now, our throughput bottleneck is in the firmware in
> the FX2. We currently get 32MB/sec. We know that at least for
> unidirectional apps (might not apply
On Sunday 01 May 2005 2:04 pm, Oliver Neukum wrote:
> Am Sonntag, 1. Mai 2005 21:29 schrieb Harald Welte:
> > A quick browse through the EHCI specification and the ehci linux hcd
> > driver
This should be true of any HCD that supports DMA, FWIW.
EHCI is probably most interesting because it's the
On Sunday 01 May 2005 1:43 pm, Glenn Maynard wrote:
> We're hitting the "connect-debounce failed" message on a remote system,
> in 2.6.12-rc3 (no changes).
Which among other things is an "infinite loop during enumeration"
problem. There are a few of those lurking still.
> There are two root hub
On Sunday 01 May 2005 6:31 pm, Gregg C Levine wrote:
> Is the USB stack's networking driver vendor nuetral?
There are several drivers. Some are vendor-specific, some
know about the quirks of specific hardware. And for some
reason, vendors haven't yet gotten into the habit of making
their webpage
On Sun, 1 May 2005 21:31:45 -0400 Gregg C Levine wrote:
| Hello from Gregg C Levine
| In going over the LinkSys website I see three USB Network devices. All three
| naturally do not mention Linux on their portion of the site regarding
| operating systems.
|
| Is the USB stack's networking driver
26 matches
Mail list logo
