On Fri, Aug 11, 2006 at 09:14:57PM -0300, Marcelo Tosatti wrote:
>
> The reason for so much delay was a serious accident which resulted in 2
> weeks of hospitalization with no Internet connnectivity (and no mental
> state for work).
>
> Sorry about that.
Hey Marcelo,
you don't have to apologize
On Wed, Aug 09, 2006 at 07:02:01PM +0200, Willy Tarreau wrote:
> Hi Benjamin,
>
> On Wed, Aug 09, 2006 at 10:01:41AM -0700, Benjamin Cherian wrote:
> > Willy,
> > Sorry I didn't notice your email till now.
>
> no problem.
>
> > On Friday 04 August 2006 09:55, Willy Tarreau wrote:
> > > The probl
On Fri, Aug 11, 2006 at 02:03:21PM -0400, Alan Stern wrote:
> On Fri, 11 Aug 2006, Greg KH wrote:
>
> > > This won't work right if an error occurs. The value you return to the
> > > caller of usb_new_device() reflects only errors in creating the new
> > > thread. It doesn't reflect any errors
Greg:
We don't want khubd to start interfering in the device-resume process
merely because the PORT_STATUS_C_SUSPEND feature happens to be set.
Ports need to be marked as busy while a resume is taking place.
In addition, so long as ports are marked as busy, khubd won't be able
to clear their vari
Hi Monty,
Em Fri, 11 Aug 2006 16:24:49 -0400
"Christopher Montgomery" <[EMAIL PROTECTED]> escreveu:
| [resending again; sourceforge's SMTP servers appear to be unhappy.
| The original mails bounced back to me after timing out]
We received it first time. :)
I'll give it a try this weekend.
[resending again; sourceforge's SMTP servers appear to be unhappy.
The original mails bounced back to me after timing out]
While I continue working to split my scheduler patch up into smaller
bits that are easier to review, I've tossed the monolithic version up
on the web for testing.
http://web.
Greg & David:
The inconsistent lock state problem in usbcore (the one that shows up when
an HCD is unloaded) comes down to two inter-related problems:
usb_rh_urb_dequeue() isn't set up to be called with interrupts
disabled.
hcd_endpoint_disable() doesn't wait for all URBs
On Fri, 11 Aug 2006, Greg KH wrote:
> > This won't work right if an error occurs. The value you return to the
> > caller of usb_new_device() reflects only errors in creating the new
> > thread. It doesn't reflect any errors the thread itself may encounter.
> >
> > So the caller won't realiz
I have a new Palm Treo 700p from Verizon, and it seems they
have modified the software so the stock
kernel drivers will cause the 700p to reboot when the first character is
sent to ttyUSB0. When the Verizon
USB drivers are installed on Windoze, it works fine. I have been testing
with
On Fri, Aug 11, 2006 at 11:24:26AM -0400, Alan Stern wrote:
> On Fri, 11 Aug 2006, Greg KH wrote:
>
> > From: Greg Kroah-Hartman <[EMAIL PROTECTED]>
> > Subject: USB: create a new thread for every USB device found during the
> > probe sequence
> >
> > Might speed up some systems. If nothing els
On Fri, 11 Aug 2006, Thorsten Wiedemer wrote:
> Hi !
>
> Thanks for the quick answers !
>
> > You shouldn't make timing measurements based on when things show up in
> > /var/log/messages. That file is maintained by the syslog daemon, which
> > does not necessarily add entries as soon as they ar
Greg:
The UHCI controller in my laptop takes longer to turn off the
Resume-Detect bit than the 4 us allowed by uhci-hcd. Presumably other
computers will have the same problem.
This patch (as752) increases the maximum delay to 10 us, which should be
plenty, and uses polling to avoid penalizing s
On Fri, 11 Aug 2006, Greg KH wrote:
> From: Greg Kroah-Hartman <[EMAIL PROTECTED]>
> Subject: USB: create a new thread for every USB device found during the probe
> sequence
>
> Might speed up some systems. If nothing else, a bad driver should not
> take the whole USB subsystem down with it.
>
On Fri, 11 Aug 2006, Klaus Muth wrote:
> Ok. I patched scsi_scan.c and scsi_ioctl.c, recompiled the modules and
> replaced scsi_mod.ko; modprobe scsi_mod; cat "bla" > /proc/scsi/device_info;
> plugged in.
> --
> [...]
> klaus scsi_get_device_flags: Vendor: >SRE<,
device_create_file() could fail, add proper error paths for this condition.
Please review.
Signed-off-by: Sean Young <[EMAIL PROTECTED]>
--
diff -urpN linux-2.6.18-rc3/drivers/usb/misc/phidgetkit.c
linux-2.6.16/drivers/usb/misc/phidgetkit.c
--- linux-2.6.18-rc3/drivers/usb/misc/phidgetkit.c
Hi list, hi Alan,
I fear I geht more and more off-topic here...
Am Freitag, 11. August 2006 10:55 schrieb Klaus Muth:
> Hi, list, hi Alan,
> I'm learning now much more about drivers as I intended to...
>
> Am Donnerstag, 10. August 2006 17:34 schrieb Alan Stern:
> > > Hmmm. As far I can see, this
On Fri, Aug 11, 2006 at 08:46:54AM +0200, Thorsten Wiedemer wrote:
> Hi !
>
> > Yes, I'm playing around with some multi-threaded probing stuff right
> > now. I've got PCI working pretty well now, see the -mm kernel for the
> > patches if you want to test it out.
> >
> > However it's not going to
Hi, list, hi Alan,
I'm learning now much more about drivers as I intended to...
Am Donnerstag, 10. August 2006 17:34 schrieb Alan Stern:
> > Hmmm. As far I can see, this ALLOW_MEDIUM_REMOVAL is issued despite of
> > the blacklist entry. So:
> > # cat /proc/scsi/device_info | grep OPTAC
> > 'SRE
18 matches
Mail list logo
